Long ago, script kiddies developed the skills or acquired the tools to exploit the vulnerabilities that enable cross-site scripting (XSS) and SQL injection (SQLi) attacks, but exploiting business logic flaws has largely eluded less skilled attackers. The popularity and relative ease of exploiting XSS or SQLi vulnerabilities has led attackers to place less emphasis on challenging business logic flaws. Yet, according to 88% of the 600 security pros surveyed by the Ponemon Institute LLC, business logic attacks are as important or more important than any security issue they encounter.
As more programmers, and even nonprogrammers, develop Web applications or mashups, it is critical to ensure that sound Web application security programming principles are followed.
In this tip, we'll discuss the threat business logic attacks pose to businesses and some mitigations enterprises can put in place to defend against them, which include emphasizing the role of security in the software development lifecycle (SDLC).
Business logic attacks explained
In its study, Ponemon defined business logic abuse as the result of "the criminal discovering a flaw in the business logic or functionality of a website." Business logic attacks can be difficult to defend against because they typically require nothing more than what an enterprise would expose via its customer-facing Web applications or access to any Web applications. The vulnerabilities range from the very simple to the very complex and are not limited to just custom-developed Web applications. A 2007 report from WhiteHat Security detailed some common business logic flaws that are still being exploited today, such as weak password-recovery validation and improper Web application coding, particularly with regard to the use of encryption techniques and input validation. In recent years, business logic attacks have become more automated.
The main risks posed by business logic attacks are lost revenue and unauthorized access to confidential information. The specific losses stemming from business logic abuse are hard to estimate, but the remediation time could be expensive. Such flaws can also be used as a stepping stone for infiltrating a network to access sensitive and valuable information. A well-known example of a business logic attack is when grey-hat hacker weev used an open API to recover iPad owners' email addresses that AT&T had inadvertently published. As attackers become more creative, this problem will continue to grow as business logic flaws are targeted in applications other than Web applications, such as ATMs.
Is security part of your software development lifecycle?
It can be difficult to fix business logic flaws because of complex Web applications and their integration with an enterprise's business. Traditional Web application security tools, including Web application security scanners and firewalls, are ineffective against these types of attacks since the attacks are typically site specific.
From the editors: More on secure Web development
Learn to use automated attack toolkits to secure Web applications.
Treat security vulnerabilities as bugs to improve Web development processes.
Traditional security tools like intrusion detection systems are also less effective because Web application traffic is typically encrypted. To overcome this hurdle, IT must terminate the SSL/TLS connection at a load balancer (or similar device) and then inspect the unencrypted traffic behind the load balancer. All of these tools could be used in an investigation and programmed to look for anomalies in Web application traffic or for unexpected values in certain fields. Several vendors offer tools for detecting and preventing business logic flaws, such as SilverTail Systems and WhiteHat Security. Such third-party vendors can offer effective assistance, but as with any vendor engagement -- depending on specific issues and costs -- your mileage may vary.
One of the most critical aspects of remediating business logic flaws is improving the security processes in the software development lifecycle. As more programmers, and even nonprogrammers, develop Web applications or mashups, it is critical to ensure that sound Web application security programming principles are followed.
An organization's SDLC should be updated to include checks for the business logic flaws outlined by WhiteHat Security, including abuse of functionality, insufficient process validation, information leakage, weak password recovery validation and predictable resource location and insufficient authorization. To make it much easier for the developers to follow good security practices when developing Web applications, try including checks in the integrated development environment used by the developers. Training should also be provided to developers, quality assurance and information security professionals on business logic flaws so they can identify attacks that are not detected by the automated tools.
Listen to this tip
as an MP3!
Listen to How to negate business logic attack risk: Improve security in the SDLC as an MP3 here.
As businesses have become more aware of business logic abuse, more resources have been devoted to securing Web applications. This increase in resources has been significant given the large number of Web applications that are threatened, but these flaws account for a small part of cybercrime losses. Organizations can deploy the best perimeter defenses and harden every server and desktop, but a business logic attack can bypass all these security controls to achieve an attacker's goal. Enterprises should include training on business logic flaws in their information security programs to raise awareness and minimize the costs of business logic attacks.
About the author:
Nick Lewis (CISSP) is an information security architect at Saint Louis University. Nick received his Master of Science in information assurance from Norwich University in 2005, and in telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick previously worked at the University of Michigan and at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.