Quick (Stored) XSS on Infrastructure Giant

May 2019 (65 Words, 1 Minutes)

Quick (Stored) XSS on Infrastructure Giant

Follow on twitter: https://twitter.com/initroott

I did a quick view at a major infrastructure client. Given their modern web-design I couldn’t find any reflective injection points. I’ve let it go for a while and found myself dealing with one of their earlier versions and immediately note that the hosted site is much more outdated than their recent counterparts.

I set out scoping the application using Burp and found a reflective spot. This could lead to a type Stored XSS on the user machine as you’re adding into the container.

Wouldn’t have been able to identify the endpoint if I haven’t played with the application functionality.

Vulnerable endpoint: xxxx.com/workingSetState.jsp?operation=add&workingSet=(injection point)

This is where I found things difficult. Nothing I tried seem to evade the Akamai WAF.

I headed back to https://github.com/s0md3v/AwesomeXSS and tried a couple of other payloads. Scrolling twitter feeds searching for the WAF eventually was my breakthrough.

I ended with the payload:

<dETAILS%0aopen%0aonToGgle%0a=%0aa=prompt,a() x>

injected in the parameter for the execution of XSS.

Success!

Source code output:

The create thing about the above XSS is that once its generated it will become stored as part of the sets are saved in the cookies. If the user ever opens the page again the script will keep executing.

Timeline 20–04–19 Discovered bug, informed company by email

24–04–19 Confirmed by company and awaiting further feedback