目录
1.总结CSRF和XSS区别
（1）CSRF是跨站请求伪造; XSS是跨域脚本攻击。
（2）XSS 允许攻击者在受害者的浏览器上执行js代码;而CSRF 不行。
（3）XSS 通过窃取受害者的cookie 来实现账号接管，如果目标站点使用了httponly 这就行不通了:CSRF 通过浏览器发起请求，自动携带受害者的cookie信息，即使有 httponly也不影响CSRF 攻击的实现。
（4）XSS 的危害更大。攻击者如果成功实现了XSS 攻击，那通常意味着他可以使用受害者在这个网站的所有功能，而CSRF只限于特定的存在漏洞的功能。
（5）CSRF 无法让攻击者获取到服务器返回的数据，由于请求是由受害者的浏览器发起的，那么服务器的响应最后还是给到了受害者那里，攻击者是拿不到这部分数据的，所以对于一些查询类功能，即便没有做任何防御CSRF的措施，它也几乎是没有利用价值的；而 XSS 由于可以执行is代码，这也就使得攻击者可以将它想要的数据发送到自己的服务器上，比如前面XSS章中提到的回传cookie。
2.总结CSRF攻击步骤
2.1 用户登录受信任网站
用户使用浏览器打开并登录受信任的网站，输入用户名和密码，请求登录网站。用户成功登录后，网站会生成Cookie信息并返回给浏览器，以维持用户的登录状态。
2.2 浏览器保存Cookie
在用户信息通过验证后，网站的Cookie信息被保存在用户的浏览器中。这个Cookie包含了用户的会话凭证，使得浏览器在后续对网站的请求中能够自动携带Cookie进行身份验证。
2.3 用户访问恶意网站
在用户未退出网站之前，用户在同一浏览器中打开一个新的标签页或窗口，访问恶意网站。恶意网站可能是攻击者控制的网站，用于向用户发送攻击性代码或诱导用户进行某些操作。
2.4 恶意网站发送攻击性代码
恶意网站接收到用户请求后，返回一些攻击性代码，这些代码可能是隐藏的表单、脚本或其他HTML元素。这些攻击性代码通常包含指向受信任网站的请求，且该请求会在用户不知情的情况下执行。
2.5 浏览器携带Cookie发起请求
用户的浏览器在接收到恶意网站的攻击性代码后，根据这些代码的要求，自动向受信任网站发起请求，并携带了原本用于网站身份验证的Cookie。由于请求中携带了有效的Cookie，受信任网站会认为这是来自用户的合法请求，并根据该请求执行相应的操作。
2.6 网站执行恶意操作
受信任网站在接收到请求后，根据用户的Cookie信息以用户的权限处理该请求，执行一些恶意的操作，如转账、发送邮件、修改账户信息等。这些操作实际上是由攻击者通过恶意网站诱导用户浏览器发起的，但用户对此毫不知情。
2.7 防护建议
为了防御CSRF攻击，可以采取以下措施：
使用CSRF令牌：在每次用户请求中嵌入一个无法预测的CSRF令牌，并在服务器端进行验证。
设置Cookie的HttpOnly属性：确保Cookie不能通过客户端脚本（如JavaScript）被访问，减少被XSS攻击利用的风险。
验证Referer字段：对于重要的请求，可以验证HTTP请求头中的Referer字段，确保请求来自受信任的源。
定期审计和漏洞扫描：定期对网站进行安全审计和漏洞扫描，及时发现并修复潜在的安全问题。
3.总结CSRF手工构造POST型页面方法
手工构造CSRF POST型页面的方法主要涉及到创建一个HTML页面，该页面包含一个表单（form），该表单通过POST方法向目标网站发送数据。由于CSRF（跨站请求伪造）攻击是攻击者利用受害者的身份向网站发送未授权的请求，因此，在构造这样的页面时，需要特别注意表单的构造以及可能的防御措施。以下是详细步骤：
3.1 确定目标URL和参数
首先，需要明确你想要攻击的目标URL以及该URL所期望接收的POST参数。这通常可以通过分析目标网站的API文档、网络抓包（如使用Burp Suite等工具）或查看网页源代码中的表单结构来获取。
3.2 编写HTML表单
在HTML页面中，编写一个表单（form），设置其action属性为目标URL，method属性为POST。然后，根据目标URL所需的参数，在表单中添加相应的input元素，并设置其name属性为参数名，value属性为攻击者希望发送的值。示例代码如下：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>CSRF POST 攻击示例</title>
</head>
<body>
<h2>CSRF POST 攻击表单</h2>
<form action="http://example.com/target/url" method="POST" style="display:none;">
<input type="text" name="username" value="attacker_chosen_username">
<input type="text" name="password" value="attacker_chosen_password">
<input type="hidden" name="token" value="尝试猜测或绕过Token"> <!-- 如果目标URL需要Token，则需要尝试猜测或绕过 -->
<!-- 其他必要的输入项 -->
<script>
// 自动提交表单
document.forms[0].submit();
</script>
</form>
</body>
</html>注意：在实际攻击中，由于大多数现代网站都会实施CSRF防护措施（如Token验证），因此直接构造一个表单并自动提交可能无法成功。此外，style="display:none;"用于隐藏表单，以免受害者看到并产生怀疑。
3.3 考虑绕过Token验证
如果目标URL需要Token来验证请求的合法性（这是一种常见的CSRF防护措施），那么攻击者需要尝试绕过这种验证。这可能包括猜测Token值（如果Token生成算法存在漏洞）、利用浏览器的Cookie（如果Token存储在Cookie中且未设置HttpOnly标志）或通过其他漏洞（如XSS）来获取Token。
3.4 诱使用户访问页面
构造好攻击页面后，攻击者需要诱使用户访问该页面。这通常通过发送包含该页面URL的恶意链接给用户来实现，例如通过电子邮件、社交媒体消息或恶意网站上的链接。
4.说明token类CSRF利用方法
4.1 猜测Token
如果Token的生成算法不够随机或存在可预测性，攻击者可能会尝试通过暴力破解或统计分析来猜测Token的值。然而，现代系统中Token的生成通常足够复杂，使得这种方法在实际中难以成功。
4.2 窃取Token
攻击者可能会通过其他手段（如XSS攻击）来窃取用户浏览器中的Token。一旦获得Token，攻击者就可以构造CSRF请求，仿佛是由合法用户发出的。
4.3 利用未设置HttpOnly的Cookie
如果Token被存储在Cookie中，并且该Cookie没有设置HttpOnly标志，那么它可能通过客户端脚本（如JavaScript）被访问。这样，攻击者就可以通过XSS攻击来获取Token，进而发起CSRF攻击。
4.4 绕过Token验证
服务器端漏洞：如果服务器端存在安全漏洞，攻击者可能会找到绕过Token验证的方法。例如，如果服务器端没有正确验证Token的有效性，或者存在逻辑上的缺陷，攻击者可能会构造出看似合法的请求。
中间人攻击：在极端情况下，攻击者可能会通过中间人攻击来拦截和修改HTTP请求，从而绕过Token验证。然而，这种方法通常需要攻击者能够控制用户和目标服务器之间的网络流量，这在现实中是较为困难的。
4.5 防御措施
使用HttpOnly Cookie：将Token存储在设置了HttpOnly标志的Cookie中，以防止客户端脚本访问。
使用HTTPS：确保所有涉及Token的传输都通过HTTPS进行，以防止中间人攻击。
双重验证：除了Token验证外，还可以考虑实施其他形式的双重验证，如验证码、二次确认等，以增加攻击者的难度。
限制Token的使用范围：确保Token只能在特定的上下文中使用，并且具有有限的有效期。
5.SSRF常用伪协议
5.1 file://
用途：用于从文件系统中获取文件内容。
格式：file://[文件路径]。
示例：file:///etc/passwd 用于读取系统密码文件；file:///etc/hosts 显示当前操作系统网卡的IP；file:///proc/net/arp 显示ARP缓存表，用于寻找内网其他主机。
应用场景：攻击者可以利用这个伪协议读取服务器上的敏感文件，如配置文件、日志文件等。
5.2 dict://
用途：字典服务协议，用于访问字典资源。
特点：最初为UNIX和类UNIX系统设计，用于从远程服务器上查询词典或字典内容。
应用场景：攻击者可以利用此协议进行端口扫描、获取内网信息等。例如，dict://ip:6739/info 可以用来扫描目标IP的6739端口是否开放，并获取一些基本信息。
5.3 ftp:// 和 sftp://
用途：FTP（文件传输协议）和SFTP（SSH文件传输协议或安全文件传输协议）用于网络文件传输。
应用场景：尽管它们主要用于文件传输，但在SSRF攻击中，也可以被用于网络端口扫描。然而，由于FTP协议的特性（如需要长时间连接和识别请求内容），其扫描效率相对较低。
5.4 ldap://
用途：轻量级目录访问协议，用于访问目录服务。
应用场景：在SSRF攻击中，LDAP协议可以被用来探测和攻击LDAP服务器，尽管其直接利用场景相对较少，但仍是攻击者可能考虑的一种手段。
5.5 tftp://
用途：简单文件传输协议，用于在局域网内传输文件。
应用场景：虽然TFTP协议主要用于文件传输，但在某些情况下，它也可能被用于SSRF攻击中，尤其是在涉及内网资源访问时。
5.6 gopher://
用途：分布式文档传递服务协议，早期互联网上的一种文档检索协议。
特点：与HTTP类似，但更加简单和结构化。在SSRF攻击中，gopher协议因其能够构造复杂的请求而被广泛使用，包括GET和POST提交等。
应用场景：攻击者可以利用gopher协议来绕过某些限制，如HTTP协议只能构造GET请求的限制，进而对内网应用进行更深入的攻击。
5.7 http:// 和 https://
用途：超文本传输协议和安全超文本传输协议，用于互联网上的信息传输。
应用场景：在SSRF攻击中，HTTP和HTTPS协议是最常见的利用方式。攻击者可以通过构造恶意的URL来使服务器向内部或外部网络发送HTTP/HTTPS请求，进而达到攻击目的。
6.SSRF pikachu靶场通关
6.1 curl
进入SSRF(curl)界面
点击超链接，观察url的变化，发送了参数?url=http://127.0.0.1/pikachu/vul/ssrf/ssrf_info/info1.php
可以尝试修改url传递的参数：
6.1.1 通过网址访问链接
?url=http://www.baidu.com
6.1.2 利用file协议查看本地文件
?url=file:///C:/Users/Herry/Desktop/dying.txt
6.1.3 dict协议扫描内网主机开放端口
?url=dict://10.20.47.95:3306
6.2 file_get_content
进入SSRF(file_get_content)界面,要我们再来亿首，点击超链接
点击超链接，观察url的变化，发送了参数?file=http://127.0.0.1/pikachu/vul/ssrf/ssrf_info/info2.php
跟上一关类似，只不过变成了传文件
附file_get_content()的用法：PHP file_get_contents() 函数 | 菜鸟教程
可以尝试修改url传递的参数：
6.2.1 file读取本地文件
?file=file:///C:/Users/Herry/Desktop/begging.txt
6.2.2 http协议请求内网资源
?file=http://127.0.0.1/pikachu/eggshell.txt
7.SSRF靶场通关时根据源代码说明漏洞成因（加分项）
直接观察传递参数隶属于哪个文件即可
7.1 curl
分析对应文件代码，发现他没有对url参数修改做任何过滤
7.2 file_get_content
这里和上一个原因一样的，没有做参数过滤。
192
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
