以下为CSRF中token篇

---

第四关-token未与session绑定

实验的名字为

Lab: CSRF where token is not tied to user session

大概意思就是说当前token并未与当前用户的session绑定在一起

给了两个账号，就是来在本地验证，token并未与session绑定

现在登陆的是A用户

先登录一个用户，使用bp抓取修改邮箱的包，将其发送到repeter板块。

在第一次在repeter中发包，通过返回可以看出已经成功修改了

如果再次发送会发现invalid token。

此时再从原来的页面中，刷新一下，拿到一个新的还没用过的token，将其放在repeter中替换token。

此时会发现已经修改成功。、

此时应该就能看出来，其实token是在变化的。

只要一个token用过一次，那么token就作废了。

现在登录B用户

拿到一个A用户一个还没用过的token，

抓取一个B用户修改邮箱的包，将其token更改为A用户的token

此时的情况是

B用户+A用户token

发现竟然成功了。此时就能推断出，token与用户的session无关。

那么我们也可以通过再获取一个A用户的新鲜token去pass this lab

再repeter中拿到CSRF的POC

按照图中点即可，实现一种功能，即打开网站即可提交表单，修改邮箱

将生成的代码放到下面的框框中，点击提交，即可通过

第五关-token绑定了非对话session

原文题目

Lab: CSRF where token is tied to non-session cookie

分析

CSRF的三个相关条件

抓一个修改邮箱地址的包。

可以看到有token，

接下来就是对token的分析

再repeter中发送了两下，发现token是可以重复利用的。

并且又发现 在cookie中有一个csrfKey的东西，猜测是token与它绑定着。

接下来就要分析

:::success

1、检查token与csrfKey Cokkies的关系

提交一个错误的CSRFtoken（）

提交一个来自其他用户CSRFtoken （判断token与CSRFKey Cookeies的关系。是否绑定在一起呢）

:::

分析一

提交一个错误的token会发现，invalid token，

未成功

在Chrome中新建私密空间，登录B用户，获取到token后替换当前Repeter中的token再次发送，会发现invalid

未成功。

我们拿到一个真实可用的token去测试，发现还是不行的话。此时可以推断出token与Cookie中的csrfKey绑定着呢

分析二

:::success

1、检查token与csrfKey Cokkies的关系

提交一个错误的CSRFtoken（）

提交一个来自其他用户CSRFtoken （判断token与CSRFKey Cookeies的关系。是否绑定在一起呢）

2、将A用户的Cookies csrfKey和token 全部替换为B用户的

:::

替换完后会发现。竟然成功修改了。

此时完全推断出Cookie csrfKey 与 token完全绑定着呢。

现在我们的整体思路就是

1、在被攻击的浏览器中插入一个http Cookie：csrfKey 。它的值就是我们已知A用户的就行。

2、将csrfpoc发送给被攻击者，即可成功。

注意：csrfKey和token 必须为一对

修改Cookie

现在已经知道了，csrfKey和token是一对的，所以我们要向被攻击者的浏览器去修改csrfkey的Cookie。

通过查询功能可以看出，当查询一个东西时，会向当前页面插入一个cookie，此时是否可以通过修改抓包，修改包

将我们的csrfKey Cookie插入到浏览器中呢。

通过抓包、可以看出在 search后的hat和Set-Cookie彷佛有着联系。

通过这段payload

/?search=hat%0b%0aSet-Cookie:%20scrfKey=值

即可成功修改csrfKey的值

此时要理清的是，这能运行是因为我们执行了一个url进行了一段数据的查询，修改了一段url使其结果朝着我们想要的方向发展。

只要访问这段连接即可修改cookie

:::success

https://0af300450435c630c00e9fe000b50022.web-security-academy.net/?search=hat%0b%0aSet-Cookie:%20scrfKey=Q45y0OxVp3HN7bswIRNdnh6jrPV6AJE0

:::

攻击

再抓取一个修改邮箱的包，设置poc

将token更改为A用户我们已知的。

在后面加入这段payload，加载一个图片，图片的连接，就是我们上面修改cookie csrf的连接。然后此时肯定是不对的，是报错，然后后面的onerror就是接受这个错误的，如果错的话，会执行这段代码，自动提交表单，修改邮箱，

<img src="https://0af300450435c630c00e9fe000b50022.web-security-academy.net/?search=hat%0b%0aSet-Cookie:%20scrfKey=Q45y0OxVp3HN7bswIRNdnh6jrPV6AJE0%3b%20SameSite=None"

οnerrοr="document.forms[0].submit()">

后面必须得加上这个黑色背景那段，要不然不会成功

提交完后即可成功pass

第六关-双重提交仿CSRF

原文题目

CSRF token is simply duplicated in a cookie

先抓取一个提交修改邮箱的包，发现cookie中csrf和url中参数csrf值相同

:::success

这里提到了一个double submit防范方式，其具体原理为：

Web应用不维护已发出令牌的任何服务器端记录，而是在一个cookie和一个请求参数中复制每个令牌，在验证后续请求时，应用程序只需验证在请求参数中提交的令牌是否与在cookie中提交的值匹配，这样一来就避免了任何服务器端状态的需要，因此也是一种不错的实现方式。

:::

尝试去删除url参数中csrf最后一个字符。

发现invalid token

将cookie中csrf的最后一个字符也删除，使cookie中和url中都相同。此时发现已经可以修改邮箱了。

此时的思路和上题差不多。

使用http cookie注入，向目标浏览器中注入一个已知的cookie使其与token相同。

也是使用搜索栏中，插入cookie

https://0aed00ea038a704ac08077e400c600d5.web-security-academy.net/?search=hat%0d%0aSet-Cookie:%20csrf=test%3b%20SameSite=None

pass

以下为Cookie篇

---

第七关-绕过SameSite Lax类型-通过更改提交Method

:::success

当SameSite类型为Lax的话，

原理可以看一下这个视频

https://www.bilibili.com/video/BV19y4y1j7Yx/?spm_id_from=333.337.search-card.all.click&vd_source=6690f45adca8f613b156af090b3ad350

如果是Lax的话在跨站请求中获取Cookie的话必须满足以下两个条件

• The request uses the GET method. （必须为GET请求）

• The request resulted from a top-level navigation by the user, such as clicking on a link.（必须为点击事件，可伪造）

例如，这意味着跨站POST请求中不会包含cookie。由于POST请求通常用于执行修改数据或状态的操作(至少根据最佳实践)，它们更有可能成为CSRF攻击的目标。

同样，cookie也不会包含在后台请求中，比如那些由脚本、iframe发起的请求，或者对图像和其他资源的引用。

:::

原题

SameSite Lax bypass via method override

通过分析可以看出，并未加入token

在这里看出SameSite的并未为None，所以为Lax，Chrome默认给SameSite设置的就是Lax。

通过多次尝试去发送请求，发现都可以成功修改。

现在我们的思路就是，还是和之前差不多，要整一个POC给受害者。在本地测试一下

生成一个链接，在网站中打开，如果此时我们的邮箱被改了，那么可以证明在受害者中也将被修改。

但是此时我们发现打开链接后，出现的是登录界面。这是为什么呢。

想起前面的Lax，可以分析出是因为我们点击了一个链接，该请求是一个POST请求，在Lax中POST请求不会携带cookie。也就会出现一个登录页面，现在这个页面不认识我们了。

现在的问题就是如何绕过，那个POST请求，修改为GET请求如何

它显示了方法不允许。这就需要绕过

我们只需要在GET请求参数后加入一个_method=POST即可。

浏览器会以为我们是POST请求。

此时在生成一个POC。

即可pass

第八关-绕过SameCookie Strict类型-通过重定向

原题

Lab: SameSite Strict bypass via client-side redirect

If a cookie is set with the SameSite=Strict attribute, browsers won't include it in any cross-site requests. You may be able to get around this limitation if you can find a gadget that results in a secondary request within the same site.
One possible gadget is a client-side redirect that dynamically constructs the redirection target using attacker-controllable input like URL parameters. For some examples, see our materials on DOM-based open redirection.
As far as browsers are concerned, these client-side redirects aren't really redirects at all; the resulting request is just treated as an ordinary, standalone request. Most importantly, this is a same-site request and, as such, will include all cookies related to the site, regardless of any restrictions that are in place.
If you can manipulate this gadget to elicit a malicious secondary request, this can enable you to bypass any SameSite cookie restrictions completely.

翻译后 --》

在strict中，任何跨站请求都将不会包含Cookie，但是如果能找到一个在同站点中导致二次请求的方法，那么即可绕过。

该方法就是利用重定向，重定向包含了该网站的所有Cookie，此时即可执行一些恶意操作。重定向就相当于是简单、独立的请求，在同一站点会包含所有Cookie

首先我们先登录一个ID，然后执行修改邮箱操作并抓取一个包，通过将该包转换为GET请求，再次发送即可发现成功修改。

此时我们可以尝试生成一个POC，测试一下。

使用链接的方式，这样最能接近受害者角度。

当我们将链接在网页中打开时，点击submit时，会发现已经需要重新登录了。

这是因为SameCookie的类型时Strict的原因。

当我们点击submit的时候，其实已经算是跨站请求了。自然不会包含Cookie。

所以此时我们需要一种方法，来绕过。此方法就是寻找一个重定向的页面。

当我们去主页，点开一个博客，进行评论。

评论完后，此时会发现有一个重定向的页面。

然后就回到该博客了。

通过查询http历史，可以看到确实在提交评论后，会有一个重定向的页面，该页面的返回源代中看到了重定向的JS代码。

在targe中找到了js路径

访问，即可找到源码，通过分析源码可知

传递了一个postId，再用

window.location = blogPath + '/' + postId;

这段代码重定向。

postId就是这个数据包发送的，我们可以利用这个数据。构造CSRF

通过postId的值，为目录遍历的代码即可

postId=../my-account

这样即可返回到自己账户页面。

前面已经知道了在修改邮箱的时候可以改为GET请求。

所以payload进一步修改

postId=../my-account/change-email?email=test%40qq.com&submit=1

加上../返回上层目录，是因为在JS代码中，有一个/

所以我们必须要返回的网站根目录所以要加上../

完整的payload如下，

记得要将&进行url编码

https://0aab00dd04159adac16fdf52006700f3.web-security-academy.net/post/comment/confirmation?postId=../my-account/change-email?email=test33%40qq.com%26submit=1

我们将原本修改邮箱的数据包中传递参数改一下。

然后将生成poc

复制代码到地方即可pass

以下为Referer篇

---

第九关-删除Referer

有些应用程序会在请求中验证Referer首部，但如果该首部被忽略，则跳过验证。
在这种情况下，攻击者可以设计CSRF漏洞攻击程序，使受害者用户的浏览器在产生的请求中删除Referer首部。实现这一目标的方法有很多种，但最简单的是在发起CSRF攻击的HTML页面中使用META标签:
<meta name="referrer" content="never">

通过抓取一个修改邮箱的数据包，放入repeter板块中，反复发送。

可发现可以不断修改，此时就可以尝试生成poc

生成一个poc在本地中打开。

referer不正确。这是因为在生成的页面中点击一下submit即可发送一个url请求，此时的请求会自带referer。而此时的referer来自于burpsuite生成的网站，不是同域名，所以会显示Invalid referer header。

在数据包中修改一下referer会发现，显示invalid referer。

此时就能准确判断出和referer有关。

将referer删除即可成功

但是在生成poc中即使将referer删除掉，在点击submit时也会自带referer。

此时可以在poc中加上

referrer别打错了

复制代码到exploit server

pass

第十关-绕过判断不严谨Referer

在本次实验中我们将绕过一些，只要Referer中的域名存在与当前站点的域名相同的即可。

首先先抓取一个数据包。

生成一个poc，使用链接测试，会发现Invalid referer

通过查看历史记录，发现Referer来自burpsuite。

此时考虑上一个实验的方法。

删除referer后，还是不行

此时我们在原本的域名前加上一段我们自己设置的域名。

将原本的域名以参数形式传递，发先竟然成功了。

我们在poc中插入一段域名

在复制代码到Exploit server中 要在Head中加入

Referrer-Policy: unsafe-url

原因是

如果存储漏洞并通过单击“查看漏洞”进行测试，您可能会再次遇到“无效的 Referer 标头”错误。这是因为许多浏览器现在默认从 Referer 标头中删除查询字符串作为安全措施。要覆盖此行为并确保完整的 URL 包含在请求中，请返回漏洞利用服务器并将以下标头添加到“Head”部分,[请注意，与普通的 Referer 标头不同，在这种情况下，“referrer”一词必须拼写正确。]

即可pass