首页 文章 精选 留言 我的

精选列表

搜索[实战攻防],共10000篇文章
优秀的个人博客,低调大师

Web应用安全--攻防对抗发展趋势

Struts2 S2-032让安全的江湖又掀起了一阵腥风血雨,很多网站纷纷中招,被黑客入侵造成了各种重大损失。从历史 Struts2 漏洞爆发数据看,此前每次漏洞公布都深度影响到了政府、银行、证券、保险等行业,这次也不例外。网站的Web安全一直是一个大众密切关注的方向,接下来我们聊聊这个话题。 超过半数的网站Web应用数据遭受泄露、造成重大财务损失; 企业网站安全事件频发、遭黑客勒索与竞争对手恶意攻击; 越来越多的网站开始将业务接入到云计算服务中、充分利用云的计算优势和便利; 网站的管理者都开始关注网站安全,会使用安全产品进行防护。 企业面临的挑战 每天曝光的Web漏洞、危害性大、影响面广,如何保持实时的更新? 不断的收到大量的安全告警日志、但不知如何下手? 被第三方漏洞平台曝光网站安全隐患,防不胜防? 海量肉鸡攻击下网站的页面显示很慢甚至无法打开、无能为力? 攻击从传统Web攻击跨越到业务场景、如撞库、抓取数据、短信接口滥用等,束手无策? 解决方案 WAF(Web应用防火墙)作为一款成熟的网站防护产品、已成为企业为Web应用提供安全防护的必备利器。它能够抵御定向的Web技术攻击、部分业务逻辑攻击以及海量肉鸡的恶意访问。通过对Web应用的深入解析和检测, 能够阻拦SQL注入、跨站脚本攻击,阻止恶意扫描等常见Web攻击并提供修补漏洞的能力。 云安全下的新特性 WAF作为一款传统的安全防护产品,已经发展多年。但近年来,随着云计算市场的火热,WAF有了一种新的接入方式:云部署。通过简单的DNS记录变更,将流量引入到云端防护集群,经过安全防护检测后,将安全流量回源到服务器。相比于传统的防护手段,它有如下特点: 产品+数据+运营,三位一体综合、实现最佳防护效果。传统的安全防护模式仅是提供形形色色的产品。但绝不仅仅是买了个安全产品就搞定了一切。安全是需要不断的大数据分析模型、自适应的调整防护策略应对不断变化的安全趋势;需要不断的对产品进行精细化的运营。阿里云在数据和运营上有着先天的巨大优势,客户要做的,就是关于自身业务,安全交给我们。 零部署、零安装、五分钟接入、快速稳定。仅需简单的变更、无需繁琐的机房布线、机器上架等操作、即可快速享受安全防护。同时多集群部署保障业务稳定不受影响。 实时防护0day漏洞。云上安全专家实时监控、针对漏洞的防护规则云端瞬时下发、无需传统模式下的复杂升级流程。 防护能力自动扩展、与云上网站共享。云上用户包括淘宝、支付宝等生成的防护规则,百万级的恶意IP信誉库、恶意样本等,均自动覆盖到您的网站。 集群弹性扩容、轻松应对海量业务下的防护。传统的防护模式、很难满足业务突增(如秒杀促销活动)、海量肉鸡攻击的场景,而云计算时代下的弹性扩容及大数据学习能力、将这些不可能都变成了过去。 在业务上,结合反欺诈、风控、人机识别等相关技术,在不修改应用代码的情况下,完美的实现防撞库、防爬防抓、接口滥用等业务防护需求;在产品的结合上,无论是和CDN的联动打造安全的加速流量,还是和云解析的一键开通,无缝融合、满足用户业务的各种使用场景。 云WAF发展的新道路 诚然,曾经的云WAF也有被人诟病之处,比如说攻击者可以绕过WAF直接访问源站地址进行定向攻击;业务误漏报后、不能很好的支持网站的规则自定义;数据的隐私泄露,HTTPS业务下私钥的安全性等。但经过这几年技术的发展,这些都变成了历史,不再是云WAF的弱点、取而代之的是下面的变革: 合规。积极的完成PCI-DSS认证需求,满足企业对数据安全性的要求。针对数据库的注入抓取等非授权行为做到安全防护,避免数据泄露。针对企业对HTTPS业务下的私钥安全顾虑,推出Keysafe方案,无需上传私钥,同时支持对加密流量的安全防护。 严密。针对以往的指定源站IP进行定向攻击绕过、一方面可在源站服务器上做安全准入控制、只允许云WAF的IP访问,其余定向的访问一律禁止;另一方面将站点流量全部置身于云WAF的防护中、实现网站的隐身,避免真实地址的暴露。 省心。充分利用云计算的大数据优势、建立起网站的正常模型。能够清晰的梳理出网站的正常业务请求模型、让0day漏洞无从绕过,正常的业务请求不被误阻断。网站接入初期开启预警模式、保障线上业务的正常运行、在最短时间内让网站维护者清晰的清楚业务误漏报概况。 全面。高性能SSL支持,数据链路加密。防护能力更多的覆盖到如撞库、接口滥用、业务欺诈、风控识别等业务场景中。 贴心。针对站点、URL等定制各种精细化的防护策略;提供友好可自定义的出错、拦截页面;给予网站用户最好的使用体验。一切皆可定制,打造成你自己想要的那一个。 对于数据隐私要求性非常高的金融行业,WAF是必备的防护利器。阿里云WAF除了支持云内客户的网站安全防护,也支持云外客户的安全需求,通过DNS切换轻松一键接入。除此之外、阿里云安全为金融行业还可以提供各类安全服务(如白盒测试、黑盒测试、渗透测试、移动应用测试等),全力为客户打造安全的解决方案。本文转自d1net(转载)

优秀的个人博客,低调大师

AD域攻防权威指南.六十.FAST配置操作

‍ ## 引言 在前文对 Kerberos 灵活认证安全隧道(FAST)机制的原理与作用进行梳理之后,如何在实际域环境中正确启用 FAST,并直观地验证其对常见 Kerberos 攻击的防护效果,成为管理员与红蓝双方都非常关心的问题。若 FAST 未被正确开启,KDC 依然会响应未经 Armoring 的认证请求,攻击者便可以轻易实施票据传递、AS-REP Roasting、Kerberoasting 等基于 TGT 的攻击;反之,一旦策略生效,这些攻击链会在最前端被截断。本篇文章将围绕 FAST 的组策略配置流程展开,先介绍 KDC 与 Kerberos 客户端两侧需要修改的关键策略项,再通过对比开启前后 `Rubeus` 请求 TGT 与实施 AS-REP Roasting 的实际结果,帮助读者完整理解 FAST 的配置方法与防护价值。 ## 1 FAST配置 ### 1.1 在KDC侧启用FAST策略 在组策略中找到 KDC 选项,将「KDC 支持声明、复合身份认证和 Kerberos Armoring」选项设置为「失败的非 Armoring 身份验证请求」,如图 1-1 所示。 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/dcdd6f76ab897850999ff89bb8040e87.png) 图1-1 设置为「失败的非 Armoring 身份验证请求」 ::: ### 1.2 在Kerberos客户端启用FAST支持 在 Kerberos 选项中启用「Kerberos 客户端支持声明、复合身份认证和 Kerberos Armoring」选项,如图 1-2 所示。 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/f1cf3e82da64ce897b24b0bb779355fd.png) 图1-2 启用「Kerberos 客户端支持声明、复合身份认证和 Kerberos Armoring」 ::: ### 1.3 更新组策略并验证FAST开启前的TGT请求 使用 `gpupdate` 命令刷新组策略: ```powershell gpupdate /force ``` 更新完毕后对 FAST 进行验证。可以看到,在未开启 FAST 前,通过 `Rubeus` 向 KDC 请求域用户的 TGT 票据是能够成功的,如图 1-3 所示。 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/f408ee429e518c43745124c2393321b4.png) 图1-3 未开启 FAST 前成功请求域用户的 TGT 票据 ::: ### 1.4 开启FAST后请求TGT票据的效果对比 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/af1e1376beeec7423b672e7d94ec57e0.png) 图1-4 开启 FAST 后请求域用户 TGT 票据失败 ::: 开启 FAST 之后再次请求域用户 TGT 票据,请求随即失败,如图 1-4 所示。此时已无法再使用 `Rubeus` 向 KDC 申请该用户的 TGT。 ### 1.5 开启FAST后AS-REP Roasting攻击验证 在开启 FAST 后,继续尝试 AS-REP Roasting 攻击,结果如图 1-5 所示,攻击同样无法成功执行。 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/7a426d5072f236bf206cd78545c65545.png) 图1-5 开启 FAST 后进行 AS-REP Roasting 攻击 ::: ### 1.6 小结 通过上述验证可以看到,正确配置 FAST 之后,攻击者已经无法再强制 KDC 返回目标用户的 TGT。一旦这一环节被阻断,很多依赖 TGT 的域内攻击都将无法继续实施,例如票据传递(Pass-the-Ticket)、AS-REP Roasting 利用等一系列需要预先申请 TGT 的攻击手法。前文提到的 Kerberoasting 攻击同样会受影响,因为该攻击链需要先申请 TGT,再据此向 KDC 申请服务票据(ST)。综合来看,可以得出结论:FAST 的配置确实能够显著提升 Kerberos 认证的安全性,是加固域环境时非常值得启用的一项防护机制。

优秀的个人博客,低调大师

AD域攻防权威指南.九十七.配置约束委派

## 1. 配置约束委派 约束委派是 AD 域中一种"受限的委派方式",其允许指定服务账户仅代表用户去访问某些明确指定的目标服务(通过 `msDS-AllowedToDelegateTo`​ 属性限定)。这种机制在被攻击者控制服务账户后,同样可以借助 S4U2self 与 S4U2proxy 协议扩展被滥用,进而伪造任意用户身份访问目标服务。下文以 `cifs/dc01` 服务为例,演示完整的利用过程。 ### 1.1 实验环境 本次实验所使用的环境信息如下: - 域控(DC):`dc01.dm.org` - 开启委派的服务账户:`user3` - 开启委派的目标服务:`cifs/dc01` ### 1.2 获取开启委派服务账户的 TGT 要利用约束委派,第一步是获取到"开启委派的服务账户"的 TGT。根据攻击者所掌握凭据形式的不同,可分为以下三种典型场景。 #### 1.2.1 场景一:已知明文密码,使用 Rubeus 请求 TGT 若已经获取到 `user3`​ 的明文密码,可直接使用 `Rubeus`​ 的 `asktgt`​ 功能申请 TGT 并保存为 `.kirbi` 文件。在 cmd 中执行以下命令,如图 1-1 所示。 ```powershell rubeus.exe asktgt /user:user3 /password:Aa12341234 /domain:dm.org /outfile:user3_cifs.kirbi ``` :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/7c270df8e230802bb27d1562f7a658cc.jpg) 图 1-1 使用 Rubeus(明文密码)请求 user3 的 TGT ::: #### 1.2.2 场景二:已知 NTLM 哈希,使用 Rubeus 请求 TGT 若只掌握 `user3`​ 的 NTLM 哈希,可使用 `/rc4` 参数进行哈希传递并请求 TGT。在 cmd 中执行以下命令,如图 1-2 所示。 ```powershell Rubeus.exe asktgt /user:user3 /domain:dm.org /rc4:ce70663fc9b5f62bef73ec79bc57921e /outfile:user3_cifs.kirbi ``` :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/e629aa8fd8ed19f6b569e40390d93cfc.jpg) 图 1-2 使用 Rubeus(NTLM 哈希)请求 user3 的 TGT ::: #### 1.2.3 场景三:无明文与哈希,利用 Mimikatz 从内存导出 TGT 若既没有明文密码,也没有 NTLM 哈希,但已经在该服务账户所登录的主机上取得较高权限,则可以借助 `Mimikatz`​ 直接从 LSASS 内存中导出 `user3` 已缓存的 TGT。执行以下命令,如图 1-3 所示。 ```powershell privilege::debug sekurlsa::tickets /export ``` :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/79ab152eb2900028521924fc3d48b5f2.jpg) 图 1-3 利用 Mimikatz 从内存中 dump user3 的 TGT ::: ### 1.3 通过 S4U2self / S4U2proxy 申请高权限服务票据 拿到 `user3` 的 TGT 后,即可利用 Kerberos 的 S4U(Service for User)扩展来伪造任意用户身份并申请目标服务的 ST(Service Ticket)。整个过程分为"S4U2self 换取可转发 TGS"和"S4U2proxy 换取目标服务 ST"两步,Rubeus 可通过一条命令一次性完成。 #### 1.3.1 使用 S4U2self 获取 administrator 的 TGS 首先通过 S4U2self,让 KDC 为 `administrator` 用户"代表申请"访问该服务的可转发 TGS。在 cmd 中执行以下命令,如图 1-4 所示。 ```powershell Rubeus.exe s4u /ticket:user3_cifs.kirbi /impersonateuser:administrator /msdsspn:cifs/dc01.dm.org /altservice:cifs /ptt ``` :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/316b6647ff4e481db71d2720ac1ad6bf.jpg) 图 1-4 通过 S4U2self 获取 administrator 用户的 TGS ::: #### 1.3.2 使用 S4U2proxy 请求 cifs/dc01 的 ST 并注入内存 随后 Rubeus 会自动使用上一步得到的可转发 TGS,通过 S4U2proxy 向 KDC 申请以 `administrator`​ 身份访问 `cifs/dc01`​ 的 ST,并借助 `/ptt` 参数将该票据注入到当前会话内存中,如图 1-5 所示。 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/2bc05e2a21a569b7862e99839ac3c330.jpg) 图 1-5 通过 S4U2proxy 请求 cifs/dc01 的 ST 并注入内存 ::: ### 1.4 验证权限 票据申请完成后,需要通过实际访问来验证权限提升是否成功。可通过"清空票据 → 直接访问"与"注入高权限票据 → 再次访问"进行对比。 #### 1.4.1 清空票据后以低权限身份访问 先使用 `klist purge`​ 清空当前会话中所有 Kerberos 票据,然后以低权限身份(`user2`)尝试直接访问域控的 C 盘共享,如图 1-6 所示,此时会因权限不足而被拒绝。 ```powershell klist purge dir \\dc01.dm.org\c$ ``` :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/73a1988cf1b0333b3af5f62ff68ccdc3.jpg) 图 1-6 清空票据后以 user2 身份访问 cifs/dc01 被拒绝 ::: #### 1.4.2 注入高权限票据后再次访问 将上一步通过 S4U2proxy 获得的、以 `administrator`​ 身份访问 `cifs/dc01` 的 ST 注入内存后,再次执行访问命令,如图 1-7 所示,可以成功列出域控 C 盘目录,说明约束委派攻击链路利用成功。 ```powershell dir \\dc01.dm.org\c$ ``` :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/abc587b73313f220d96e809e3a125c1f.jpg) 图 1-7 注入高权限票据后成功访问 cifs/dc01 ::: ### 1.5 攻击链小结与防御建议 #### 1.5.1 攻击链小结 综合上述过程,约束委派利用链可以概括为以下五个关键步骤: 1. 攻陷或获取开启了约束委派的服务账户(本例中的 `user3`); 2. 通过明文密码 / NTLM 哈希 / 内存导出等方式,获得该账户的 TGT; 3. 通过 S4U2self 伪造目标用户(如 `administrator`)身份,向 KDC 申请可转发的 TGS; 4. 通过 S4U2proxy 使用该 TGS 申请对 `msDS-AllowedToDelegateTo`​ 中所允许目标服务(如 `cifs/dc01`)的 ST; 5. 将 ST 注入内存,以被伪造用户的身份访问对应服务,实现权限提升与横向移动。 其危险性在于:只要拿下"任意一个"配置了约束委派并指向高价值服务(如 `cifs/dc01`​、`ldap/dc01`​、`host/dc01` 等)的服务账户,即可等价于拿下对应服务的完全控制权,往往可直接接管域控。 #### 1.5.2 防御建议 针对约束委派带来的安全风险,建议在实际域环境中从以下几个方面进行加固: 1. **最小化委派配置**:严格审计域内所有开启了 `msDS-AllowedToDelegateTo` 属性的账户,仅在必要业务场景中开启约束委派,并将委派目标 SPN 收敛到最小集合。 2. **禁止对敏感服务的委派**:避免将 `cifs`​、`ldap`​、`host`​、`http`​ 等指向域控的 SPN 加入委派列表;对高权限账户(如域管理员)应勾选 "Account is sensitive and cannot be delegated",并加入 `Protected Users` 组。 3. **强化服务账户口令**:为开启委派的服务账户设置高强度密码,或改用 `gMSA`(组托管服务账户),降低密码被爆破或从内存导出的风险。 4. **加强日志监控**:重点关注 4768(TGT 申请)、4769(TGS 申请)事件,特别是同一账户短时间内为多个不同用户申请 TGS、或对高敏 SPN 申请 TGS 的行为,及时告警。 5. **限制主机侧凭据落地**:在配置了委派的服务器上启用 Credential Guard、LSA 保护,减少 Mimikatz 类工具从内存中获取票据与哈希的可能性。 通过配置侧收敛 + 账户侧加固 + 检测侧监控的组合策略,才能真正压制约束委派滥用带来的风险,避免其成为攻击者从普通服务账户"一步登天"直取域控的跳板。

优秀的个人博客,低调大师

AD域攻防权威指南.七十三.域信任技术

‍ > **引言**:在企业级 Active Directory 环境中,随着业务的扩张与组织架构的演进,单一域已无法满足跨部门、跨分支机构乃至跨组织的资源访问需求,如何在多个独立的安全边界之间安全、高效地共享身份与资源,成为域架构设计中的核心议题。而域信任(Domain Trust)正是解决这一问题的关键机制——它决定了一个域中的用户能否被另一个域所认可,也决定了攻击者一旦攻陷某个域后能否进一步横向渗透至其他域乃至整片森林。因此,深入理解域信任的方向、传递性以及底层的 TDO(信任域对象)属性,既是域管理员构建合理权限边界的基础,也是红队评估攻击面、蓝队规划纵深防御的必修课。本篇文章将从域信任的基本概念入手,依次讲解信任方向(单向/双向)、传递性机制以及信任关系创建时所传递的核心属性,帮助读者建立起对 AD 域信任体系的整体认知,为后续深入研究跨域攻击手法(如 SID History、Golden Ticket 跨域滥用、林信任利用等)打下理论基础。 # 1 域信任概述 默认情况下,Windows 域中的所有用户都可以通过该域进行身份验证,这个域可以为其用户提供对该域中所有资源的安全访问。要扩展访问权限以访问超出此域边界的资源,就需要使用**信任关系**。信任关系为一个域提供了一种机制,允许基于另一个域的登录身份验证来访问信任域的资源。 在 Windows NT 4.0 Server 和更早版本的域控制器的域中,信任关系是单向的,两个域中只有一个信任另一个域,且具有非传递性,不会扩展到其他任何域。而在运行 Windows Server 2003 或 Windows 2000 Server 的域控制器的域中,信任关系都是双向的,即两个域彼此信任,且具有传递性,可以扩展到林中的所有域。 从信任方向上看,域信任可分为两大类:**单向信任**和**双向信任**,下面分别进行介绍。 # 2 单向信任 单向信任是在两个域之间创建的单向身份验证路径,**信任在一个方向上流动,而访问在另一个方向上流动**。如果 A 信任 B,在 A 查询信任会标记 `outbound`​,在 B 查询信任会标记 `inbound`,则访问权限是 B 可以访问 A。 这意味着,在受信任域和信任域之间的单向信任中: - 受信任域中的用户或计算机**可以**访问信任域中的资源; - 信任域中的用户**无法**访问受信任域中的资源。 某些单向信任可以是非传递的,也可以是传递的,具体取决于要创建的信任的类型,如图 1-1 所示。 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/e78221952bcc7f31cd92fe11fb43fa80.png) 图 1-1 单向信任中的信任路径 ::: # 3 双向信任 双向信任可以看作两个相对的单向信任的组合,因此,信任域和受信任域都彼此信任,是双向的信任和访问流。这意味着可以在两个方向之间的两个域之间传递身份验证请求。 某些双向关系可以是非传递性的,也可以是传递性的,具体取决于所创建的信任类型。**Active Directory 林中的所有域信任都是双向传递信任**。创建新的子域时,将在新的子域和父域之间自动创建双向传递信任。 # 4 信任的传递性 传递性决定了信任是否可以扩展到相互信任的两个域之外: - **可传递的信任**:将信任关系扩展到其他域; - **非传递性信任**:不会将信任关系扩展到其他域。 即 A 信任 B,B 信任 C,如果存在传递性,则 A 隐式信任 C,否则反之。每次在林中创建新域时,都会在新域与其父域之间自动创建双向传递信任关系。如果将子域添加到新域,则信任路径在域层次结构中向上流动,从而扩展在新域与其父级之间的初始信任路径。 ## 4.1 TDO 中传递的属性 当一个域信任关系被创建时,各域之间会传递一些属性,这些内容都会保存在 **TDO(Trusted Domain Object,存储信任域对象资料)** 中,主要包括: - DNS 域名 - 域 SID - 信任关系类型 - 信任关系传递性 - Windows 对等域名 如果是**林信任关系**,还会传递以下额外内容: - 各林中的域树名 - 用户主体名称(UPN)后缀 - 服务主体名称(SPN)后缀 - 安全 ID(SID)命名空间 ## 4.2 传递信任在域树中的流动 传递信任关系在域树形成时向上流动通过域树,从而在域树中的所有域之间创建传递信任。因此,可以将域树定义为一个或多个域的层次结构,这些域通过可传递的双向信任关系连接,形成一个连续的名称空间。多个域树可以属于一个森林(Forest)。 身份验证请求遵循这些扩展的信任路径,因此林中任何域的账户都可以由林中的任何其他域进行身份验证。**通过单个登录过程,具有适当权限的账户可以访问林中任何域中的资源**,这也是 AD 林作为统一安全边界的核心价值所在。

优秀的个人博客,低调大师

AD域攻防权威指南.五十九.绕过FAST保护

> **引言**:Kerberos FAST(Flexible Authentication Secure Tunneling)作为微软为抵御 AS-REQ 阶段离线爆破、Kerberoasting 等攻击而引入的安全通道机制,广泛部署于强化后的 AD 域环境中。然而在真实的红队对抗场景里,攻击者往往关注一个关键问题:当 FAST 已开启时,是否仍存在绕过其保护、继续实施票据申请与离线破解的路径?本篇聚焦"绕过 FAST 保护"这一课题,围绕机器账户在 AS-REQ 阶段的行为差异,结合 Powermad 与 Charlie Clark 修改版 Rubeus 工具,完整演示一次从机器账户申请、TGT 获取到指定 SPN 服务票据请求的绕过流程,并对绕过的实际边界(如与 CVE-2021-42287/42278 组合利用时的限制)进行剖析,帮助读者理解 FAST 机制的防护范围与盲区。 ‍ ### 1. 原理分析 在 AS-REQ 请求的过程中,若将 `req-body`​ 中的 `sname`​ 字段指定为某个 SPN,AS 认证服务将直接返回该服务对应的 ST 票据。也就是说,攻击者不再需要经过 TGS 阶段,而是直接通过 AS 就能申请到 ST 票据,从而**跳过了传统的 TGT 申请步骤**。 进一步分析可以发现:当 FAST 配置开启后,**机器账户的 AS-REQ 请求实际上并未受到 FAST 保护**——这正是本节要利用的核心突破口。 ### 2. 实验思路 接下来通过一次完整的实验演示:在开启 FAST 的情况下,使用机器账户向 AS 认证服务请求指定 SPN 的服务票据,验证 FAST 保护范围外的攻击链是否成立。 ### 3. 使用 Powermad 申请机器用户 首先借助 `Powermad`​ 创建一个用于测试的机器账户 `fastbypass`,结果如图 1-1 所示。 ```powershell import-module .\powermad.ps1 New-MachineAccount -MachineAccount fastbypass -Domain jctest.com -DomainController xxxxxx.jctest.com ``` :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/0bbb1a032d113c95972c115a68ba8dc1.png) 图 1-1 使用 Powermad 申请机器用户 ::: ### 4. 使用机器账户在开启 FAST 的情况下申请 TGT 在 FAST 已开启的域环境中,使用上一步创建的机器账户去申请 TGT,结果如图 1-2 所示。 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/03bf8c797f26bbb9091cf9fc231bfaa7.png) 图 1-2 开启 FAST 的情况下使用机器账户申请 TGT ::: ### 5. 抓包验证:机器账户走的仍是传统 Kerberos 协议 通过抓包可以确认,使用机器账户在 FAST 开启的情况下成功申请到了 TGT,并且认证流程**仍然使用传统 Kerberos 协议**,而不是 FAST 封装后的形态,如图 1-3 所示。 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/c7605eb877c65fdabfce8984e8a9fc1d.png) 图 1-3 抓包验证 ::: ### 6. 使用 Charlie Clark 修改版 Rubeus 指定 SPN 请求 ST 接下来使用经过 Charlie Clark 修改后的 `Rubeus`​,在 AS-REQ 发送过程中把 `sname`​ 指向指定 SPN,让 AS 直接返回该 SPN 对应的服务票据。使用方式非常简单——只需在命令行中额外加上 `/service` 参数即可,如图 1-4 所示。 ```powershell Rubeus.exe asktgt /user:fastbypass$ /password: /domain:jctest.com /dc:xxxxxx.jctest.com /service: ``` :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/b7529f0e5c0e4316984c55682541c288.png) 图 1-4 在执行 Rubeus 时添加 /service 参数 ::: ### 7. 离线爆破:获取注册该 SPN 的域用户密码 此时可以看到,返回票据中的 `servicename` 已经指向我们指定的 SPN,可直接对该票据进行离线爆破。最终成功获取到注册该 SPN 的域用户密码,如图 1-5 所示;对应的数据包信息如图 1-6 所示。 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/e70a36dc02f618e4f101bb8b164e1341.png) 图 1-5 已经成功获取注册该 SPN 的域用户密码 ::: :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/a31b675c4776375d3181fbe4d2714a7d.png) 图 1-6 数据包信息 ::: ### 8. 绕过的边界与限制 至此已经验证:通过修改 `sname`​,可以让 AS 认证服务器直接返回 ST 票据;并且使用**机器账户**能够绕过 FAST 机制成功申请 TGT。 但需要指出的是,这种绕过并非"万能钥匙",存在明确的限制。以 `CVE-2021-42287`​ & `CVE-2021-42278`​ 漏洞利用链为例,其标准利用流程是:先申请一个机器账户,再通过该机器账户请求 TGT,随后借助 TGT 通过 `S4U2Self`​ 协议申请目标 ST 票据。而实际测试中我们会发现——即便本节的方法能够绕过 FAST 成功申请到 TGT,**依旧无法通过** **​`S4U2Self`​**​ **完成 ST 票据的申请**,如图 1-7 所示。 :::center ​![](https://developer.qcloudimg.com/http-save/yehe-1277458/c3fc313d9ccff519dfc8f4b23036d377.png) 图 1-7 可以绕过 FAST 申请 TGT,但无法通过 S4U2Self 申请 ST 票据 ::: 换句话说,FAST 对**基于 TGS-REQ 的后续动作(如 S4U2Self / S4U2Proxy)依然具有约束力**——这也是防御方在评估 FAST 部署收益时需要理解的关键边界。

优秀的个人博客,低调大师

渗透攻防Web篇-深入浅出SQL注入

1 背景 京东SRC(Security Response Center)收录大量外部白帽子提交的sql注入漏洞,漏洞发生的原因多为sql语句拼接和Mybatis使用不当导致。 2 手工检测 2.1 前置知识 mysql5.0以上版本中存在一个重要的系统数据库information_schema,通过此数据库可访问mysql中存在的数据库名、表名、字段名等元数据。information_schema中有三个表成为了sql注入构造的关键。 1)infromation_schema.columns: table_schema 数据库名 table_name 表名 column_name 列名 2)information_schema.tables table_schema 数据库名 table_name 表名 3)information_schema.schemata schema_name 数据库名 SQL注入常用SQL函数 length(str) :返回字符串str的长度 substr(str, pos, len) :将str从pos位置开始截取len长度的字符进行返回。注意这里的pos位置是从1开始的,不是数组的0开始 mid(str,pos,len) :跟上面的一样,截取字符串 ascii(str) :返回字符串str的最左面字符的ASCII代码值 ord(str) :将字符或布尔类型转成ascll码 if(a,b,c) :a为条件,a为true,返回b,否则返回c,如if(1>2,1,0),返回0 2.2 注入类型 2.2.1 参数类型分类 整型注入 例如?id=1,其中id为注入点,类型为int类型。 字符型注入 例如?id=”1”,其中id为注入点,类型为字符型,要考虑闭合后端sql语句中的引号。 2.2.2 注入方式分类 盲注 布尔盲注:只能从应用返回中推断语句执行后的布尔值。 时间盲注:应用没有明确的回显,只能使用特定的时间函数来判断,例如sleep,benchmark等。 报错注入:应用会显示全部或者部分的报错信息 堆叠注入:有的应用可以加入 ; 后一次执行多条语句 其他 2.3 手动检测步骤(字符型注入为例) // sqli vuln code Statement statement = con.createStatement(); String sql = "select * from users where username = '" + username + "'"; logger.info(sql); ResultSet rs = statement.executeQuery(sql); // fix code 如果要使用原始jdbc,请采用预编译执行 String sql = "select * from users where username = ?"; PreparedStatement st = con.prepareStatement(sql); 使用未预编译原始jdbc作为demo,注意此demo中sql语句参数采用单引号闭合。 2.3.1 确定注入点 对于字符类型注入,通常先尝试单引号,判断单引号是否被拼接到SQL语句中。推荐使用浏览器扩展harkbar作为手工测试工具。https://chrome.google.com/webstore/detail/hackbar/ginpbkfigcoaokgflihfhhmglmbchinc 正常页面应该显示如下: admin后加单引号导致无信息回显,原因是后端sql执行报错,说明引号被拼接至SQL语句中 select * from users where username = 'admin' #正常sql select * from users where username = 'admin'' #admin'被带入sql执行导致报错无法显示信息 2.3.2 判断字段数 mysql中使用order by进行排序,不仅可以是字段名也可以是字段序号。所以可以用来判断表中字段数,order by 超过字段个数的数字就会报错。 判断字段数 当order by 超过4时会报错,所以此表共四个字段。 后端所执行的sql语句 select * from users where username = 'admin' order by 1-- ' 此处我们将原本username的值admin替换为admin’ order by 1 —+,其中admin后的单引号用于闭合原本sql语句中的前引号,—+用于注释sql语句中的后引号。—后的+号主要作用是提供一个空格,sql语句单行注释后需有空格,+会被解码为空格。 2.3.3 确定回显位置 主要用于定位后端sql字段在前端显示的位置,采用联合查询的方式确定。注意联合查询前后字段需一致,这也就是我们为什么做第二步的原因。 通过下图可知,后端查询并回显的字段位置为2,3位。 联合查询后的字段可以随意,本次采用的是数字1到4直观方便。 2.3.4 利用information_schema库实现注入 group_concat()函数用于将查询结果拼接为字符串。 查看存在数据库 查看当前数据库中的表 查看指定表中字段 利用以上获取信息读取users表中username和password 3 自动化检测 3.1 sqlmap 使用 sqlmap兼容python2和python3,可以自动化检测各类注入和几乎所有数据库类型。 3.1.1 常用命令 -u 可能存在注入的url链接 -r读取http数据包 --data 指定post数据 --cookie 指定cookie --headers 指定http头 如采用token认证的情况下 --threads 指定线程数 --dbms 指定后端的数据库 --os 指定后端的操作系统类型 --current-user 当前用户 --users 所有用户 --is-dba 是否是dba --sql-shell 交互式的sqlshell -p指定可能存在注入点的参数 --dbs 穷举系统存在的数据库 -D指定数据库 --tables 穷举存在的表 -T指定表 --column 穷举字段 -C指定字段 --dump dump数据 直接检测 其中—cookie用于指定cookie,—batch 自动化执行,—dbms指定数据库类型 检测结果 读取系统中存在数据库 —dbs读取当前用户下的数据库 读取指定库下的表 -D java_sec_code —tables dump users表数据 -D java_sec_code -T users —dump 4 进阶 4.1 Mybatis注入 1)$错误使用导致注入 //采用#不会导致sql注入,mybatis会使用预编译执行 @Select("select * from users where username = #{username}") User findByUserName(@Param("username") String username); //采用$作为入参可导致sql注入 @Select("select * from users where username = '${username}'") List<User> findByUserNameVuln01(@Param("username") String username); 2)模糊查询拼接 //错误写法 <select id="findByUserNameVuln02" parameterType="String" resultMap="User"> select * from users where username like '%${_parameter}%' </select> //正确写法 <select id="findByUserNameVuln02" parameterType="String" resultMap="User"> select * from users where username like concat(‘%’,#{_parameter}, ‘%’) </select> 3)order by 注入 order by 后若使用#{}会导致报错,因为#{}默认添加引号会导致找不到字段从而报错。 //错误写法 <select id="findByUserNameVuln03" parameterType="String" resultMap="User"> select * from users <if test="order != null"> order by ${order} asc </if> </select> //正确写法 id指字段id 此表字段共四个 所以id为1-4 <select id="OrderByUsername" resultMap="User"> select * from users order by id asc limit 1 </select> 以上测试均在本地进行,请勿未授权进行渗透测试 5 文章及资料推荐 slqmap手册:https://octobug.gitbooks.io/sqlmap-wiki-zhcn/content/Users-manual/Introduction.html sql注入详解:http://sqlwiki.radare.cn/#/ 作者:罗宇(物流安全小分队)

优秀的个人博客,低调大师

Web 安全三大攻防:XSS、CSRF、SSRF 的防护实践

## 多数 Web 漏洞不是新攻击,是老三样的变体 安全团队每年披露大量 CVE,但落到业务上的实际入侵,多数还是 XSS(跨站脚本)、CSRF(跨站请求伪造)、SSRF(服务端请求伪造)这老三样的变体。理解它们的攻击原理与防护体系,能挡住绝大多数常规攻击面。 ## 一、XSS:输入不可信,输出要转义 **攻击原理**:用户提交的内容里携带脚本(如 `` 或事件属性),服务端或前端把它原样渲染进页面,其他用户浏览时脚本在其浏览器执行——窃取 Cookie、伪造操作、钓鱼挂马。 **三类形态**:存储型(存进数据库,伤害所有访问者,危害最大)、反射型(藏在 URL 参数里,需要诱导点击)、DOM 型(纯前端渲染时插入,不经过服务端)。 **防护体系**: 1. **输出转义是根本**:按渲染上下文转义(HTML 实体、JS 字符串、URL 编码各自规则)——用框架的默认转义(Vue/React 默认安全),危险的是 `v-html`/`dangerouslySetInnerHTML` 这类绕过点; 1. **输入过滤做辅助**:白名单校验(富文本用成熟过滤库),不要尝试黑名单穷举; 1. **CSP 兜底**:Content-Security-Policy 限制脚本来源(`script-src 'self'`),即使被注入也加载不了外部脚本;关键 Cookie 加 `HttpOnly` 让脚本偷不走; 1. **富文本场景**: sanitize 白名单标签集,禁止 script/iframe/onclick 一切事件属性。 ## 二、CSRF:借用你的身份发请求 **攻击原理**:用户登录着银行网站,又访问了恶意页面——恶意页面悄悄向银行发起转账请求,浏览器自动带上 Cookie,服务端以为是本人操作。核心是「浏览器会自动带认证信息」这个特性被滥用。 **防护体系**: 1. **CSRF Token**:服务端下发随机 Token,写操作必须携带且服务端校验——恶意页面拿不到 Token(跨域读不到),请求被拒。注意 Token 要绑定会话且随机; 1. **SameSite Cookie**:`SameSite=Lax/Strict` 限制跨站请求携带 Cookie,现代浏览器默认 Lax 已挡掉大部分攻击,但历史 Cookie 要专项排查; 1. **校验 Origin/Referer**:写操作校验请求来源域名,缺失或不对即拒绝——作为纵深防御的补充层; 1. **不要用 GET 做写操作**:State-Changing 请求全部 POST/PUT,别给攻击者一个图片标签就能触发的接口。 ## 三、SSRF:让服务器替攻击者访问内网 **攻击原理**:应用提供「输入一个 URL 帮你拉取」的功能(webhook、图片导入、预览),攻击者输入内网地址(`http://169.254.169.254/` 云元数据、内网管理后台),服务器替他访问了内网——云环境里 SSRF 直接等于密钥泄露。 **防护体系**: 1. **白名单目标域**:只允许拉取预设的域名列表,默认拒绝一切; 1. **解析后校验 IP**:DNS 解析成 IP 后校验是否内网段(10./172.16-31./192.168./169.254./127.)——注意 DNS Rebinding(解析两次返回不同 IP),校验后发起连接的必须是校验过的那个 IP; 1. **网络层隔离**:执行外呼的服务放独立子网,安全组只放行必要的出网目标——内网管理面与元数据端点对它不可达,SSRF 伤害自然封顶; 1. **禁用危险协议**:只允许 http/https,过滤 file://、gopher:// 等协议。 ## 共同的工程原则 三者背后是同一条纪律:**输入永远不可信**(XSS 是渲染不可信输入,CSRF 是不可信页面借用身份,SSRF 是把不可信输入当访问目标)。防护不是单点,是「转义/校验/隔离」的纵深组合——单层被绕过(新攻击变体)时下一层还在。上线前用自动化扫描(依赖检查 + DAST)过一遍,比事后补洞便宜一百倍。

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册