burp靶场--CSRF
burp靶场–CSRF
https://portswigger.net/web-security/csrf#what-is-csrf
### 什么是 CSRF？
跨站请求伪造（也称为 CSRF）是一种 Web 安全漏洞，允许攻击者诱导用户执行他们不打算执行的操作。它允许攻击者部分规避同源策略，该策略旨在防止不同网站相互干扰。
### CSRF 攻击会产生什么影响？
在成功的 CSRF 攻击中，攻击者会导致受害用户无意中执行某项操作。例如，这可能是更改其帐户上的电子邮件地址、更改其密码或进行资金转账。根据操作的性质，攻击者可能能够完全控制用户的帐户。如果受感染的用户在应用程序中具有特权角色，那么攻击者可能能够完全控制应用程序的所有数据和功能。
### CSRF 是如何工作的？
要实现 CSRF 攻击，必须满足三个关键条件：
相关行动。攻击者有理由诱发应用程序内的某个操作。这可能是特权操作（例如修改其他用户的权限）或对用户特定数据的任何操作（例如更改用户自己的密码）。
基于 Cookie 的会话处理。执行该操作涉及发出一个或多个 HTTP 请求，并且应用程序仅依赖会话 cookie 来识别发出请求的用户。没有其他机制可以跟踪会话或验证用户请求。
没有不可预知的请求参数。执行操作的请求不包含攻击者无法确定或猜测其值的任何参数。例如，当导致用户更改密码时，如果攻击者需要知道现有密码的值，则该功能不易受到攻击。
例如，假设应用程序包含一个允许用户更改其帐户上的电子邮件地址的功能。当用户执行此操作时，他们会发出如下 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 protected]
这满足了CSRF所需的条件：
攻击者会对更改用户帐户上的电子邮件地址的操作感兴趣。执行此操作后，攻击者通常能够触发密码重置并完全控制用户的帐户。
应用程序使用会话 cookie 来识别发出请求的用户。没有其他令牌或机制来跟踪用户会话。
攻击者可以轻松确定执行操作所需的请求参数的值。
具备这些条件后，攻击者就可以构建包含以下 HTML 的网页：
<html>
<body>
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="[email protected]" />
form>
<script>
document.forms[0].submit();
script>
body>
html>
如果受害者用户访问攻击者的网页，将会发生以下情况：
攻击者的页面将触发对易受攻击的网站的 HTTP 请求。
如果用户登录到易受攻击的网站，他们的浏览器将自动在请求中包含其会话 cookie（假设未使用 SameSite cookie ）。
易受攻击的网站将以正常方式处理该请求，将其视为由受害用户发出，并更改他们的电子邮件地址。
### 如何构建CSRF攻击
手动创建 CSRF 漏洞所需的 HTML 可能很麻烦，特别是在所需的请求包含大量参数或请求中存在其他怪癖的情况下。构建 CSRF 漏洞的最简单方法是使用Burp Suite Professional内置的CSRF PoC 生成器：
在 Burp Suite Professional 中的任意位置选择您想要测试或利用的请求。
从右键单击上下文菜单中，选择参与工具/生成 CSRF PoC。
Burp Suite 将生成一些 HTML 来触发所选请求（减去 cookie，这些 cookie 将由受害者的浏览器自动添加）。
您可以调整 CSRF PoC 生成器中的各种选项来微调攻击的各个方面。在某些不寻常的情况下，您可能需要执行此操作，以处理请求的奇怪功能。
将生成的 HTML 复制到网页中，在登录到存在漏洞的网站的浏览器中查看，并测试是否成功发出预期请求以及是否发生所需操作。
### 如何实施 CSRF 漏洞利用
跨站点请求伪造攻击的传递机制本质上与反射型 XSS 相同。通常，攻击者会将恶意 HTML 放置到他们控制的网站上，然后诱导受害者访问该网站。这可以通过电子邮件或社交媒体消息向用户提供网站链接来完成。或者，如果攻击发生在流行的网站中（例如，在用户评论中），他们可能只是等待用户访问该网站。
请注意，一些简单的 CSRF 漏洞利用 GET 方法，并且可以完全独立于易受攻击的网站上的单个 URL。在这种情况下，攻击者可能不需要使用外部站点，并且可以直接向受害者提供易受攻击域上的恶意 URL。在前面的示例中，如果可以使用 GET 方法执行更改电子邮件地址的请求，那么独立攻击将如下所示：
<img src="https://vulnerable-website.com/email/[email protected]">
### 针对 CSRF 的常见防御
如今，成功查找和利用 CSRF 漏洞通常需要绕过目标网站、受害者浏览器或两者部署的反 CSRF 措施。您将遇到的最常见的防御如下：
CSRF 令牌- CSRF 令牌是由服务器端应用程序生成并与客户端共享的唯一、秘密且不可预测的值。当尝试执行敏感操作（例如提交表单）时，客户端必须在请求中包含正确的 CSRF 令牌。这使得攻击者很难代表受害者构建有效的请求。
SameSite cookie - SameSite 是一种浏览器安全机制，用于确定何时将网站的 cookie 包含在源自其他网站的请求中。由于执行敏感操作的请求通常需要经过身份验证的会话 cookie，因此适当的 SameSite 限制可能会阻止攻击者跨站点触发这些操作。自 2021 年起，ChromeLax默认强制执行 SameSite 限制。由于这是提议的标准，我们预计其他主要浏览器将来也会采用这种行为。
基于 Referer 的验证- 某些应用程序使用 HTTP Referer 标头来尝试防御 CSRF 攻击，通常是通过验证请求是否源自应用程序自己的域。这通常不如 CSRF 令牌验证有效。
有关每种防御措施的更详细描述以及如何绕过它们，请查看以下材料。其中包括交互式实验室，可让您在现实的、故意易受攻击的目标上练习所学知识。
实验1:无防御措施的 CSRF 漏洞
### 实验要求：
该实验室的电子邮件更改功能容易受到 CSRF 的攻击。
为了解决这个实验室问题，请制作一些 HTML，使用CSRF 攻击来更改查看者的电子邮件地址并将其上传到您的漏洞利用服务器。
您可以使用以下凭据登录您自己的帐户：wiener:peter
### 实验操作：
打开 Burp 的浏览器并登录您的帐户。提交“更新电子邮件”表单，并在您的代理历史记录中找到生成的请求。
如果您使用的是Burp Suite Professional，请右键单击请求并选择参与工具/生成 CSRF PoC。启用包含自动提交脚本的选项，然后单击“重新生成”。
或者，如果您使用的是Burp Suite Community Edition，请使用以下 HTML 模板。您可以通过右键单击并选择“复制 URL”来获取请求 URL。
<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="anything%40web-security-academy.net">
form>
<script>
document.forms[0].submit();
script>
转到漏洞利用服务器，将漏洞利用 HTML 粘贴到“正文”部分，然后单击“存储”。
要验证该漏洞是否有效，请通过单击“查看漏洞”自行尝试，然后检查生成的 HTTP 请求和响应。
更改漏洞利用中的电子邮件地址，使其与您自己的电子邮件地址不匹配。
单击“交付给受害者”以解决实验室问题。
保存为html代码，然后托管到可控的攻击者服务器上，最后将html链接发送给受害者等待受害者点击响应：
托管到攻击者服务器，模拟受害者点击链接：
实验2:CSRF中令牌验证取决于请求方法【请求方法绕过csrf 令牌校验】
### 实验要求：
该实验室的电子邮件更改功能容易受到 CSRF 的攻击。它尝试阻止 CSRF 攻击，但仅对某些类型的请求进行防御。
要完成该实验，请使用您的漏洞利用服务器托管一个 HTML 页面，该页面使用CSRF 攻击来更改查看者的电子邮件地址。
您可以使用以下凭据登录您自己的帐户：wiener:peter
### 实验操作：
打开 Burp 的浏览器并登录您的帐户。提交“更新电子邮件”表单，并在您的代理历史记录中找到生成的请求。
将请求发送到 Burp Repeater 并观察，如果更改参数的值，csrf则请求将被拒绝。
使用上下文菜单上的“更改请求方法”将其转换为 GET 请求，并观察 CSRF 令牌不再经过验证。
如果您使用的是Burp Suite Professional，请右键单击请求，然后从上下文菜单中选择参与工具/生成 CSRF PoC。启用包含自动提交脚本的选项，然后单击“重新生成”。
或者，如果您使用的是Burp Suite Community Edition，请使用以下 HTML 模板。您可以通过右键单击并选择“复制 URL”来获取请求 URL。
转到漏洞利用服务器，将漏洞利用 HTML 粘贴到“正文”部分，然后单击“存储”。
要验证该漏洞是否有效，请通过单击“查看漏洞”并检查生成的 HTTP 请求和响应来亲自尝试。
更改漏洞利用中的电子邮件地址，使其与您自己的电子邮件地址不匹配。
存储漏洞，然后单击“交付给受害者”以解决实验室问题。
实验3:CSRF中令牌验证取决于令牌是否存在
### 实验要求：
该实验室的电子邮件更改功能容易受到 CSRF 的攻击。
要完成该实验，请使用您的漏洞利用服务器托管一个 HTML 页面，该页面使用CSRF 攻击来更改查看者的电子邮件地址。
您可以使用以下凭据登录您自己的帐户：wiener:peter
### 实验操作：
打开 Burp 的浏览器并登录您的帐户。提交“更新电子邮件”表单，并在您的代理历史记录中找到生成的请求。
将请求发送到 Burp Repeater 并观察，如果更改参数的值，csrf则请求将被拒绝。
完全删除该csrf参数并观察请求现在已被接受。
如果您使用的是Burp Suite Professional，请右键单击请求，然后从上下文菜单中选择参与工具/生成 CSRF PoC。启用包含自动提交脚本的选项，然后单击“重新生成”。
或者，如果您使用的是Burp Suite Community Edition，请使用以下 HTML 模板。您可以通过右键单击并选择“复制 URL”来获取请求 URL。
<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="$param1name" value="$param1value">
form>
<script>
document.forms[0].submit();
script>
转到漏洞利用服务器，将漏洞利用 HTML 粘贴到“正文”部分，然后单击“存储”。
要验证该漏洞是否有效，请通过单击“查看漏洞”并检查生成的 HTTP 请求和响应来亲自尝试。
更改漏洞利用中的电子邮件地址，使其与您自己的电子邮件地址不匹配。
存储漏洞，然后单击“交付给受害者”以解决实验室问题。
实验4:CSRF中令牌不与用户会话绑定
自己注册两个账户，在csrf没有绑定到用户会话的功能：如修改邮验证存在csrf 替换，以使用自己账户请求的csrf token给任意账户使用，造成了csrf攻击。
### 实验要求：
该实验室的电子邮件更改功能容易受到 CSRF 的攻击。它使用令牌来尝试防止 CSRF 攻击，但它们没有集成到站点的会话处理系统中。
要完成该实验，请使用您的漏洞利用服务器托管一个 HTML 页面，该页面使用CSRF 攻击来更改查看者的电子邮件地址。
您在应用程序上有两个帐户，可用于帮助设计攻击。凭证如下：
wiener:peter
carlos:montoya
### 实验操作：
打开 Burp 的浏览器并登录您的帐户。提交“更新电子邮件”表单，并拦截生成的请求。
记下 CSRF 令牌的值，然后删除请求。
打开私人/隐身浏览器窗口，登录到您的其他帐户，然后将更新电子邮件请求发送到 Burp Repeater。
请注意，如果您将 CSRF 令牌与其他帐户的值交换，则请求将被接受。
创建并托管概念验证漏洞利用，如CSRF 漏洞解决方案中所述，无需防御实验室。请注意，CSRF 令牌是一次性的，因此您需要添加一个新的令牌。
更改漏洞利用中的电子邮件地址，使其与您自己的电子邮件地址不匹配。
存储漏洞，然后单击“交付给受害者”以解决实验室问题。
A账户：wiener:peter
B账户：carlos:montoya
将生成的csrf poc放置于自己控制的web服务器上，模拟攻击目标站点的其他用户：
注意：CSRF令牌是一次性的，因此需要添加一个新令牌，刷新页面再次请求，就是新的了
实验5:CSRF中令牌与非会话cookie绑定
### 实验要求：
该实验室的电子邮件更改功能容易受到 CSRF 的攻击。它使用令牌来尝试防止 CSRF 攻击，但它们并未完全集成到站点的会话处理系统中。
要完成该实验，请使用您的漏洞利用服务器托管一个 HTML 页面，该页面使用CSRF 攻击来更改查看者的电子邮件地址。
您在应用程序上有两个帐户，可用于帮助设计攻击。凭证如下：
wiener:peter
carlos:montoya
### 使用操作：
打开 Burp 的浏览器并登录您的帐户。提交“更新电子邮件”表单，并在您的代理历史记录中找到生成的请求。
将请求发送到 Burp Repeater 并观察到更改sessioncookie 会使您退出，但更改csrfKeycookie 只会导致 CSRF 令牌被拒绝。这表明csrfKeycookie 可能并未与会话严格绑定。
打开私人/隐身浏览器窗口，登录到您的其他帐户，然后将新的更新电子邮件请求发送到 Burp Repeater。
请注意，如果您将csrfKeycookie 和csrf参数从第一个帐户交换到第二个帐户，则请求将被接受。
关闭中继器选项卡和隐身浏览器。
返回原始浏览器，执行搜索，将结果请求发送到 Burp Repeater，并观察搜索词是否反映在 Set-Cookie 标头中。由于搜索功能没有 CSRF 保护，因此您可以使用它向受害用户的浏览器中注入 cookie。
创建一个 URL，利用此漏洞将您的csrfKeycookie 注入受害者的浏览器中：
/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None
创建并托管概念验证漏洞利用，如CSRF 漏洞解决方案中所述，无需防御实验室，确保包含 CSRF 令牌。应根据电子邮件更改请求创建漏洞利用程序。
删除自动提交
自行存储和查看漏洞利用程序。
请注意，当发生客户端重定向时，您仍然会看到登录帐户页面。这确认了浏览器在第二个请求中包含了经过身份验证的会话 cookie，即使最初的评论提交请求是从任意外部站点发起的。
创造一个漏洞
将POST /my-account/change-email请求发送到 Burp Repeater。
在 Burp Repeater 中，右键单击请求并选择Change request method。Burp 自动生成等效GET请求。
发送请求。请注意，端点允许您使用GET请求更改您的电子邮件地址。
返回漏洞利用服务器并更改漏洞postId利用中的参数，以便重定向导致浏览器发送GET更改电子邮件地址的等效请求：
请注意，您需要包含参数并对“&”分隔符进行 URL 编码，以避免在初始设置请求中 submit破坏参数。postId
自行测试漏洞并确认您已成功更改电子邮件地址。
更改漏洞利用中的电子邮件地址，使其与您自己的电子邮件地址不匹配。
将漏洞利用程序传递给受害者。几秒钟后，实验室就解决了。
实验9:SameSite通过同级域严格绕过【略…】
实验10:通过cookie刷新绕过SameSite Lax【略…】
### 实验要求：
该实验室的更改电子邮件功能容易受到 CSRF 的攻击。要解决该实验室问题，请执行CSRF 攻击，更改受害者的电子邮件地址。您应该使用提供的漏洞利用服务器来托管您的攻击。
该实验室支持基于 OAuth 的登录。您可以使用以下凭据通过社交媒体帐户登录：wiener:peter
### 实验操作：
研究一下更改邮箱功能
在 Burp 的浏览器中，通过您的社交媒体帐户登录并更改您的电子邮件地址。
在 Burp 中，转到代理 > HTTP 历史记录选项卡。
研究该POST /my-account/change-email请求并注意它不包含任何不可预测的令牌，因此如果您可以绕过任何 SameSite cookie 限制，则可能容易受到 CSRF 的攻击。
查看OAuthGET /oauth-callback?code=[...]流程末尾的请求 响应。请注意，网站在设置会话 cookie 时没有明确指定任何 SameSite 限制。因此，浏览器将使用默认的限制级别。 Lax
尝试CSRF 攻击
在浏览器中，转到漏洞利用服务器。
使用以下模板创建基本的 CSRF 攻击以更改受害者的电子邮件地址：
自行存储和查看漏洞利用程序。接下来发生的情况取决于您登录后经过的时间：
如果超过两分钟，您将通过 OAuth 流程登录，攻击将失败。在这种情况下，请立即重复此步骤。
如果您在不到两分钟前登录，则攻击成功并且您的电子邮件地址被更改。从“代理”>“HTTP 历史记录”选项卡中，找到该POST /my-account/change-email请求并确认包含您的会话 cookie，即使这是跨站点POST请求。
绕过 SameSite 限制
请注意，在浏览器中，如果您访问/social-login，这会自动启动完整的 OAuth 流程。如果您仍然与 OAuth 服务器有登录会话，则这一切都会在没有任何交互的情况下发生。
从代理历史记录中，请注意，每次完成 OAuth 流程时，目标站点都会设置一个新的会话 cookie，即使您已经登录也是如此。
返回到漏洞利用服务器。
更改 JavaScript，以便攻击首先通过强制受害者的浏览器访问 来刷新受害者的会话/social-login，然后在短暂暂停后提交电子邮件更改请求。以下是一种可能的方法：
请注意，我们已在新窗口中打开/social-login，以避免在发送更改电子邮件请求之前离开漏洞利用程序。
自行存储和查看漏洞利用程序。请注意，初始请求被浏览器的弹出窗口阻止程序阻止。
观察发现，暂停之后，CSRF 攻击仍然发起。但是，只有在您的 cookie 设置后不到两分钟时，此操作才会成功。如果不是，攻击就会失败，因为弹出窗口阻止程序会阻止强制 cookie 刷新。
绕过弹出窗口拦截器
请注意，弹出窗口被阻止是因为您尚未手动与该页面交互。
调整该漏洞，使其诱导受害者单击页面，并且仅在用户单击后才打开弹出窗口。以下是一种可能的方法：
Click anywhere on the page
再次测试对自己的攻击，同时监视 Burp 中的代理历史记录。
出现提示时，单击该页面。这会触发 OAuth 流程并向您发出新的会话 cookie。5 秒后，请注意 CSRF 攻击已发送，并且请求POST /my-account/change-email包含您的新会话 cookie。
转到您的帐户页面并确认您的电子邮件地址已更改。
更改漏洞利用中的电子邮件地址，使其与您自己的电子邮件地址不匹配。
将漏洞发送给受害者以解决实验室问题。
实验11:CSRF中Referer验证取决于标头是否存在
### 实验要求：
该实验室的电子邮件更改功能容易受到 CSRF 的攻击。它尝试阻止跨域请求，但有不安全的回退。
要完成该实验，请使用您的漏洞利用服务器托管一个 HTML 页面，该页面使用CSRF 攻击来更改查看者的电子邮件地址。
您可以使用以下凭据登录您自己的帐户：wiener:peter
### 实验操作：
打开 Burp 的浏览器并登录您的帐户。提交“更新电子邮件”表单，并在您的代理历史记录中找到生成的请求。
将请求发送到 Burp Repeater 并观察，如果更改 Referer HTTP 标头中的域，则请求将被拒绝。
完全删除 Referer 标头并观察请求现在已被接受。
创建并托管概念验证漏洞利用，如CSRF 漏洞解决方案中所述，无需防御实验室。包含以下 HTML 以抑制 Referer 标头：
更改漏洞利用中的电子邮件地址，使其与您自己的电子邮件地址不匹配。
存储漏洞，然后单击“交付给受害者”以解决实验室问题。
构造poc:
<meta name="referrer" content="no-referrer">
<html>
<body>
<form action="https://0a4d0059039e793e803d71db00c30038.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="aabbaaa1@test.com" />
<input type="submit" value="Submit request" />
form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
script>
body>
html>
将恶意的html托管到自己控制的web服务器上：
实验12:引用验证失效的CSRF
### 实验要求：
该实验室的电子邮件更改功能容易受到 CSRF 的攻击。它尝试检测并阻止跨域请求，但检测机制可以被绕过。
要完成该实验，请使用您的漏洞利用服务器托管一个 HTML 页面，该页面使用CSRF 攻击来更改查看者的电子邮件地址。
您可以使用以下凭据登录您自己的帐户：wiener:peter
### 实验操作：
打开 Burp 的浏览器并登录您的帐户。提交“更新电子邮件”表单，并在您的代理历史记录中找到生成的请求。
将请求发送到 Burp Repeater。请注意，如果更改 Referer HTTP 标头中的域，请求将被拒绝。
复制实验室实例的原始域并将其以查询字符串的形式附加到 Referer 标头。结果应该是这样的：
Referer: https://arbitrary-incorrect-domain.net?YOUR-LAB-ID.web-security-academy.net
发送请求并观察该请求现在已被接受。该网站似乎接受任何 Referer 标头，只要它在字符串中的某处包含预期的域即可。
创建 CSRF 概念验证漏洞，如CSRF 漏洞解决方案中所述，无需防御实验室，并将其托管在漏洞利用服务器上。编辑 JavaScript，使函数的第三个参数history.pushState()包含带有您的实验室实例 URL 的查询字符串，如下所示：
history.pushState("", "", "/?YOUR-LAB-ID.web-security-academy.net")
这将导致生成的请求中的 Referer 标头在查询字符串中包含目标站点的 URL，就像我们之前测试的那样。
如果您存储漏洞并通过单击“查看漏洞”进行测试，您可能会再次遇到“无效的 Referer header”错误。这是因为作为安全措施，许多浏览器现在默认从 Referer 标头中删除查询字符串。要覆盖此行为并确保请求中包含完整的 URL，请返回漏洞利用服务器并将以下标头添加到“Head”部分：
Referrer-Policy: unsafe-url
请注意，与普通的 Referer 标头不同，在这种情况下，“referrer”一词必须拼写正确。
更改漏洞利用中的电子邮件地址，使其与您自己的电子邮件地址不匹配。
存储漏洞，然后单击“交付给受害者”以解决实验室问题。
发送请求到BP repeater。如果更改Referer HTTP头中的域，则请求将被拒绝
复制实验实例的原始域，并将其以查询字符串的形式附加到Referer头中
Referer: https://arbitrary-incorrect-domain.net?YOUR-LAB-ID.web-security-academy.net
我的是：
Referer: https://arbitrary-incorrect-domain.net?0a7a001f0362b892808edae400210029.web-security-academy.net
生成相关的poc:
并将其托管在攻击服务器上。编辑JavaScript，使history.pushState()函数的第三个参数包含一个查询字符串，其中包含实验室实例URL，如下所示：
history.pushState(“”, “”, “/?YOUR-LAB-ID.web-security-academy.net”)
我的是：
history.pushState(“”, “”, “/?https://0a7a001f0362b892808edae400210029.web-security-academy.net”)
最终poc:
<html>
<body>
<form action="https://0a7a001f0362b892808edae400210029.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="bbbaaa@test.com" />
<input type="submit" value="Submit request" />
form>
<script>
history.pushState("", "", "/?https://0a7a001f0362b892808edae400210029.web-security-academy.net");
document.forms[0].submit();
script>
body>
html>
如果存储该利用漏洞攻击并通过单击"查看利用漏洞攻击"进行测试，则可能会再次遇到"invalid Referer header"错误。这是因为作为一种安全措施，许多浏览器现在默认从Referer头中剥离查询字符串。要覆盖此行为并确保请求中包含完整的URL，请返回利用漏洞攻击服务器并将以下标题添
加到"Head"部分：
Referrer-Policy: unsafe-url
（注意，与普通的Referer头不同）
参考：
### CSRF(跨站请求伪造)与Cookie的SameSite属性
https://blog.csdn.net/weixin_50464560/article/details/119579825
### portswigger官方csrf:
https://portswigger.net/web-security/csrf
### 【Burp系列】超全CSRF请求伪造漏洞实验总结
https://mp.weixin.qq.com/s/J9bAu98qATpnhoONT4fUkw
### owasp跨站请求伪造：
https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery
### PayloadsAllTheThings：CSRF
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CSRF%20Injection