Understanding Weak Points in Web Application Architecture
Information collected during the reconnaissance process can unveil critical aspects of a web application's architecture, including technologies used, API endpoints, functionality, domains, configurations, and authentication systems. Vulnerabilities in web applications often stem from poorly designed architectures rather than poorly written methods. Secure architectures are vital to prevent exploits like Cross-Site Scripting attacks, which take advantage of poorly designed application structures to execute malicious scripts on users' browsers.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
IDENTIFYING WEAK POINTS IN APPLICATION ARCHITECTURE Based on the book Web Application Security: Exploitation and Countermeasures for Modern Web Applications by Andrew Hoffman (2020)
WHAT AND WHY? The information collected during the recon process may reveal the architecture of the target web application. - Technology used in the web application - List of API endpoints by HTTP verb - List of API endpoint shapes (where available) - Functionality included in the web application (e.g., comments, auth, notifications, etc.) - Domains used by the web application - Configurations found (e.g., Content Security Policy or CSP) - Authentication/session management systems - ... Most vulnerabilities in a web application stem from improperly designed application architecture rather than from poorly written methods. Ultimately, the architecture of an application and the architecture of the modules/dependencies within that application are fantastic markers of weak points from which vulnerabilities may arise. 2
SECURE VERSUS INSECURE ARCHITECTURES A single vulnerability may be the result of a poorly written method, but multiple vulnerabilities are probably the sign of weak application architecture. Take Cross-Site Scripting (XSS) attack as an example. XSS attacks exploit vulnerabilities in web applications by taking advantage of the fact that web applications execute scripts on users browsers. Any type of dynamically created script that is executed puts a web application at risk if the script being executed can be contaminated or modified in any way in particular by an end user. 3
THE CROSS-SITE SCRIPTING ATTACK In XSS, an attacker injects his/her malicious code to the victim s browser via the target website. When code comes from a website, it is considered as trusted with respect to the website, so it can access and change the content on the pages, read cookies belonging to the website and sending out requests on behalf of the user. Basically, code can do whatever the user can do inside the session. 4
THE CROSS-SITE SCRIPTING ATTACK (CONT.) An insecure application (against XSS attacks) does not implement any of the following protections: 1) It might not reject a script when a request to store a comment is made to an API endpoint; 2) Its database might not reject the script, and 3) It might not perform proper filtration and sanitization against the string representing the request message. Ultimately, the script is loaded into the DOM and evaluated as a DOM message, hence resulting in script execution. <script> ...; </script> A secure application, on the other hand, likely has one or many of the preceding protections. 5
SECURE VERSUS INSECURE ARCHITECTURES (CONT.) In a secure application development, security is integrated into the development process, prior to and during program development. Result? A secure application architecture In an insecure application development, security is developed during program development, possibly up to the individual programmers. Result? - Some of the applications might not have implemented any security features. - Even an application written by engineers skilled in application security would likely have security holes eventually if its application architecture was inherently insecure. 6
THE CROSS-SITE SCRIPTING ATTACK (CONT.) Each DOM injection must be examined and, if necessary, sanitized. A simple method built into the UI like the following would eliminate most XSS risk: 7
SECURE VERSUS INSECURE ARCHITECTURES (CONT.) Lesson learned? Rather than relying on individual programmers to build security into each of the individual programs, the software designer/architect ought to analyze the vulnerabilities associated with the whole application and integrate security features into and throughout the whole application. Special attention to user input sanitization before data are used and/or stored That is, security ought to be considered from the very beginning of the development process (system analysis, high-level design, low-level design, coding, ...). 8
MULTIPLE LAYERS OF SECURITY A vulnerability can occur as a result of insufficient security mechanisms at more than one layer. Example: XSS vulnerability can be exploited in any of the following layers. - API POST - Database Write - Database Read - API GET - Client Read 9
MULTIPLE LAYERS OF SECURITY (CONT.) An application continues to evolve with new features/programs added and/or changed. An initially secure application may evolve into an insecure application (e.g., an insecure feature/program has been added). An application is only as secure as the weakest link in its architecture. Instead of implementing security at only one of the multiple layers (e.g., API POST layer), security mechanisms are implemented in multiple locations (e.g., API POST + Database Write). Plus, different layers of security can support different mechanisms for defending against a particular type of attack. Different mechanisms can detect different attack payloads. 10
MULTIPLE LAYERS OF SECURITY (CONT.) The most secure web applications introduce security mechanisms at many layers, while insecure web applications introduce security mechanisms at only one or two layers. When testing web applications, you want to look for functionality in an application that makes use of a few security mechanisms or requires a significant number of layers. The attackers: If you can isolate and determine what functionality meets this criteria, it should be prioritized above the rest when looking for vulnerabilities as it is more likely to be exploitable. The protectors? 11
ADOPTION AND REINVENTION The question: Should the Web application developer adopt or reinvent an algorithm/method/code? In general, a securely architected application will only reinvent features that are purely functional, such as reinventing a schema for storing comments, or a notification system. Features that require deep expertise in mathematics, operating systems, or hardware should probably be left alone by web application developers. This includes databases, process isolation, and most memory management. Standardized algorithms are results of rigorous reviewing and testing. Applications full of custom databases, custom cryptography, and special hardware-level optimization often are the easiest to break into. 12
SUMMARY Often, the architectural design of an application leads to either a plethora of security bugs or a relatively low number of security bugs based on how the application s defenses are designed and distributed throughout the codebase. The ability to identify weak points in an application s architecture is a useful recon technique. When investigating a web application as part of your recon efforts, make sure to consider the overall security architecture of the application as you make your map of it. 13
