4

I have created an authentication API to manage user sessions and the works. To log a user in, the user send their credentials to my API endpoint and it returns “true” or “false” based on their login. I recently received an issue report stating that using “a burp and intercept”, the response of “false” can be changed to “true”, bypassing a failed login attempt and tricking the browser into thinking the user is logged in.

I’ll be honest: I have no clue how to prevent this. And if I cannot prevent it, is there a better way to be authenticating users?

shane
  • 43
  • 4
  • Will they be able to access confidential information afterwards? – Arminius Dec 16 '17 at 20:09
  • 4
    It should not matter what the browser thinks. On successful login, you should return a token to the browser to be presented on further requests (usually stored in cookies). If the login fails, you do not return a token and the browser will get a 401 from the server. You may want to [read up](http://blog.restcase.com/restful-api-authentication-basics/) on web api authentication. – Marc Dec 16 '17 at 20:09

2 Answers2

6

You may want to ask the reporter to explain what they think the security implications are.

Tricking the browser into showing a successful login via a locally forged API response does no harm unless the user can use that to actually bypass authentication or access confidential information. An attack would have to trick the server into assuming the authentication succeeded, not the client.

I have no clue how to prevent this.

You can't prevent a user from tampering with data which has left your server. You have no control over the client (their browser) and can't stop them from using Burp (or the developer console for that matter) to rewrite requests and responses in ways that you web application didn't intend.

And if I cannot prevent it, is there a better way to be authenticating users?

As Marc outlined, one possible approach is to have the API endpoint return a session token once the authentication succeeds. The client would then use this token to make further authenticated requests.

Arminius
  • 43,922
  • 13
  • 140
  • 136
1

Security Researcher 'Joel Aviad Ossi' from https://websec.nl has shared a code that does exactly this on his github:

https://github.com/websecnl/BurpBuster

TuttieFruity256
  • 11
  • 1
  • interesting. One way to defeat BurpBuster, then, is to add a match and Replace rule to mess up that javascript code.... I added a Match and Replace for the Response body that replaced isLoaded == true with 0 == 1 and BurpBuster stopped working – mcgyver5 Oct 14 '21 at 02:12
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Oct 14 '21 at 09:47