Business Logic Vulnerabilities Banking apps

1. Amount Transfer :

While transferring the amount from one account to another, try to modify “FromAccount” parameter value to that of another user’s account number by intercepting the request through any of the proxy tools like Burp Suite, Charles Proxy, OWASP Zap Proxy etc.,

The same test case can be applied for other functionalities like Bill pay, recharge etc., where the amount will be deducted from the different account number.

2. View Balance:

In the purpose of viewing account balance, Try modifying the ID’s related to our account with that of another user’s account ID which comes under a case of Insecure Direct Object Reference vulnerability.

The impact of this vulnerability would be a user can view other user’s account balance information which leads to sensitive information disclosure through IDOR.

3. KYC Verification OTP Bypass

After logging into the application, most of the apps verify KYC by sending OTP either through mail or mobile. Figure out to bypass the OTP through response modification.

The user is able to successfully verify the KYC details through OTP bypass.

4. Deactivate Card:

While testing the Deactivate Card functionalities, intercept the request and modify the appropriate values in the request where we can try to deactivate other user cards.

5. View Statements

While testing the view statements/statement download functionalities observe any possibility to view other user statements by fuzzing or manipulating any user resource Id’s and also when downloading the statements try to access those appropriate URL’s through forceful browsing(Unauthorized Access).

In the above screenshot observe that card Id is modified to that of another user’s card Id where the user is able to view transaction details of another user successfully.

6. Buy virtual Cards

Nowadays we are observing the virtual card functionalities in many of the internet banking applications. User can buy different types of virtual cards like Classic, Gold, Platinum etc., which is chargeable depending on the card type chosen by the end-user.

Being a pentester approach with the following use cases

a. Look for amount promising parameter and try to buy a card for a lower price by modifying it. Observe that logic of the functionality is vulnerable to client-side validation or not.

Ohhhh!!! Did the above test case did not work due to proper server side validation. Don’t worry chilllll!!!!!!!!!!!!! Try one more test case here.

b. Now try to buy the least valued(Example: Gold card in this case) virtual card and get the successful response for the request. Observe if any random token values are getting generated and make a copy of those values and drop the response in the proxy tool.

Again repeat the same process for higher(Example: Diamond Card) amount virtual card by replacing the random token value with the one which is copied already. Observe if you’re able to buy a higher valued virtual card with a lower amount token value through this scenario.

This scenario(b) can be applied using two different user accounts and notice whether you’re able to buy virtual cards using a different user account token value.