1 Lab: Unprotected admin functionality
target: Solve the lab by deleting the user carlos. 删除用户 carlos
根据题目要求，尝试在 robots.txt 中寻找敏感信息。
访问该 API，来到管理员面板。
2 Lab: Unprotected admin functionality with unpredictable URL
后台隐藏在 javascript 中。
访问 url ...web-security-academy.net/admin-3h7sno
3 Lab: User role controlled by request parameter
目标：访问后台并删除用户 carlos
credentials: wiener:peter
使用 wiener:peter 并抓包，重放，可以看到包里面设置了 csrf token 和 session
登录成功后，会进行页面跳转，这里的逻辑可能是：判断 Admin 参数来决定跳转的页面。
思路：修改所有请求报文中的 cookie 参数 Admin=ture
重新登录，抓包，改包
4 Lab: User role can be modified in user profile
根据题意，请求 /admin
[!question] 问题
如何修改user role？抓包的结果里面也没地方传参数roleid=2呀！答： 修改邮箱的时候以 json 格式传输
roleid，注意枚举输入向量
响应报文提示，roleid 已被修改：
进入 Admin panel 删除用户 carlos，拿下。
5 Lab: URL-based access control can be circumvented
抓包重放
[!note]
Notice that the response is very plain, suggesting it may originate from a front-end system.
响应里面啥也没有，说明它可能是来自前端
更改 HTTP 请求头：X-Original-Url: /admin
提示 Missing parameter 'username'
将参数单拎出来，响应报文提示 302 重定向，说明删除用户的操作可能成功了。
抓包，改包，删用户，删除用户之后重定向到 /admin 时还需要改一下报文，成功。
官方 solution 在中间加了一步，判断后端是否会处理 X-Original-Url 头。
Send the request to Burp Repeater. Change the URL in the request line to
/and add the HTTP headerX-Original-URL: /invalid. Observe that the application returns a “not found” response. This indicates that the back-end system is processing the URL from theX-Original-URLheader.
6 Lab: Method-based access control can be circumvented
credentials: wiener:peter, administrator:admin
目标：使用 wiener 登录，并通过 BAC ( break access control ) 将自己提升为 administrator 权限。
ps：可以登录 administrator 账号熟悉下提权流程。
提权流程与 [[#13 Lab Referer-based access control]] 类似。
登录 administrator 抓包，请求报文使用 POST 方法，直接传递参数 username=carlos&action=upgrade 且无需二次验证等操作，请求的 API 是 /admin-roles。
思路：登录普通用户，使用 POST 方法请求 /admin-roles 接口，并传递参数 username 和 action=upgrade。
在 url 中传递 GET 参数 id=administrator 后，发现重定向跳转到了登录界面，抓包，观察重定向报文是否暴露敏感信息。
响应报文仅显示了跳转到 login 界面，且未包含其他有效内容。
“Update email” 抓包，使用 POST 传递参数 email。
修改报文，请求 API /admin-roles 并传递参数 username=wiener&action=upgrade
响应报文提示 401 Unauthorized
难道它还要判断这个请求是不是从 /admin 接口过来？需要 Referer 头部包含 /admin？
再次修改报文，修改 HTTP 请求头 Referer。
得到的响应仍然是 “401 Unauthorized”。
稍微审下题，emmm，有些服务器可能会使用不同的 HTTP 方法处理同样的 action，这里我们把报文改成 GET 请求，再发送。这道题应该不会验证 Referer 头部，我只是懒得改回去了。。。
响应报文显示 302 重定向到 /admin 提权成功。
7 Lab: User ID controlled by request parameter
credentials: wiener:peter
目标：拿到用户 carlos 的 API key 并提交
登录后界面
抓包，重放
直接修改 id=carlos，
在浏览器中修改参数，拿到 API key 并提交
也可以直接复制 burp repeater 响应 中的 API key。 Render 渲染部分好像无法复制 API key，不过可以复制响应 Pretty 或 Raw 中的 API key
8 Lab: User ID controlled by request parameter, with unpredictable user IDs
抓包发现，这里的用户判断依据是 GUIDs，如果能拿到受害人 carlos 的 GUIDs 就能以受害人的身份访问其敏感数据，如：API key。
那么如何拿到 carlos 的 GUIDs 呢，首先肯定是明确 carlos 出现在那些地方，找了一圈，没发现好友功能。后面发现第一篇 blog 的作者就是 carlos。
点击作者 carlos 可以查看该作者的其他博客，同时地址栏显示出其 GUIDs。
复制该 GUIDs，并回到 My account 界面，以 carlos 身份拿到其 API key。
9 Lab: User ID controlled by request parameter with data leakage in redirect
首先看一下网站业务，该网站是一个线上商城，
商品页面也不包含用户 carlos 即受害人的相关信息。
在 My account 界面直接使用 id=carlos 绕过访问控制被重定向到登录页。
修改 id，发送 get 请求，抓包
得到如下响应报文：
可以看到虽然是 302 重定向到 login 页面，但响应报文中仍然包含了 carlos 的用户信息，当然也包括 API key。
10 Lab: User ID controlled by request parameter with password disclosure
目标：获取管理员密码并删除用户 carlos
credentials: wiener:peter
登录后发现用户当前密码就展示在输入框里
虽然被隐去了，但在源码中还是可以看到用户当前密码的。
通过修改 GET 参数 id=administrator，绕过访问控制，这里其实算是绕过水平 (horizontal) 访问控制，但是该用户有管理员权限，也能算是垂直 (vertical) 访问控制，也就是所谓的 “Horizontal to vertical privilege escalation“。
同样我们可以在源码中拿到 administrator 的密码：o84lgfayqhlsesmbgaan。
使用 administrator:o84lgfayqhlsesmbgaan 登录
删除 carlos 完成 lab.
11 Lab: Insecure direct object references
有个聊天机器人。
可以下载聊天内容。
单击 View transcript 后，抓包，发现，调用接口 /download-transcipt 并重定向请求对应的文件
思路：修改文件名，看看能不能获取到有用的信，如其他用户的聊天日志。
提示 No transcript。。。
不想猜了，直接 Intruder 爆破一下，先爆一下 0-100 的数字作为文件名。
屁也没有，emmm，前面几个还是我自个点 View transcript 生成的。
题目上说把用户的聊天日志存在了服务端文件系统中，难道要用到路径穿越的东西？ [[路径穿越基础介绍]]
简单构造了一下文件名 /download-transcript/../../carlos/download-transcript/1.txt 发现并不对。
[!question] 问题
carlos的聊天日志放在哪呢，咋找呢？没法使用ls和pwd是真的难受。
通过查看 solution，我突然意识到下载的聊天文件的文件名是从 2 开始的，再结合前面爆破的结果，carlos 的聊天文件大概率在 1.txt 中。
（我咋没试过 1.txt 呢，远在天边近在眼前 …
请求 1.txt
在响应报文中的 carlos 聊天文件中获取到了其敏感信息。
登录，lab 解决。
[!note]
这个 lab 告诉我们，使用 ChatGPT 的时候，别问过于敏感的问题。PS: 我对细节的把握还是差点意思。
12 Lab: Multi-step process with no access control on one step
credentials: wiener:peter, administrator:admin
目标：使用 wiener 登录，并通过 BAC ( break access control ) 将自己提升为 administrator 权限。
ps：可以登录 administrator 账号熟悉下提权流程
admin 提权流程：首先，选择对应用户，这里选 carlos，点击 Upgrade user
之后会提示 Are you sure? 点击 Yes，相当于一步验证步骤。
重定向到 /admin 页面。
提权成功情况如下。
也就是说 提权过程分为三步：
- 判断登录用户是否为 administrator
- 提交提权请求，即 ‘Upgrade user’
- 确认提权请求，’Are you sure?’
思路: 直接修改第三步操作 “Are you sure” 认证过程的报文，将 username 改为 wiener，从而实现提权。
下面先在 administrator 用户下修改报文
响应报文重定向到 /admin 页面，说明大概率成功了。
查看页面。
解题流程：先登录用户 wiener
修改邮件，抓包
由于这是 post 方法，我们直接尝试修改 API 访问 /admin-roles 并传递参数 action=upgrade&confirmed=true&username=wiener，绕过逻辑：虽然提权需要三步，但执行第三步的时候后端可能会默认前两步成功了，也就是 身份验证为 administrator，并提交了提权请求，所以直接使用 wiener 身份构造第三步的请求包即可提权成功。
响应报文显示 302 重定向到 /admin，说明提权成功了。
打开网页验证一下。
登录 administrator 面板显示提权成功。
13 Lab: Referer-based access control
credentials: wiener:peter, administrator:admin
目标：使用 wiener 登录，并通过 BAC ( break access control ) 将自己提升为 administrator 权限。
ps：可以登录 administrator 账号熟悉下提权流程
与上一个 lab 不同的是，在 admin 管理面板 (admin panel) 直接点击 Upgrade user 即可提权，没有二次检查。
点击 Upgrade user，抓包，发现使用的是 GET 方法传参，且会验证 Referer 头部 -> 必须从 /admin 页面跳转过来。
修改 Referer 头部
响应报文显示 401 “Unauthorized”，说明会验证 Referer 头部
思路：登录普通用户，使用 GET 方法请求/admin-roles?username=wiener&action=upgrade 并伪造 Referer 头部，使后端服务器认为是从 /admin 跳转过去的。
登录 wiener，这里直接选择 my-account 页面的报文，主要它用的是 GET 方法。
仅修改请求 url 为 /account-roles?username=wiener&action=upgrade
响应报错，提示 401 Unauthorized
同时修改请求 url 和 Referer
响应报文提示 302 跳转到 /admin 页面，提权成功。
刷新页面，显示出 Admin panel 提权成功。
