Application or business logic refers to the behavior that is defined directly by the developer, i.e., it is not the general functionality that is provided as part of the application server platform such as authentication, but rather the application-specific operations that define the application functionality such as item pricing rules, usage flows, presentation layout, etc. What are the most common attacks against application logic? What sort of damage do these attacks inflict?
Application logic attacks are characterized by the exploitation of a function or a feature that is specific to the application. They are different from one incident to another based on the way they exploit the application. For example, a malicious user could exploit the way discounts are designed in an online retail store by discovering a flaw that allows for discounts to be applied multiple times to the same item and reduce its price.
Unlike SQL injection attacks, which are relevant to any system that takes user input and has a relational database backend, each application logic attack is idiosyncratic to its application. As you can imagine, the damage may be great, ranging from loss of revenue -- such as in the discount example -- to exposing private data. These attacks pose the same level of risk as any other kind of attack, and they're probably a greater risk because the dangers are more difficult to identify than the general, known attack patterns. They are very difficult to discover with penetration testing, which leaves applications open to exploitation to hackers. Attacks on application logic are increasingly popular. Why the rise in prevalence?
As developers become more aware of general attack patterns such as SQL injections and XSS attacks, some of them are likely to follow practices that prevent these problems. However, security is a much broader issue which makes categorizing vulnerabilities difficult due to the wide variety of exploitation patterns, and application specific attacks in particular, because they tend to be unique to each application.
Are many of these threats coming from inside the company?
Yes. The Wall Street Journal published an article on February 13, 2006, indicating that since 1999, there are as many companies reporting incidents from the inside as there are companies reporting incidents from the outside. In addition, over 28% of incidents reported come from the company employees themselves. It is critical to know that security is not a list of measures you take to protect and isolate the company form the outside, but rather it is a list of measures and activities you take to protect the application. Many of these threats appear to involve unauthorized users accessing sensitive information. Would logic attacks be thwarted with better authentication and authorization methods?
Not at all. Take my online retail store example. A valid, authenticated and authorized user can purchase an unfairly priced item by applying a discount more than he or she should. The user uses a real credit card to purchase the item. The problem here is that the transaction can go unnoticed, since it takes place among thousands of others.
An incident like this took place in August 2005 on the Paradise Poker online gambling Web site. Regular, authorized users were gambling online but were able to predict the dealer's hands based on time delays in the system. Such a flaw gave the users an advantage and allowed them to win a lot of money. Again, these were authorized users and the Web site cannot go after them, since it cannot distinguish those who won legitimately from those who won by knowing about the delay problems. The users did not do anything illegal. It seems that, like it is with many application attacks, integration of security into the software development life cycle (SDLC) would eliminate many of these threats. What specific types of security are best for thwarting logic attacks?
That is correct; the key to addressing application security is to build in security into the application from the beginning instead of testing it later. That means there should be a process where security-related activities are incorporated with quality-related activities. Many organizations these days believe that in order to achieve quality, a variety of practices needs to be taken into account throughout the SDLC. In the past, most would write the system and then start testing it only to be surprised by unexpected problems and faced with delays and budget overruns.
Today, many professional organizations have learned from these mistakes and implemented practices such as coding standard enforcement and testing activities early, as soon as code is written, in order to eliminate the surprise factor at the end of the project and maintain a visible predictable process that meets the stakeholder expectations. Well, at least many do. However, when it comes to security, people seem to make the same mistakes they did with quality in the past. They leave security as a separate activity at the end of the project once functional and quality requirements have been met and then run into the surprises and problems, or in some cases scrapping the security activities all together because they are already late.
There is nothing special about security compared to the general software quality problem. Both cannot be solved by mere testing and both cannot be solved by isolated activities at the end of the SDLC. Security, and especially application logic security, is addressed by writing and maintaining a clearly defined security policy document (just like functional requirements). The policy states what the risks are and how they are addressed. Enforce these policies at the code level with static analysis and then again with regression testing that ensures that security problems do not occur at any point during the project. Only after these steps can you progress through the project with full control and predictability in terms of deadlines, quality, security and overall progress. After a logic attack has occurred, how can you mitigate the damage?
Fixing the damage after an incident depends on the situation. However, many organizations learn the hard way. This could be a learning opportunity so that practices are put in place to prevent a greater damage from taking place again. Is there any additional information you would like our readers to know about application logic security?
Like quality-related activities such as requirement management, test management, project visibility, code reviews and code analysis, automation is the key to ensure that these practices are being applied. If you mandate your developers do things manually, things tend to fall through the cracks and productivity is hurt. Automation technologies can enforce application security policies at the code level and generate and execute regression tests for these policies to ensure that the implementation is done correctly. These technologies have come a long way and their effectiveness is being proven. Automated error prevention throughout the SDLC assists people in performing the right activities, streamlines these activities at the individual and the team level, and provides the visibility and control that managers need over these activities.
Rami Jaamour is a member of SearchAppSecurity.com's Expert Panel. He is also a software engineer and assistant product manager at Parasoft.
Dig Deeper on Building security into the SDLC (Software development life cycle)