Over the last few years, our On-Demand and Hybrid Penetration Testing platform has performed security testing of applications across various verticals and domains including Banking, e-commerce, Manufacturing, Enterprise Applications, Gaming and so on. On one side, SQL Injection, XSS and CSRF vulnerabilities are still the top classes of vulnerabilities found by our automated scanning system, on the other hand however, there are a lot of business logic vulnerabilities that are often found by our security experts powered by a comprehensive knowledge base. Here we will discuss top business logic vulnerabilities in Banking Applications.
Business logic vulnerabilities are defined as security weaknesses or bugs in the functional or design aspect of the application. Because the security weakness or bug is in the function or design, it is often missed by all existing automated web application scanners.
In this blog we are sharing the top commonly found Business Logic Vulnerabilities in the Virtual Credit Creation (VCC) module of a Banking Application.
Consider the following scenario: A Banking Application provides web based functionality to users to pay Bills Online as well as to create and manage Virtual Credit Cards. Virtual Credit cards are used to shop online. A Virtual Credit Card creation use case involves the following steps:
1. User visits banking application.
2. User opts to create virtual credit card.
3. User fills up personal details, required amount, expiry date of VCC etc.
4. User chooses a payment gateway.
5. User fills up credit / debit card details.
6. Banking Application redirects user to a Payment Gateway.
7. Required amount + Service Charge are debited from user’s Debit / Credit card.
8. Payment Gateway redirects user to a Callback URL provided by the Banking Application.
9. Banking Application verifies the Payment Gateway confirmation.
10. Banking Application generates a CVV number.
11. Banking Application presents VCC details to the user.
12. Banking application performs SMS verification of the user.
A couple of security weaknesses that are found in the above scenario are as follows:
(Read more: Technology/Solution Guide for Single Sign-On)
TAMPERING OF DATA COMMUNICATION BETWEEN PAYMENT GATEWAY AND BANKING APPLICATION:
Weaknesses: The Banking application does not verify whether the required amount is successfully paid at the Payment Gateway Side, or what amount is being paid at the Payment Gateway Side. As a result, a virtual card can be recharged with higher amount while paying a lower amount to the bank by modifying amount when the request is sent from payment gateway to the bank.
Mitigation: There should be sufficient validations between the Banking application and the payment gateway. The callback URL should not be allowed to be directly controlled by an attacker–Tweet This!
NO VALIDATION ON BANKING APPLICATION’S CALLBACK URL
Weakness: There is lack of validation on the Banking Application Side when the Payment Gateway redirects a user to the Banking Application’s callback URL. As a result, a virtual credit card can be created without paying any service charges, by sending the request directly to the callback URL of Payment Gateway.
Mitigation: There should be enough validations on the callback URL including whether the URL is redirected by the Payment Gateway or directly called by an attacker-Tweet This!
VIRTUAL CREDIT NUMBER IS PREDICTABLE
Weakness: Generated Virtual Credit card numbers are predictable or follow certain patterns. As a result, an attacker can predict what virtual credit card numbers are being used by other legitimate users.
Mitigation: Virtual Credit Card numbers should be sufficiently random-Tweet This!
NO ANTI-AUTOMATION IN VIRTUAL CREDIT CARD DETAILS VERIFICATION
Weakness: There is no anti-automation (e.g. CAPTCHA) while verifying the Virtual Credit Card details such as CVV number and expiry date. The Credit Card number is sufficiently long however, the CVV number is generally a 3 digit number and expiry date is also a 2 digit number. As a result, it is possible to brute force the CVV number and expiry date, and shop online using a stolen virtual credit card number.
Mitigation: There should be sufficient anti-automation e.g. CAPTCHA while verifying the CVV numbers along with the Credit Card Number-Tweet This!
NO ANTI-AUTOMATION IN CARD CREATION PROCESS
Weakness: There is no anti-automation while creating a virtual credit card. An attacker can use automated scripts to exhaust credit card numbers. As a result, Credit Card Numbers can be exhausted and be therefore made unavailable to users leading to a Denial of Service (DoS) attack. It can also lead to other attacks including Credit Card Number pattern prediction.
Mitigation: There should be sufficient anti-automation e.g. CAPTCHA while creating virtual credit card numbers-Tweet This!
Adapted from the original post written in Iviz Security Website.
(Read more: CISO Guide for Denial-of-Service (DoS) Security)
Comments