Over the past decade, one of the vertical that has grown by leaps and bounds is BFSI Segment. As a result, BFSI applications are a part of stricter scrutiny of security attackers around the world.
Why Conventional Application Penetration Testing is not good enough for BFSI Applications?
- BFSI applications already have basic hygiene in place. For example, Input Validation, Strong Password Policy, Multi Factor Authentication etc. are already in place in a BFSI application.
- BFSI Applications have sophisticated and focused Business Logic in place. For example, Transfer Money itself has been subjected to a variety of attacks in the past.
- BFSI Applications have wide variety of integrations and access methods by end users. For Example, Web Portal, Mobile, IVR, Payment Gateway APIs and so on.
- On the other hand, conventional application penetration testing focus on vulnerability classes described in OWASP or WASC standards. Primarily, conventional application penetration testing focuses on OWASP Top 10 vulnerabilities classes like SQL Injection, XSS, and CSRF etc.
As a result, it is required to create a Penetration Testing Framework specifically for BFSI applications. In the following section, we will describe some of the key vulnerability classes that should be a part of the BFSI applications Pentest framework.
Key Vulnerability Classes Covered
BFSI classes of applications have tremendous amount of logical and sophisticated functionality to perform security assessment. Following is a partial list of vulnerabilities classes tailored specific to BFSI applications/
- Business Logic Vulnerabilities
○ Flaws in Transfer Money Modules. Some examples are Negative Amount, Zero Amount Transfers
○ Flaws in Banks Processors and Payment Gateways
○ Flaws in Virtual Credit Cards Management
○ Flaws in Cards (Debit and Credit) Management Modules
○ Flaws in Bill Payment Module
○ Flaws in Reward Points Management
○ Flaws in Interactive Voice Response Systems (IVR)
○ Flaws in Mobile Banking, Mobile Wallets and Mobile Money Transfer
- Identity Management and SSO Flaws: This class consists of many sub classes of flaws, and some of them are listed below:
○ Authentication Weaknesses
○ Weak two factor authentication implementation
○ Flaws in Single Sign On Implementations
○ Flaws in implementing additional security defenses like IP based restrictions, multiple concurrent connections and so on.
- Authorization and RBAC Flaws: This class consists of comprehensive RBAC security assessment from multiple perspectives, some of them are listed below:
○ URL based and Object based access controls.
○ Horizontal and vertical privilege escalations.
- End User Security Management Flaws: In this class, various flaws are tested related multiple mediums of authentications specifically designed for various purposes for examples PINs, Smart Cards, Multi Factor Authentications etc.
- Denial of Service (DoS) Flaws: In this class of flaws, apart from conventional DoS attacks, various logical flaws that may lead to Denial of Service to all or few tenants of the application. Some examples are as follows:
○ Slow POST Requests
○ Slow Batch Processing Requests m
○ Starving other tenants by misusing long running jobs, or consuming too many resources.
- Conventional Vulnerabilities
○ SQL Injection, Cross Site Scripting (XSS), CSRF and other vulnerabilities defined as part of OWASP
Free Download: Business Logic Vulnerabilities Checklist
Some of the sample vulnerabilities are listed below.
1. TAMPERING OF DATA COMMUNICATION BETWEEN PAYMENT GATEWAY AND BANKING APPLICATION:
Weakness: 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. So, Business Logic Testing is mandatory.
2. 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.
3. 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.
4. 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.