Business Logic Vulnerabilities Banking apps
As a pentester, we perform testing on various kinds of web applications like e-commerce, banking, insurance, etc.. In this process we use automated scanners to trigger common vulnerabilities like XSS, SQL injection, and other generic class of vulnerabilities. But there is a certain type of security flaws which can’t be identified through scanners or secure code reviews (In certain cases) → Business Logic Vulnerabilities.
During my experience, I’ve come across major business logic vulnerabilities in banking applications. I would like to share a few of the test cases through this blog post.
First Kickoff
When you guys are performing a pentest on any banking applications grab your attention on the below-mentioned functionalities such as
- Amount Transfer
- View Balance
- Card Deactivate
- View statements
- Buy virtual Cards
- Bill Pays, Recharge
- KYC verification through OTP
- Reward Points
Grab your hands on and perform the mentioned test cases which might be helpful if any of the above functionalities are spotted out that might lead to a successful attack.
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.
To summarize, If the application has improper client-side and server-side validations, insufficient authorization checks it would be useful to perform these test cases.
P.S: This blog is for educational purpose, please do not try it on unauthorized sites.
“Good Banking is produced not by Good Banker’s nor Good laws but by maintaining proper security controls”.
I hope this blog post seems to be useful. For any feedback or suggestions reach out to me Jeevanindluri. Keep learning and Happy Hacking :)
