Weak Points in Web Application Architecture
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
•
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
THE CROSS-SITE SCRIPTING ATTACK
(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
SECURE VERSUS INSECURE
ARCHITECTURES
(CONT.)
7
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:
•
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
SECURE VERSUS INSECURE
ARCHITECTURES
(CONT.)
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
•
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
MULTIPLE LAYERS OF SECURITY
(CONT.)
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
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.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
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.
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
