XSS & IDOR & CSRF to ATO

Hello hackers I’m Mostafa Elguerdawi,

I have returned once again with my friend Abdelrhman Allam (sl4x0) with a new vulnerability, which involves combining a set of vulnerabilities to obtain an Account Takeover (ATO).

In the beginning, I found an XSS vulnerability in the link after triggering any error.

We were able to bypass the firewall by URL encoding the payload.

The payload used: }}iybkg<script>alert(1)</script>//iipue=1 But by performing URL encoding.

Unfortunately, the program did not accept XSS without ATO or without obtaining important user information, and at the same time, the httpOnly flag was being used, which prevented us from obtaining users’ cookies.

However, there’s another parameter in the Cookie header called SSS_SESSION_ID. After some investigation, we found that this is a CSRF token.

So now, we can steal any user’s CSRF token with just one click.

We attempted some CSRF attacks, but these attacks would reduce the severity because the Account Takeover (ATO) would require two clicks instead of one. Therefore, we tried other methods.

We went to the “Forgot Password” page and found that the application doesn’t ask for the old password, which is a good sign. However, when we tried to change the password using another user’s CSRF token, we received a 401 Unauthorized error.

So, we tried adding a new parameter to the POST request called USERNAME and set its value to the victim user's username.

We also changed the USERID parameter value in the URL to match the USERNAME parameter in the POST request.

After sending the request with the victim’s username, ID, and CSRF token, we received a 302 Found response and were redirected to the /change_password_success page.

Then we tried logging in with the victim’s username and the new password, and we succeeded, And our attack was successful.

Recap:

We discovered an XSS vulnerability with the HttpOnly flag set on the jessionid parameter, which is responsible for user authentication. However, there were no secure flags on the SSS_Session_ID parameter, which is responsible for the CSRF token. We then attempted to change another user's password using the stolen CSRF token via XSS. After that failed, we modified the username and ID parameters to match the stolen CSRF token. Finally, the attack was successful by chaining XSS, CSRF, and IDOR to achieve Account Takeover (ATO).