CSRF PoC mistake that broke crucial functions for the end user/victim

You have heard of business logic bugs. The idea of abusing the logic behind the website’s functionality in order to achieve something like a discount or similar that you shouldn’t be able to do, i.e. https://hackerone.com/reports/336131 and similar, none of it is really new. Then, there are other logic errors that I have not seen in the past. Could be I wasn’t looking where I should have been looking.

This is about a very curious logical bug, in my opinion. It is a whole new way to mess with the underlying logic, depending on how the website is coded. In this case, it “only” breaks some of the website’s functionality for the end user/victim, and it can be triggered through csrf. I actually discovered it by pure accident/error in my coding of the csrf PoC.

CSRF Discovery:

The simplest test for csrf is: You follow burp’s request headers, see there’s no x-csrf or other custom headers (if there are, you remove them, and verify that the request still goes through as it should), no Origin limitation, no Referer limitation, etc. Finally, the request body is verified to either has no csrf token or csrf token isn’t being properly validated. Then comes the fun part.

CSRF PoC, and a mistake:

Having verified that there were no limitations/protections from csrf through headers and parameters, I proceeded with getting PoC ready. It was a simple html form, but it had an interesting logic. I’ll try to explain it the best I can considering that I can’t quite go into detail because it’s private bbp and on top of that the param names could potentially make it easy to figure out which bbp I’m discussing.

Let’s say you are a user who can limit how many paid emails you can send per month where you can attach a file to. Meaning, if the limit has been reached you can only send free emails without attachments (trust me, this is just a simplest example I could translate the actual functionality to, the real thing was far more interesting, but its details would disclose the bbp in question fairly easily).

You can either set that limit to be an OptionalLimit, meaning you can change it before the month is over if you need to do so. Or, you can set it to be a MandatoryLimit, meaning it has to be followed until the month has expired — you can’t override that limit before the month has expired.

The code for html form looked something like this for OptionalLimit:

And, the code for MandatoryLimit:

Note the highlighted lines from both images (lines 4 and 5, respectively).

CSRF PoC with a minor mistake:

Can you spot the error?

Just in case you didn’t, it’s line 4 or line 5: the value for the Type should be corresponding to the name OptionalLimit, meaning in this case it should have been either Type with value Optional, or name OptionalLimit should have been MandatoryLimit.

Impact: because value is set to 0 it means that the user/victim can only send free emails until the month is over, assuming that the form design resets at the beginning of the following month.

The impact’s severity is further increased because the user/victim can’t readjust anything pertaining to message limit through the website forms because the dropdown boxes don’t display any options, just blank fields. Therefore the only way to solve it would be for the end user/victim to use burp repeater or similar, and to manually enter params and values in order to restore everything back to normal.