XSS: Beyond the pop-ups

We all know that simple pop-ups ‘alert()’ doesn’t worth much as this does not show any impact & bounty world is all about the impact, also in Pentest world a simple Cross Site Script (XSS) has medium level severity.

Do you stuck on escalating XSS when server says httponly ?

I have recently encountered same scenario where server implements httponly flag on all of it’s cookie values. An example of same can seen in below image.

That little yellow highlighted bastard tells the browser that this cookie value can not be accessed by any client side scripts, for example the most popular document.cookie

Is this the END of XSS ?

Well the httponly might end the simple technique of using document.cookie to steal the user cookies for session hijacking which most of Info-Sec guys emphasize as Account Takeover in bug bounty world.

But this does not nullify the XSS attack vector, XSS are not just meant to pop some alert boxes & steal user cookies. The real power of XSS is the ability to execute malicious codes in browser (maybe beyond if you have browser exploitation skills). To know how destructive XSS can be is the classic browser exploitation framework solely based on it, the BeEF tool.

The Beyond Strategy ?

Being stuck in something means try something else, learn more and experiment more. This ignite a spark of curiosity inside, So I used some google-fu to learn different techniques used to escalate simple alert popup into something better.

To achieve this, the most important thing is to know the target well enough. “To know the target well enough” here means enumerate each endpoint of the target. The more data we have the more chances we have to get better results, this can be done by simply using proxy tool such as Burp Suite and browsing the entire target domain.

This will tell which endpoint leaks what kind of data, for example if target have login form then it will certainly stores and retains user’s credentials or user sensitive information. This information is required to be shared between server and client for authentication and authorization purpose.

Let’s look at the example to understand better, suppose there’s an endpoint like /v1/getAccountSummary which will revert back user information in response body. Assume that the response contains username, contact information, password or access token, etc…

The blue highlighted area is request uri and request headers, the green highlighted part is response headers, the rest is the response body. For the attack we’re interested in the response body part.

As seen in above image, the response body contains user information along with the access token which is nothing but the JWT token which is used by target application for authentication and authorization.

Can we steal this information using XSS ?

Yup! definitely, we can steal it as there is nothing defined to protect it from accessing the response body using client side script.
How to do that ? Well here comes the secret XMLHttpRequest (XHR).

This is designed to retrieve data from server without the need to refresh the page. To simplify think of it as viewing a page whose contents changes constantly without the page being refreshed such scoreboard of live match keeps updating the scores in real-time.

Now we have to craft the payload such that it should:

i. Fetch data from /v1/getAccountSummary
ii. Extract response body from response
iii. Send the response body to attacker controlled server

The payload is self explanatory if it’s difficult to understand what it is, then I suggest you to read documentation XMLHttpRequest.
For quick wrap up, xhr.open will send request as defined in ‘()’, the first part will be HTTP Method and second part will be the target URL.
The xhr.withCredentials will allow to share cookies and headers with cross-domains.
The onload function is used to trigger second request to attacker controlled server, here we can use simple burp collaborator or postb.in or ngrok.

In short the above payload is powerful enough to fetch victim user data then send response body to attacker controlled server via GET Method. The attacker server log will now contain the GET request with stolen user data.

Now, we can simply extract the JWT token from request then append it to Authorization header in crafted request to fetch user data in Burp & if the response has user or account details of victim in it, congrats we have got nice Session Hijacking a.k.a Account Takeover.