Insecure comparison in PHP — Business Logic Bypass vulnerability

I have recently spotted an interesting vulnerability in a PHP application, which was in scope of a private bug bounty program. This vulnerability has nothing to do with standard web app issues like SQLi, XSS or IDOR, hence despite relatively small impact I decided to write couple of paragraphs about it.

Unfortunately, due to the NDA I won’t be publishing any screenshots in this article, but hopefully the description and pseudo-code will allow you to understand the issue.

Application description

Application which was a subject to the test had a functionality which allowed users to create and publish objects. Before being published an object required an approval from a user who was selected by the Creator during object creation process. To prevent fraudulent activities, security mechanism in place did not allow the Creator to select himself/herself as the Approver. An attempt to do that resulted in an error.

From HTTP request perspective, web browser was sending a POST request with multiple parameters to the web server. Two of these parameters were containing Creator’s and Approver’s UserIDs — 3 digit long natural numbers.

Pseudo-PHP code to present the mechanism:

Security issue

Knowing PHP issues with value comparison I decided to give it a try and check what would happen if I pass a float number as an approverid.

I modified HTTP request and passed 200.9, as approverid’s value. To my surprise application did not return an error, but did some weird rounding and set up a user with UserID 201, as an Approver.

With such a behavior the next action was clear for me. I sent a POST request to the web server with 201 as creatorid and 200.9 as approverid.

Application compared both values, determined that they are not the same, rounded approverid value up and successfully saved both values (201 and 201).

No errors were returned. The Creator was able to set himself as an Approver and approve his own object. That resulted in a complete bypass of business logic in the application.

Summary

Bug was triaged and accepted 4 hours after submission. Bounty amount was relatively small due to limited business impact.

However, it is important to remember that security issues related to value comparison may have tragic consequences if implemented incorrectly in critical application areas (e.g. authentication, authorization). Identifying these issues without an access to the source code might be very hard and often requires some luck or eureka moment.

Happy hunting!