As mentioned earlier, business logic-related flaws cannot be tested comprehensively using automated tools. The following are some guidelines to test business logic:

• Have a brainstorming session with the application architect, the business users of the application, and the developer to understand what the application is all about
• Understand all the workflows in the application
• Jot down critical areas of the application where things might go wrong and have a larger impact
• Create sample/raw data and try to explore the application both as a normal user as well as from an attacker's perspective
• Develop attack scenarios and logical tests for testing specific business logic
• Create a comprehensive threat model

Example of a business logic flaw

Consider an e-commerce website selling recharge coupons for TV set-top boxes. It is connected to an external payment gateway. Now a user selects a recharge amount on the e-commerce website and then the e-commerce website transfers the user to the payment gateway to make a payment. If the payment is successful, the payment gateway will return a success flag to the e-commerce website and then the e-commerce website will actually initiate the user requested recharge in the system. Now suppose the attacker chooses to buy a recharge worth X$ and proceeds to a payment gateway, but, while returning to the e-commerce website, he tampers with the HTTP request and sets the amount to X+10$. Then, in this case, the e-commerce website might accept the request thinking that the user actually paid X+10$ instead of X$. This is a simple business logic flaw which happened due to improper synchronization between the e-commerce website and the payment gateway. A simple checksum mechanism for communication between the two could have prevented such a flaw.