Refocusing in bug hunting, Bonus: An interestingly simple to test CSRF bypass

Use the source… of a html page

It happens that from time to time you get stuck during bug hunting. You visit the website that is in scope, and you look around it, you check what burp proxy history logs, and there’s nothing there. That is, nothing obvious. And, at times, you may stop there. Especially if you’re early on your journey like I was some time ago.

I went to this website that had the usual suspects like search form, ability to add products to a cart, to your wishlist, and to place the order.

The obvious attack, for a “green” bug hunter, is to throw xss payloads into all the parameters and see what happens. And, in this case, nothing. There was nothing interesting, the html tags were being properly encoded. It looked like a dead end.

Therefore, I left it be for a few months. And, when I came back, instead of using the tool to extract links to js files that the website was using, I actually decided to read through the source code of the main page. It wasn’t like the real deal, just html source code. But, it turned out that a lot of interesting javascript code was right in the midst of all the html stuff.

The interesting part was a section where javascript was being used for POST and GET requests to very interestingly named endpoints. Knowing the basic javascript was more than enough to understand what the code was doing, and how to test for IDOR using those endpoints.

Issuing the GET requests to those endpoints while changing the numbers or usernames presented me with data of other users, data that was clearly meant to be accessible by only those users.

Bonus: CSRF Bypass

There have been many approaches to bypassing csrf protection: removing csrf headers/parameters, replacing the csrf token’s value with a different value of the same length, and attempting to switch from POST request to GET request (this one is heavily dependent on the website’s function that is being protected with csrf)

The one that I haven’t heard of, and if you have, I find it bears repeating: changing the content-type. Namely, switching from non form content-type (i.e. application/json, application/x-url-encoded, etc.) to content-type: form-multipart

Here’s a screenshot example, simplified to a necessary degree, based on one of my reports that, to my surprise due to its simplicity, wasn’t marked as a duplicate and I got a nice bounty:

Note that the content-type: application/x-www-form-urlencoded and wrong value for csrftoken gave 403, while the content-type: multipart/form-data and omitting csrftoken parameter and its value gave 200.