Open Close

Business Logic Testing for Banking and Financial Applications


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.

(Read More:  5 Application Security Trends You Don’t Want to Miss!)

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.

(Read More:  Silent SMS: How I know where you were yesterday night?)

  • 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

Sample Vulnerabilities

Some of the sample vulnerabilities are listed below.


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.


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.


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.


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.

(Read More:  How MIT website got hacked despite having any vulnerability?)









  1. Superb site ƴoս have ɦere but I was wanting to know if yoou knew
    of any forums tҺat cover tҺe samе topics discussed
    Һere? I’d rеally like to be a ƿart օf group wherе I ccan get sutgestions fгom ߋther knowledgeable people tɦаt share the sɑme inteгeѕt.
    If you havе any suggestions, please lеt mee know.
    Ҭhanks a lot!

  2. Hey! I’m at work browsing your blog from my new apple iphone!
    Just wanted to say I love reading your blog and look
    forward to all your posts! Keep up the superb work!

  3. Meir Ezra says:

    Hi there, after reading this remarkable post i
    am as well happy to share my experience here with colleagues.

Leave a comment

All fields marked (*) are required