在本节中，将解释什么是跨站请求伪造（CSRF），描述一些常见的CSRF漏洞示例，并解释如何防止CSRF攻击。
CSRF令牌不绑定到用户会话
某些应用程序不会验证令牌与发出请求的用户是否属于同一会话，相反，应用程序维护它已发布的全局令牌池，并接受该池中出现的任何令牌。
在这种情况下，攻击者可以使用自己的账号登录应用程序，获取有效令牌，然后在CSRF攻击中将攻击令牌提供给受害用户。
场景试验-不绑定到用户会话的CSRF：
https://portswigger.net/web-security/csrf/lab-token-not-tied-to-user-session
场景说明：
这个试验场景的电子邮件更改功能易受到CSRF攻击，它使用令牌来尝试防止CSRF攻击，但是他们没有集成到站点的会话处理系统中。
试验目的：
要完成这个试验，需要使用漏洞利用服务器托管一个HTML页面，该页面使用CSRF攻击来更改查看者的电子邮件地址，场景提供了两个可供使用的账号wiener:peter、carlos:montoya
攻击过程：
①打开页面后访问"My account"，用提供的账号和密码进行登录后修改下邮箱。
②到Burp Suite中找到改邮箱的请求，右键点击后从菜单中选择"Generate CSRF PoC"
③将Burp Suite设置成阻断模式，在页面上再次提交修改邮件的请求，把这次请求中的csrf复制出来，因为每个CSRF令牌只能使用一次，因此放弃这个请求包
④将这个CSRF令牌复制到CSRF PoC中进行替换，并在"Options"中勾选"Include auto-submit script"，随后点击"Regenerate"生成新的CSRF HTML，再点击"Copy HTML"
⑤打开"exploit server"，把CSRF HTML粘贴到Body中，点击"Store"，并发送给受害者，完成试验
试验小结：
这种场景要注意的是，CSRF令牌由于只能使用一次，因此一定在截取有效令牌时将请求数据包丢弃，这样就可以获得一个可用的令牌。
CSRF令牌绑定到非会话cookie
在上述漏洞的一个变体中，一些应用程序确实将CSRF令牌绑定到一个cookie，但没有绑定到用于跟踪会话的同一个cookie。
当应用程序使用两个不同的框架时，很容易发生这种情况，一个用于会话处理，一个用于CSRF保护，但它们没有集成在一起：
这种情况更难利用，但仍然很脆弱。如果网站包含任何允许攻击者在受害者浏览器中设置cookie的行为，那么就有可能发生攻击。
攻击者可以使用自己的账户登录应用程序，获取有效的令牌和关联的cookie，利用cookie设置行为将其cookie放入受害者的浏览器，并在CSRF攻击中将其令牌提供给受害者。
场景试验-令牌绑定到非会话cookie的CSRF：
https://portswigger.net/web-security/csrf/lab-token-tied-to-non-session-cookie
场景说明：
这个试验场景的电子邮件更改功能易受到CSRF攻击，它使用令牌来尝试防止CSRF攻击，但是他们没有集成到站点的会话处理系统中。
试验目的：
要完成这个试验，需要使用漏洞利用服务器托管一个HTML页面，该页面使用CSRF攻击来更改查看者的电子邮件地址，场景提供了两个可供使用的账号wiener:peter、carlos:montoya
攻击过程：
①先用wiener这个账号登录，进去后修改下邮箱，将修改邮箱的请求发送到Repeater，可以看到在cookie区域多了一个csrfkey的参数
②随后另外再开个浏览器（隐私模式），用carlos:montoya这个账号登录，通过抓包可以获取到这个这个账号的csrfkey和csrf
③接下来将carlos这个账号获取到的csrfkey和csrf分别替换到wiener那个更改邮箱的请求，可以看到如果只替换其中一个的话，都会请求失败，但如果两个都进行替换的话，就可以改邮件成功，说明CSRF令牌并没有跟cookie绑定
④接着要想办法修改受害者的csrfkey，因为这部分是包含在cookie里面的，我们通过在首页上的"search"功能可以看到，最近次搜索会返回在响应包中
⑤利用这个特性，我们构建如下payload语句（注意替换下csrfkey），可以看到响应包可以让客户端重新设置了cookie
/?search=test%0d%0aSet-Cookie:%20csrfKey=your-key
⑥将经过改造（替换了csrf和csrfkey）的改密请求右键点击后从菜单中选择"Generate CSRF PoC"
⑦在弹出的CRSF配置框中，"Options"中勾选"Include auto-submit script"，随后点击"Regenerate"生成新的CSRF HTML，并删除script区域，插入下面新的语句（用来更改受害者的csrfkey），再点击"Copy HTML"
<img src="$cookie-injection-url" onerror="document.forms[0].submit()">
⑧打开"exploit server"，把CSRF HTML粘贴到Body中，点击"Store"，并发送给受害者，完成试验
试验小结：
这个场景比较关键的就是如何在受害者的cookie位置进行注入，cookie注入行为甚至不需要与CSRF漏洞存在于同一个Web应用程序中，如果受控制的cookie具有合适的范围，则可以利用同一整体DNS域中的任何其他应用程序在目标应用程序中设置cookie。
CSRF令牌只是在cookie中复制
在上述漏洞的进一步变体中，一些应用程序不维护任何已发布令牌的服务器端记录，而是在cookie和请求参数中复制每个令牌。验证后续请求时，应用程序只需验证请求参数中提交的令牌与cookie中提交的值是否匹配。
这有时被称为针对CSRF的“双重提交”防御，并且被提倡是因为它易于实现并且避免了对服务器端状态的需要，比如下面这个请求：
在这种情况下，如果网站包含任何cookie设置功能，攻击者可以再次执行CSRF攻击。
在这里，攻击者不需要获取自己的有效令牌，他们只是发明了一个令牌（格式上可能要求一致），利用cookie设置行为将他们的cookie注入受害者的浏览器，并在他们的CSRF攻击中将他们的令牌提供给受害者。
场景试验-令牌在cookie中重复：
https://portswigger.net/web-security/csrf/lab-token-duplicated-in-cookie
场景说明：
这个试验场景的电子邮件更改功能易受到CSRF攻击，它试图使用不安全的“双重提交”CSRF预防技术。
试验目的：
要完成这个试验，需要使用漏洞利用服务器托管一个HTML页面，该页面使用CSRF攻击来更改查看者的电子邮件地址，场景提供了可供使用的账号wiener:peter。
攻击过程：
①用wiener账号进行登录，随后修改邮箱，将这个请求发送给Repeater，可以看到csrf在cookie也出现了，并且两个csrf参数一样
②修改下这两处的csrf，发现只要一致，请求就可以成功
③接着要想办法修改受害者的cookie中的csrf，因为这部分是包含在cookie里面的，我们通过在首页上的"search"功能可以看到，最近次搜索会返回在响应包中
④利用这个特性，我们构建如下payload语句（csrf的参数要用一致的），可以看到响应包可以让客户端重新设置了cookie
/?search=test%0d%0aSet-Cookie:%20csrf=your-key
⑤将经过改造（修改了两个csrf值）的改密请求右键点击后从菜单中选择"Generate CSRF PoC"，在弹出的CRSF配置框中，增加下面新的语句（用来更改受害者cookie中的csrf），再点击"Copy HTML"
<img src="$cookie-injection-url" onerror="document.forms[0].submit()">
⑥打开"exploit server"，把CSRF HTML粘贴到Body中，点击"Store"，并发送给受害者，完成试验
试验小结：
这个试验场景中，只要所有的CSRF值都相同即可，因此都采用test来作为这个值，同时也说明这个应用程序对CSRF值的格式并没有要求。
SQL注入攻击-检索隐藏的数据
HTTP Host头漏洞攻击-概念梳理
原文始发于微信公众号（H君网安白话）：跨站请求伪造（CSRF）-攻击示例（二）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论