Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Academy Lab Feedback: 2FA broken logic

Jackson | Last updated: May 25, 2023 04:17AM UTC

Hello, I was working on the 2FA broken logic lab found here: https://portswigger.net/web-security/authentication/multi-factor/lab-2fa-broken-logic I wanted to give some feedback. I was able to complete the lab. However, it doesn't really seem like the best example of a business logic vulnerability, certainly not one in which the application has "Excessive trust in client-side controls" which is the heading of section after which this lab is listed. To be clear, I do understand *why* this lab is used to demonstrate this flaw... but I do not think it is the *best* example. To me the application in this lab has 2 flaws (listed in the order in which I think most people would consider the severity): 1) The mfa challenge can be brute-forced because the mfa codes are not complex (long) enough, the application does not throttle users who make too many failed attempts, and the mfa challenges do not time out in a timeframe that is short enough to prevent brute forcing. 2) The application presents a challenge for whichever user is requested by the client instead of relying on something like the session id. Flaw #2 is definitely a flaw and it is definitely an example of the application trusting client side code when it would be better to use the session id to determine for which user the challenge should be presented. But I think the bigger issue is that the mfa codes can be brute forced (flaw #1). If, for example, flaw #1 was fixed, flaw #2 would be substantially (if not arguably completely) mitigated. Since I don't like just complaining, I have a recommendation for what I think would be a few ways the example application could be designed to demonstrate this type of flaw better: -The server could depend on a predictable client-side cookie to determine if MFA has already been completed successfully. (For example, after completing MFA successfully for the wiener user, that application could set an "auth: completed" cookie or something like that. Then the student could see that, try adding it to a request for the my-account page of "carlos" and bob's your uncle). I think this would clearly demonstrate a canonical, albeit simple, example of applications having too much trust in client-provided data and a misplaced assumption that the user will use the provided web interface (the browser) and therefore won't set their own cookies (this part is actually a similar lesson to the way the lab is currently). -The same idea of the current lab could be used (changing the "verify" cookie value to "carlos")... but instead of brute-forcing, it could be set up such that mfa codes work for *any* mfa challenge on the application. So the student could get a code for the wiener user *but not use that code*, then use repeater to send a request with modified "verify" cookie to get a challenge for "carlos". Then they could use the code they received in their email that was supposed to be used for their account, but submit it as the challenge response for carlos's account. Since the application allows any code to work for any challenge, it is just assuming that a user will only submit a challenge response for their own user. I think this is another way to clearly demonstrate an application trusting client supplied data too much. To be fair, this example *also* has a second flaw: that any code can work for any challenge... but I think this example places more emphasis on the changing of the cookie value and less emphasis on the mfa code itself.

Dominyque, PortSwigger Agent | Last updated: May 25, 2023 08:42AM UTC