目录
1. CSRF（Cross-Site Request Forgery，跨站请求伪造）
2. XSS（Cross-Site Scripting，跨站脚本攻击）
3. CSRF双重提交Cookie（Double Submit Cookie）攻击
一、要求
1.总结CSRF和XSS区别
2.总结CSRF攻击步骤
3.总结CSRF手工构造POST型页面方法
4.说明token类CSRF利用方法
5.SSRF常用伪协议
6.SSRF pikachu靶场通关
7.SSRF靶场通关时根据源代码说明漏洞成因（加分项）
二、内容与步骤记录
（一）CSRF和XSS
CSRF和XSS都是客户端攻击，它们滥用同源策略，利用web应用程序和受害用户之间的信任关系。XSS和跨站脚本攻击允许攻击者破坏合法用户与任何易受攻击的应用程序的交互。
1. CSRF（Cross-Site Request Forgery，跨站请求伪造）
CSRF攻击是指攻击者诱使用户在已认证的网站上执行未授权的操作，攻击者利用用户的身份验证凭据，伪造请求来执行用户未意图的操作。攻击者可以在用户不知情的情况下执行操作，如更改账户设置、转账资金或提交表单等。
（1）工作原理：
- 攻击者诱导用户点击恶意链接或访问包含恶意代码的页面。
- 当用户已经登录并拥有有效的会话时，该恶意请求会被受信任的网站接受，并按照用户的身份执行。
（2）防护措施：
- 使用CSRF令牌（CSRF token）来验证请求的合法性。
- 检查请求来源（例如，检查Referer头部）。
- 实现双因素身份验证（2FA）来增加额外的安全性。
2. XSS（Cross-Site Scripting，跨站脚本攻击）
XSS攻击是指攻击者将恶意脚本注入到目标网站的网页中，当其他用户访问该网页时，恶意脚本会在用户的浏览器中执行。攻击者可以窃取用户的敏感数据，劫持用户会话，或在受害者浏览器中执行任意操作。
（1）工作原理：
- 攻击者在受信任的网页中注入恶意代码（通常是JavaScript）。
- 当受害者访问该网页时，恶意代码被浏览器执行，可以窃取用户的敏感信息（如cookie、会话令牌），劫持会话或展示伪造的内容。
（2）防护措施：
- 对用户输入进行严格的输入验证和输出编码。
- 使用内容安全策略（CSP）来限制脚本的执行。
- 禁用不必要的HTML特性（如内联JavaScript）。
3.CSRF和XSS区别
（1）目标不同：
- CSRF主要攻击用户已认证的状态，强迫其执行非意图的操作；
- XSS主要注入和执行恶意脚本，窃取数据或劫持用户会话。
（2）攻击方式不同：
- CSRF利用用户的身份认证和现有的会话，伪造合法请求；
- XSS通过在网页中注入恶意代码，欺骗浏览器执行攻击者的代码。
（3）防御方法不同：
- CSRF通过验证请求的来源和使用令牌防护；
- XSS通过过滤和编码用户输入、使用CSP等策略防护。
（二）CSRF攻击步骤
1.受害者登录受信任网站：
受害者登录网站，并获得一个会话Cookie。这个过程通常涉及受害者提供用户名和密码进行登录，成功后，网站会生成一个session ID并将其存储在受害者的浏览器中，以便受害者能够保持登录状态。
2.攻击者构造恶意请求：
攻击者构造一个包含恶意操作的请求，并将该请求嵌入到第三方网站或直接发送给用户。这个请求可能是通过创建一个恶意的网页链接或者使用HTML表单，诱使受害者在不知情的情况下执行。
3.受害者触发恶意请求：
当受害者访问了包含恶意请求的网页或点击了恶意链接时，受害者的浏览器会自动发送构造好的HTTP请求到目标网站。由于受害者的浏览器已经登录并持有有效的Cookie，目标网站会认为这是一个合法的请求并执行相应操作。
4.目标网站执行请求：
目标网站在接收到请求后，验证用户的身份，认为这是一个合法请求，并执行所请求的操作。如果没有足够的防护措施，网站会执行这个恶意请求，例如转账资金、修改账户信息等。
（三）CSRF手工构造POST型页面方法
1.确定目标操作的POST请求格式
要手动构造一个用于CSRF攻击的POST型页面，首先需要了解目标网站的表单结构和参数。例如请求的URL、POST、以及请求体中的参数。
2.创建HTML页面
使用HTML和JavaScript，攻击者可以创建一个自动提交表单的页面，该页面在加载时自动提交或被用户操作时触发提交。
方法一：使用自动提交的HTML表单
这种方法利用HTML表单的自动提交功能，在页面加载时提交表单。
例：
- 表单元素(<form>)：该元素的action属性指定了目标URL，metho属性指定请求方法为POST。
- 隐藏输入字段 (<input type="hidden">)：这些字段包含请求参数，如amount和recipient。
- 自动提交脚本：当页面加载时，JavaScript代码通过submit()方法自动提交表单。
方法二：使用fetch API
利用JavaScript的fetch API来构造POST请求，可以更加灵活地控制请求参数和行为。
例：
- fetch函数：fetch函数用于发送HTTP请求。method参数指定请求方法为POST。
- headers：指定Content-Type为application/x-www-form-urlencoded以匹配标准表单提交的格式。
- body：包含请求参数，例如amount和recipient。
- credentials: "include" ：确保请求中包含用户的认证Cookie，以便伪造请求看起来像是受害者用户发出的。
（四）token类CSRF利用方法
Token类CSRF防御机制通常依赖于在每个敏感请求中使用唯一的CSRF令牌来防止攻击。虽然CSRF令牌通常是难以预测的随机值，并且在请求时会被验证是否与服务器端生成的令牌匹配。然而，有一些方法可以绕过这些防御机制：
1. XSS结合CSRF
如果目标网站存在XSS漏洞，攻击者可以利用这个漏洞来窃取合法用户的CSRF令牌。通过XSS，攻击者可以在用户的浏览器中执行任意JavaScript代码，从而提取页面上的CSRF令牌，并将其用于伪造的请求中。
流程示例：
（1）发现XSS漏洞：攻击者在目标网站上找到一个可以注入恶意JavaScript代码的输入点。通常，这些输入点会将用户输入直接输出到页面上，而没有进行适当的转义或过滤。
（2）注入恶意代码：攻击者在这个输入点注入恶意JavaScript代码。
（3）诱导用户访问：攻击者通过社交工程（如发送钓鱼邮件）诱导用户点击包含XSS负载的链接或访问受影响的页面。
（4）窃取令牌并发起CSRF攻击：一旦用户访问受影响的页面，恶意代码被执行，CSRF令牌被发送到攻击者的服务器。攻击者可以使用该令牌构造一个伪造的请求来执行未授权的操作。
2. 会话固定攻击（Session Fixation）
会话固定攻击利用目标应用程序在同一个会话内使用相同的CSRF令牌，而没有适当地验证会话的来源。这意味着，如果攻击者可以控制或预测会话ID，就可能固定受害者的会话。
流程示例：
（1）固定会话ID：攻击者通过某种方式（例如利用一个会话固定漏洞或诱导受害者点击包含固定会话ID的链接）让受害者使用一个已知的会话ID。
（2）生成合法CSRF令牌：使用这个固定的会话ID，攻击者在自己的浏览器中访问目标网站来生成一个合法的CSRF令牌。
（3）构造恶意请求：攻击者使用固定的会话ID和获取的CSRF令牌构造一个恶意请求。
（4）执行攻击：当用户提交这个表单时，目标服务器会看到合法的CSRF令牌和会话ID，认为这是一个合法的请求，从而执行攻击者意图的操作。
3. CSRF双重提交Cookie（Double Submit Cookie）攻击
双重提交Cookie是一种防御CSRF的常见策略，要求CSRF令牌在Cookie和请求参数中同时存在，服务器验证这两个值是否一致。但是，如果网站不安全地实现了这个策略，攻击者可能会利用浏览器的SameSite Cookie策略不严格，或JavaScript可操作的Cookie漏洞来绕过CSRF防御。
流程示例：
（1）攻击者通过社交工程等方法让受害者访问一个恶意网站。
（2）恶意网站通过JavaScript设置一个与目标网站相同的Cookie名称和CSRF令牌值。
（3）当用户访问目标网站并发送请求时，目标网站会验证Cookie和请求中的CSRF令牌，但由于攻击者已提前设置了Cookie，验证将通过。
4. CSRF Token在GET请求中泄漏
某些情况下，CSRF令牌可能会被泄漏在URL中（例如通过GET参数）。如果用户访问了一个恶意网站并且CSRF令牌在Referer头中被发送，攻击者可能会通过Referer头泄漏来获取CSRF令牌。
流程示例：
（1）获取CSRF令牌URL：目标网站可能会生成一个CSRF令牌作为GET请求的一部分，（2）诱导用户点击恶意链接：攻击者诱导用户点击一个链接或打开一个页面，这个页面会加载获取的CSRF令牌URL。
（3）Referer头泄漏：用户访问攻击者页面时，浏览器会发送Referer头，其中包含前一个页面的URL。如果此URL中包含CSRF令牌，攻击者可以通过Referer头获取它。
（4）使用泄漏的令牌进行CSRF攻击：攻击者获取令牌后，可以构造一个伪造的请求，利用有效的CSRF令牌执行未经授权的操作。
5. 中间人攻击（MitM）
在未使用HTTPS的连接上，攻击者可以通过中间人攻击拦截和获取CSRF令牌。MitM攻击通常发生在不安全的网络环境中，例如公共Wi-Fi。
流程示例：
（1）拦截HTTP流量：攻击者在受害者与目标网站之间插入一个代理，并拦截所有HTTP流量。
（2）获取CSRF令牌：在受害者提交表单或请求时，攻击者可以拦截请求并提取其中的CSRF令牌。
（3）构造恶意请求：使用获取的CSRF令牌，攻击者可以伪造请求来执行未授权的操作。
6. 不正确的Token验证
一些网站可能会错误地实现CSRF令牌的验证。例如，只检查CSRF令牌的前几个字符或者使用弱的令牌生成算法，这使得攻击者有可能通过穷举或模糊测试（fuzzing）猜测到令牌。
流程示例：
（1）分析验证逻辑：攻击者通过逆向工程或监视服务器的响应，确定目标站点如何验证CSRF令牌。如果发现令牌验证仅检查前几个字符或使用容易预测的模式，攻击者可以开始构造令牌。
（2）伪造令牌：攻击者使用模糊测试工具（如Burp Suite）自动生成大量可能的令牌，并逐一测试，直到找到一个有效的。
（3）执行CSRF攻击：找到有效令牌后，攻击者可以使用它发送伪造请求，执行未经授权的操作。
7. 逻辑漏洞
某些网站的逻辑设计可能存在漏洞，例如错误地验证了同一个会话中多次提交的CSRF令牌。攻击者可以利用这种逻辑漏洞，在最初获取到令牌后反复使用它进行攻击。由于服务器逻辑漏洞，这些请求均被认为是合法的，服务器会多次执行未授权的操作。
（五）SSRF常用伪协议
为了更有效地利用SSRF漏洞，攻击者经常使用一些伪协议（或不常见的URL协议），这些伪协议可以提供访问本地文件、内存数据、或者内部服务的途径。
1. file://
该协议可以用于读取服务器上的本地文件内容，例如配置文件、密钥文件等。这在服务器允许外部URL的地方变得非常危险，因为它可以泄露敏感文件的内容。
2. dict://
该协议可以用于发起带外（OOB）的探测请求，或用于端口扫描。某些实现可能支持通过dict://协议访问任意TCP端口。
3. gopher://
该协议可以用于精确构造低层次的TCP请求，它通常用于探测和利用其他协议服务（如HTTP、SMTP、Redis等），并且能够绕过防火墙规则进行内部服务的攻击和信息泄露。
4. http://localhost 和 http://127.0.0.1
该协议通过伪造服务器请求，可以访问仅允许本地访问的管理界面或API（如监控服务、管理控制台等）。如果服务使用IP白名单或仅在本地主机上运行，则此攻击特别有效。
5. ftp://
使用FTP协议可以尝试读取服务器上可访问的文件或目录，在一些情况下，可以使用此协议访问带有默认匿名登录的FTP服务器。
6. smb://
该协议用于Windows网络共享，通过构造此类请求，可以尝试在内部网络中获取文件共享或甚至进行NTLM哈希捕获。
7. file:// UNC Paths
与smb://类似，该协议使用文件协议来访问Windows共享路径。攻击者可以尝试通过UNC路径来触发NTLM哈希认证，或访问共享文件。
8. php://
PHP伪协议提供了对输入、输出、文件操作的高级控制，攻击者可以使用这些伪协议来读取文件、编码文件、甚至执行任意代码。
9. data://
使用data://协议，攻击者可以将数据（包括任意代码）直接嵌入到URL中，一些不安全的解析逻辑可能会执行这些数据作为代码。
（六）SSRF pikachu靶场通关
1.SSRF（curl）
点击进入这一关，可以看到有一个链接
点击后，出现一个url地址，但是诗歌没有正常显示
尝试修改后面的网址，正常显示诗歌了
尝试修改URL为：url=http://www.baidu.com
成功引入了进来，这是因为网站没有对其URL进行限制，所以我们可以直接修改该网站的url，实现URL跳转。
接下来，可以尝试在这里进行手动的端口扫描，即，利用dict协议访问ip的某端口来确定该端口是否开启
比如说可以探测3306，返回了数据，说明3306端口是开启的：
再尝试探测808端口，没有返回数据，说明808端口是关闭的：
注：也可以使用Burpsuite抓包然后使用里面的扫描模块进行扫描，看那些端口开放着
2.SSRF（File_get_content）
点击进入
果然，不出所料，还是得改一下网址才能正常显示，应该是我环境配置的时候有点出入导致的，但是问题不大
此处可以注意到显示的是一个file地址
尝试使用file协议读取本地主机文件
修改file为：file=file:///D:/Bishe/haqimi/dingdongji.txt，查看文件内容
（七）SSRF靶场通关时根据源代码说明漏洞成因
1.SSRF(curl)
这一段代码首先使用$_GET['url']检测参数是否存在且不为空，然后使用curl_init()函数初始化一个cURL会话，接着用curl_exec($CH)对用户提供的URL进行请求，并获取响应内容，再通过curl_close($CH)关闭会话，最后用echo $RES输出获取的结果。
关于漏洞成因的分析：
（1）缺乏输入验证和过滤：
代码没有对$_GET['file']参数的输入进行任何验证或过滤，直接使用了用户输入，这意味着攻击者可以控制$filename的值，传入任何能够访问的URL或协议。
（2）支持多种协议可能导致的协议滥用：
curl支持多种协议，如果不限制，这会允许攻击者通过URL访问服务器内部的服务或文件。例如，使用file://协议读取本地文件，或通过http://、https://协议访问服务器内部网络中的其他服务。
（3）未验证的SSL连接：
因为curl_setopt($CH, CURLOPT_SSL_VERIFYPEER, FALSE);禁用了SSL证书验证，这可能会让攻击者利用不安全的HTTPS连接来欺骗服务器，或者中间人攻击。
2.SSRF(File_get_content)
这一部分代码使用file_get_contents()函数读取文件内容，并将获取的指定文件的内容并将其存储在变量$str中，然后将内容输出。
关于漏洞成因的分析：
（1）缺乏输入验证和过滤：
代码没有对$_GET['file']参数的输入进行任何验证或过滤，直接使用了用户输入，这意味着攻击者可以控制$filename的值，传入任何能够访问的URL或协议。
（2）使用的函数未进行任何限制：
因为file_get_contents()函数不仅可以读取本地文件，还可以处理URL，以及一些特殊的流协议（例如php://、data://），所以可以利用这个函数进行服务器端请求伪造，
也就是说，可以访问任意位置的文件或发起任意网络请求。
三、思考与总结
1.为了防止Token类CSRF攻击，应注意：
（1）将Token嵌入到每个请求中：在用户提交表单或进行敏感操作时，将Token作为请求的一部分发送（例如，作为HTTP请求头、表单字段、或URL参数）。
（2）绑定Token到用户会话：将CSRF Token与用户的会话或身份绑定，Token应当与用户的登录会话相关联，确保只有合法用户能够使用有效Token进行操作。
（3）防止Token泄露：推荐将Token放在HTTP头部或表单字段中，确保Token不通过URL传输，因为URL可能被记录在日志文件中或在浏览器历史记录中留下痕迹。
（4）定期审查和测试：定期对应用程序进行安全审查和渗透测试，确保CSRF保护措施的有效性。
2.为了防止SSRF攻击，应注意：
（1）严格验证用户输入：对所有用户输入的URL进行严格验证和过滤，只允许访问安全的、白名单中的域名和IP地址，拒绝所有不在白名单中的资源，也不要直接使用用户提供的URL或其他输入参数来执行服务器端请求，应该使用中间代理来检查和验证请求。
（2）使用防火墙或安全组：在服务器和网络层面设置防火墙或安全组，防止服务器发出对内网或敏感资源的请求。
（3）限制协议类型：确保服务器端请求只支持HTTP和HTTPS协议，禁止使用其他可能被滥用的协议。
（4）避免泄露敏感信息：在响应中避免返回敏感的内部信息或错误信息，同时设置合理的超时时间，避免服务器长时间等待外部请求，防止DoS攻击。
（5）定期安全扫描：使用自动化工具对应用进行安全扫描，定期检查和更新所有依赖库和软件组件。
扫一扫
4006
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
