Case Study for White Box Testing

A large merchant organization involved in online business was in the process of developing an online e-commerce web site. In an effort to allow customers to electronically and efficiently transfer funds from customer checking accounts to merchant accounts, the merchant organization had outsourced its payment processing to a third-party Internet-enabled financial transaction payment firm. The third-party payments software provided customized interfaces to facilitate payment processing between the customers and the merchant organization.

A high-level security risk analysis was conducted on the system. Risk assessment identified transactions processing between the payments interface and the application as one of the risks. The impact of fraudulent transactions is serious for both the customers and for the merchant organization. The customers could suffer significant financial loss and hardships resulting from unauthorized transactions that could deplete account balances. The credibility and the reputation of the merchant organization could be severely damaged as a result of fraudulent transactions should they become publicized.

A thorough white box testing was conducted on the modules using the payments interface. First, all the component interfaces were identified and illustrated as interface diagrams; second, trust relationship boundaries were drawn on the component interactions; and third, data flows between the components were drawn. Abuse cases were developed based on this information. One of the abuse cases pointed to exercising the payments processing functionality as an anonymous user. The trust relationship mapping and data flow showed a path where inputs from the users were not validated or authenticated. A test case was developed to submit an account transfer from an external account to the merchant account anonymously and the account transfer was completed successfully, which is a critical software failure: unauthorized transactions via unauthenticated channel were allowed.

Risk assessment also identified a weak authentication component in the payment customer service component of the system. As in the case above, trust relationship boundaries and data-flow analysis were conducted on this component. After analysis and testing, it was shown that an attacker could gain direct access to the merchant administrative accounts. With this access, an attacker could redirect transactions from a merchant account to another, non-merchant account.

Using the two exploits described above, white box testers showed that an attacker could funnel payments from an unwitting customer to the merchant account and then redirect the transaction from the merchant account to a non-merchant account. The two bugs put together form a serious breach of security with significant business impact.

This example shows that risk analysis yields business-relevant results and points to specific vulnerable areas of the software. Subsequent to risk analysis, performing white box testing in concentrated areas aids in quickly uncovering design assumptions and implementation errors. This example also shows that finding an exploit does not mean that the job is done. Collecting information about various bugs in the software and analyzing them together shows how multiple exploits can be stringed together to form a full attack.