False positives are a bane of… well, everything. Scientists have to deal with it, and so do pentesters and bug bounty hunters. The difference is that as a bug bounty hunter if something is false positive and you’ve spent hours on it, you just got burned. You’ve earned some experience, though. That has to count for something.

Either way, if you are really serious about bug hunting, or hacking in general, you have to be up-to-date with new attacks, new tricks, and tips, etc. But, because these attacks are new to you, it means you may not be aware of the potential pitfalls within those attacks.

False2True:

This one was quite a revelation when I first heard about it. Here’s the link that got me started down that path.

The basic idea is to keep an eye for the Response bit of requests (I had more luck with responses to POST requests rather than GET) and note places where it shows “isAdmin”:false, “staff”:false, “userLevel”:basic, etc. You get the idea. Experiment, basically.

The attack is to use Match & Replace in burp (you don’t need the pro version either) and to add the rule like this:

Then refresh the page and see if you’ll be presented with some additional options, text, buttons, anything that wasn’t there before. You can open the same page in a browser that isn’t going through burp proxy, login as the same user and compare it with the browser that is going through burp proxy. And then play: spot the difference :)

At first, I didn’t have much luck in finding it. Nothing. But then…

Admin access bypass:

This was quite an exciting roller coaster, for a moment there. And then — crash.

The website had a request to /index.html which, as I followed the burp history, was followed with a request to /userinfo.json, before loading javascript files.

Userinfo.json looked something like this:

{“canEditUsername”:true,”canUploadFiles”:true,”isStaff”:false,”isAdmin”:false,”isUser”:true}

#burpsuite #infosec #hacking #website-security #bug-bounty