• United States



Senior Editor, Network World

The 10 worst Web application-logic flaws that hackers love to abuse

May 03, 20126 mins
Data and Information SecuritySecurityVulnerabilities

Hackers are always hunting to find business-logic flaws, especially on the Web, in order to exploit weaknesses in online ordering and other processes. NT OBJECTives, which validates Web application security, says these are the top 10 business-logic flaws they see all the time.

1. Authentication flags and privilege escalation

Since applications have their own access-control lists and privileges, if the implementation of the authorization is weak, it opens up vulnerabilities that can be exploited, such as accessing another’s content or becoming a higher-level user with greater permissions. What’s needed is identifying parameter names that have something to do with ACL/permission that could become a target, and the tester can use fuzzing tools to try and change bit patterns or permission flags, which may show the point at which exploitation, escalating privileges or bypassing authentication can be achieved by an attacker.

ROUNDUP: The Most Mortifying Moments in IT Security HistoryA

FBI: Investment scams, Blackhole exploit kit lead cybercrime wave

2. Critical parameter manipulation and access to unauthorized information/content

HTTP GET and POST requests are typically accompanied with several parameters when submitted to the application, typically in the form of name/value pairs, JSON, XML and so forth, but they can be tampered with and guessed by predicting. Tests for this look for easily guessable values and whether a parameter’s value can be changed in order to gain unauthorized access.

3. Developer’s cookie tampering and business process/logic bypass

Cookies are often used to maintain state over HTTP, but developers are not just using session cookies, but are building data internally using session-only variables. Application developers set new cookies on the browser at important junctures which exposes logic holes. The danger is that these cookies can be reverse engineered or have values that can be guessed or deciphered and attackers try to identify these holes that are easy to exploit. Tests here typically involve analysis of cookies delivered during profiling, and looking for easily guessable values, and whether a cookie value can be changed.

4. LDAP parameter identification and critical infrastructure access

LDAP is becoming an important aspect for large applications and may get integrated with “single sign-on” as well. Many infrastructure layer tools like SiteMinder and Load Balancer use LDAP for both authentication and authorization. LDAP parameters can carry business-logic decision flags that can be abused or leveraged. Attackers can find business-layer bypasses and logical injections if the application is not doing enough validation. Tests for this focus on finding parameters linked with LDAP, such as those taking email or usernames, which are prospective targets.

5. Business constraint exploitation

The application’s business logic should have defined rules and constraints, but if poorly designed, attackers can crawl them and browse through hidden fields and understand their context. So it’s necessary to test hidden parameters and values, checking business-specific calls that can become a target and manipulated.

6. Business flow bypass

Applications include flows that are controlled by redirects and page transfers. However, in many cases, this flow can be bypassed, which can lead to an error condition or information leakage, which can help an attacker identify critical backend information. It’s necessary to test whether business functionality and parameters can be tampered with through a proxy.

7. Exploiting client-side business routines embedded in JavaScript, Flash or Silverlight

Many business applications now run on rich Internet application frameworks leveraging JavaScript, Flash and Silverlight, and in many cases the logic is embedded in the client-side component. These can be reverse engineered, and if it is Flash and Silverlight, both of these files can be decompiled and the actual logic used by the application can be discovered. JavaScript can be debugged line by line to identify embedded logic. This could include logic for cryptography algorithms, credential storage, privilege management and other security. This may lead to possible exploits. To check for these kind of weaknesses, it’s necessary to analyze the Document Object Model (DOM), identify variables on a browser stack, and look for suspicious values and parameters that can be exploited in DOM.

8. Identity or profile extraction

A critical parameter in authenticated applications, the user’s identity is maintained using session or other forms of tokens. Attackers can identify these token parameters in poorly designed and developed applications, opening up the potential for abuse and systemwide exploitation. The token may only be using a sequential number or guessable username. To test for this, it’s necessary to look for parameters that are controlling profiles; if it’s possible to decipher, guess or reverse engineer tokens, the game is all but finished.

9. File or unauthorized URL access and business information extraction

Business applications contain critical information in their features, in the files that are exported and in the export functionality. Users can export their data in a selected file format (PDF, XLS or CSV) and download it. If this functionality is carelessly implemented, it can enable asset leakage. To test for this, it’s necessary to identify call functionalities based on parameter names like file, doc, and dir, which will point you to possible unauthorized file-access vulnerabilities, and then a good test is doing basic brute force or guesswork to fetch another user’s files from a server.

10. Denial of service (DoS) with business logic

Denial-of-service vulnerabilities for business applications pose serious issues because if exploited, the application can be brought down for a length of time or at a critical juncture. Sometimes attackers can identify a loophole and try to exploit it during a DoS condition. There are no universal DoS attacks like TCP flooding on networking at the application layer, but in some cases, infinite loops implemented in the application layer can lead to a DoS condition. It’s important to test applications against a threat model and provide defense at the application layer.

In its report on the “Top 10 Business Logic Attack Vectors,” NT OBJECTives says identifying business-logic flaws in custom-designed Web applications is not just a matter of automated scan testing but also a manual review of the application security and logic with “human intelligence.”

Ellen Messmer is senior editor at Network World, an IDG publication and website, where she covers news and technology trends related to information security.

Read more about wide area network in Network World’s Wide Area Network section.