Top 10 Exploitable Web Technology Flaws
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.
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.
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.