目录
一、CSRF和XSS区别
CSRF和XSS都是客户端攻击,它们滥用同源策略,利用web应用程序和受害用户之间的信任关系。
但是,XSS 和 CSRF 攻击之间存在一些根本差异,包括:
-
XSS攻击遵循双向攻击模式,允许攻击者执行恶意脚本、访问响应,并将后续敏感数据发送到攻击者选择的目的地。另一方面,CSRF是一种单向攻击机制,这意味着攻击者只能发起HTTP请求,但不能检索已发起请求的响应。
-
CSRF攻击要求经过身份验证的用户处于活动会话中,而XSS攻击则不需要。在XSS攻击中,只要用户登录,就可以存储和交付有效载荷。
-
CSRF攻击的范围有限,仅限于用户可以执行的操作,例如点击恶意链接或访问黑客的网站。相反,XSS攻击提供执行恶意脚本来执行攻击者所选择的任何活动,因此攻击范围更大。
-
在XSS攻击中,恶意代码存储在站点中,而在CSRF攻击中,恶意代码存储在受害用户访问的第三方站点中。
二、总结CSRF攻击步骤
CSRF攻击的流程
-
用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A;
-
在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A;
-
用户未退出网站A之前,在同一浏览器中,打开一个TAB页访问网站B;
-
网站B接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A;
-
浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,向网站A发出请求。 网站A并不知道该请求其实是由B发起的,所以会根据用户C的Cookie信息以C的权限处理该请求,导致来自网站B的恶意代码被执行。
三、CSRF手工构造POST型页面方法
POST型的 CSRF 危害没有 GET 型的大,利用起来通常使用的是一个自动提交的表单。
访问该页面后,表单会自动提交,相当于模拟用户完成了一次 POST 操作。一般步骤如下:
1. 确定目标URL和请求参数 抓包生成 CSRF POC 首先,需要确定目标Web应用程序的URL以及POST请求所需的参数。这通常可以通过使用Burp Suite捕获post请求,然后进行分析来完成。
2. 构造HTML表单 使用HTML语言构造一个表单(form),设置表单的action属性为目标URL,method属性为POST。然后,在表单内部添加与POST请求相对应的输入字段(input),并设置其name属性与请求参数相匹配,value属性为攻击者希望提交的值。
示例代码如下:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>CSRF Attack Form</title>
</head>
<body>
<h2>CSRF Attack Form</h2>
<form action="http://example.com/target/url" method="POST">
<input type="hidden" name="param1" value="attackervalue1">
<input type="hidden" name="param2" value="attackervalue2">
<!-- 添加更多隐藏输入字段以匹配POST请求的所有参数 -->
<input type="submit" value="Submit Form">
</form>
</body>
</html>
3. 隐藏表单元素 为了使用户不易察觉,可以将表单和表单内的输入字段都设置为隐藏(通过CSS样式或直接在HTML中使用hidden属性)。这样,用户在点击诱饵链接或按钮时,实际上是在提交这个隐藏的表单。
4. 诱使用户提交表单 攻击者需要创建一个诱饵,如一个看似无害的链接或按钮,当用户点击这个诱饵时,通过JavaScript自动提交隐藏的表单。例如,可以使用以下JavaScript代码来实现:
<script>
function submitForm() {
document.forms[0].submit(); // 假设表单是页面中的第一个表单
}
</script>
<a href="javascript:void(0);" onclick="submitForm();">Click here for a free prize!</a>
四、token类CSRF利用方法
(一)Token如何防御CSRF
Token防御CSRF的核心思想是:在每次用户请求中包含一个只有用户自身才能生成或获取的随机值(Token),并在服务器端验证这个Token的有效性。以下是基于Token的CSRF防御步骤:
-
生成Token:在用户登录或会话开始时,服务器生成一个随机的Token,并将其存储在会话(Session)或用户的Cookie中。
-
传递Token:服务器将Token发送到客户端,通常是通过在HTML表单中添加一个隐藏的input字段,或者通过JavaScript将Token添加到AJAX请求的头部。
-
验证Token:每当用户提交表单或发送请求时,服务器都会检查请求中是否包含有效的Token,并且这个Token是否与服务器存储的Token相匹配。如果Token不存在、已过期或不匹配,则服务器拒绝请求。
(二)绕过Token防御进行攻击的潜在方式
虽然基于Token的CSRF防御机制相对强大,但攻击者仍可能尝试以下方法来绕过这些防御:
-
窃取Token:如果攻击者能够获取到用户的Cookie(例如,通过XSS攻击),那么他们就可以窃取到存储在Cookie中的Token,并使用它来进行CSRF攻击。
-
预测Token:对于某些简单的Token生成算法,如果它们不是足够随机或可预测性较高,攻击者可能会尝试预测Token的值。然而,现代Web应用程序通常使用强随机数生成器来创建Token,因此这种方法在实践中并不常见。
-
会话固定攻击:攻击者可能会尝试设置一个已知的Token值,并诱使用户登录或执行其他操作,从而将该已知Token与用户会话相关联。然而,通过确保每次会话开始时都生成新的Token,并销毁旧的Token,可以有效地防止这种攻击。
-
利用CORS策略:如果Web应用程序的CORS(跨源资源共享)策略配置不当,攻击者可能会尝试从其他域发送包含伪造Token的请求。因此,正确配置CORS策略对于防止CSRF攻击至关重要。
五、SSRF常用伪协议
1. file://
该协议用于从文件系统中获取文件内容。
格式:file://[文件路径]。例如,输入file:///etc/passwd,可
读取/etc/passwd文件,从而获取系统上的用户信息。
2. dict://
该协议为字典服务协议,用于访问字典资源或进行端口扫描。
格式:dict://[ip]:[端口]/[资源]例如,dict://172.100.250.1:80/info,
可用于扫描该IP地址的80端口是否开放,或尝试获取其他字典资源。
3. ftp:// 和 sftp://
FTP (文件传输协议) 和 SFTP (安全文件传输协议) 可以用来读取任意系统文件,也可用于网络端口扫描,但效率相对较低。格式:
ftp(或sftp)://[用户名]:[密码]@[服务器地址]:[端口]/[文件路径]
4. ldap://
该协议为轻量级目录访问协议,用于访问和维护分布式目录信息服务的协议。
格式:ldap://[服务器地址]:[端口]/[路径]。
5. tftp://
该协议为简单文件传输协议,用于在网络中传输小型文件。
格式:tftp://[服务器地址]:[端口]/[文件路径]
6. gopher://
分布式文档传递服务协议,可用于GET和POST提交以,也可与其他协议(如Redis、SQL)结合进行复杂攻击。
格式:gopher://<目标IP>:<端口>/<gopher-path>
这里要注意,使用gopher协议时,会吃掉第一个字符,因此在构造请求时需要在URL首位填充一个无用的字符(如下下划线)。
7. http:// 和 https://
是最常用到的协议。虽然HTTP和HTTPS不是伪协议,但在SSRF攻击中经常被利用来向目标服务器发送HTTP请求,从而验证是否存在SSRF漏洞,探测端口以及服务。
六、SSRF pikachu靶场通关
1. SSRF(curl)
进入关卡,看到一个链接,点击链接。
发现出现了一个url地址url=http://127.0.0.1:83/vul/ssrf/ssrf_info/info1.php
因为curl支持很多协议,我们就可以做以下尝试:
1) 通过网址访问链接
比如说修改url为:url=http://www.baidu.com
,访问百度页面:
2) 利用file协议查看本地文件
修改url为:url=file:///d:/test.txt
,查看文件的内容:
3) dict协议扫描内网主机开放端口
使用dict协议可以获取内网主机开放端口相应服务的指纹信息,比如说内网主机开了http端口的话, 可以修改url为:url=dict://127.0.0.1:83
:
2.SSRF(file_get_content)
和上一关类似,但 url 变成了file。
1) 利用file协议读取本地文件
修改file为:file=file:///D:/test.txt,查看文件的内容:
2) 利用http协议请求内网资源
修改file为:file=http://127.0.0.1:83/test.txt 查看文件的内容:
七、SSRF靶场根据源代码说明漏洞成因
SSRF形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制,导致攻击者可以传入任意的地址,来让后端服务器对其发起请求,并返回对该目标地址请求的数据。
攻击时数据流由攻击者传给服务器,服务器访问目标地址获取数据,再传给攻击者,造成信息泄露。
根据后台使用的函数的不同,对应的影响和利用方法又有不一样。
分析第一关源代码:
代码中使用了危险函数 curl_exec() ,前端传进来的 url 被后台使用 curl_exec() 进行了请求,然后将请求的结果又返回给了前端。由于未对 url 进行检查和限制,因此形成了SSRF漏洞,攻击者可轻易访问隐私链接和数据。
再分析第二关源代码:
第二关使用的是file_get_contents() 函数,该函数将指定 URL 的文件读入一个字符串并返回。代码中同样未对输入进行过滤,造成漏洞。