Business Logic Pitfalls in Trading Applications (Blog Series) — 1

November 14, 2013

Business logic vulnerabilities have always been the elusive unicorn of the application security world that makes a clear business case for manual penetration testing in addition to tools based automated testing. Where an automated tool excels at identifying multiple instances of a technical vulnerability such as Cross Site Scripting (XSS), we are forced to turn to an organic security tester to find fundamental business logic vulnerabilities in either the application’s authorization module or business logic enforcement engine. The fundamental reason for this is the assumption that an intelligent human security analyst can comprehend the business purpose of the application and alter his/her mental threat model to reflect an entirely new set of threats that would then form the attack plan.

Complex applications that serve a highly specialized business purpose, such as securities trading, present a scenario that falsifies the assumption. The challenge with these applications is their complexity and the specialized nature of the business they serve. In order to successfully develop a mental threat model of complex securities trading applications serving an organization’s capital markets business, the security tester would need to possess intricate knowledge of the business and financial impact of logic enforced by the application.

Based on our deep experience working with clients in the capital markets space, I have tried to summarize some common vulnerability trends to assist fellow organic testers in formulating a mental threat model and a relevant attack plan. This series of blog posts will dive into some common issues we’ve seen:

Mind the price spread

The price spread refers to the difference in the quoted price for a particular security when one is buying as opposed to selling said security. The quoted price is usually higher when a request is made to BUY than when a request is made to SELL. This price spread is a source of profit for the organization offering the trading platform.

Often, transactions for buying and selling securities such as fixed income bonds is a two-step process with a time limitation between the two steps. Step 1 involves requesting a quote to either BUY or SELL a specified quantity of the security and Step 2 is initiated when the user hits “Confirm” to finalize the transaction at the quoted price within a preset time window.

It is not uncommon to see the application transmit the transaction information including transaction type back to the server in Step 2. Modifying the transaction type from BUY to SELL, allows a malicious user to game the system into processing the transaction as a SELL with the price quoted for BUY and thereby realizing the incremental profit that comes from the price spread. The value of profit per a single quantity of any security is usually very low to attract attention, however, with enough transactions spread over a period of time for larger quantities of a security can lead to significant financial impact for the organization offering the trading platform.

Previous Article
Porting the Gitorious installer from supporting only RedHat/Centos to support Ubuntu/Debian
Porting the Gitorious installer from supporting only RedHat/Centos to support Ubuntu/Debian

As our company grows we have started experiencing some pain points with using bare git repositories for our...

Next Article
How to Automatically Verify Security Requirements: SD Elements & Fortify Integration
How to Automatically Verify Security Requirements: SD Elements & Fortify Integration

We’re excited about our integration with Fortify. It follows on our recent Veracode integration. With these...

×

Schedule a live demo

First Name
Last Name
Company Name
!
Thank you!
Error - something went wrong!