Tweet
When doing a penetration test on a web application some steps exists to aid the tester to cover most areas. Knowing what to include in a penetration test also aids in planning and allocating time or resources for the test in advance.
Footprint Web Infrastructure
The process of footprinting the web application infrastructure is the first step when pentesting a web application and aids the attacker in selecting a victim and identify vulnerable web applications.
One thing to do here would be to scan for proxies and Web Application Firewalls (WAF). Traffic may also pass through load balancers and other devices.
Attack Web Servers
When the web infrastructure is complete it is time to scan the server for known vulnerabilities and attempt to perform an attack on the vulnerabilities found. Also, execute a denial of service attack.
Analyze Web Applications
Analyze the web application functionality and what technologies it is build upon in order to identify the available and exposed attack surface.
When identifying user input entry point, consider as many possibilities as possible. A developer should never trust information such as the User-Agent, Referrer or any such information as trustworthy.
The Session ID can also be helpful in identifying the Server-Side technologies in use. Also file extensions and any other information presented to the attacker in one form or another.
Mapping the attack surface may be done by looking for the following
Attack Authentication Mechanism
Attackers will likely attempt to exploit design and implementation issues such as failure to check password strength or insecure transport of credentials to bypass authentication mechanisms.
If a web application gives too verbose an error message when a login attempt is failing, an attacker may learn that the user name is actually correct. An application should not differ between an incorrect username and an incorrect password. Both scenarios should give the same failure message to prevent the attacker from using the trial-and-error method. Some times during a password change the old password is not verified. Some applications does not have a limit on failed password change failures making it possible to guess passwords using that function. Some applications are vulnerable to the Remember Me exploit in where a username or session id is stored in cleartext in a cookie. This may enable an attacker to enumerate usernames or guess or predict sessions.
Attack Authorization Schemes
Attackers may attempt to manipulate HTTP requests to subvert the authorization scheme build in to the web application by modifying input fields user identification.
Some attacks may be done against the following
Attack Session Management Mechanism
Attackers will likely attempt to break the application session management mechanism to bypass the authentication controls which will allow the attacker to impersonate an authenticated or privileged user. It is usually done using below techniques
Perform Injection Attacks
An injection attack is performed by supply crafted malicious input that is correct according to the syntax of the language but is crafted to break the application or making the application do something it was not intended to do.
Attack Data Connectivity
Database connection strings are used in order to connect applications to back end database engines. Database connectivity attacks exploit the way applications connect to the database.
In this kind of attack a malicious user may attempt to inject parameters in a connection string, in which arguments are usually separated by a semicolon, by adding more semicolons and options of the attackers choice. Some times connection strings are build by concatenating user input with other information. An attacker may attempt to add options that help in further attacks such as disabling encryption by adding "; Encryption=off" or similar.
An attacker may also attempt to guess how the connection pool settings has been configured then construct very large SQL queries and execute numerous queries simultaneously to exhaust the connection pool.
Attack Web Application Client
This attack is performed by manipulation server-side information in the web application that then affects other users in order to access unauthorized data.
Attack Web Services
Web services may work on top of legacy web applications or similar outdated products and this may reveal an underlaying application's logic vulnerability and open the possibility for exploitation of these vulnerabilities. The issue may be the number of layers working together. Everything from a web service implementing elements such as SOAP or XML that works with WSDL, Java orsimilar that use data from databases. The total complex of web applications open for various attacks such as SOAP Injection, XML Injection, WSDL Probing, Information Leakage, Application Logic Attacks, database attacks, DoS Attacks etc.
Footprint Web Infrastructure
The process of footprinting the web application infrastructure is the first step when pentesting a web application and aids the attacker in selecting a victim and identify vulnerable web applications.
- Server Discovery - Discover the physical servers that host web applications
- Service Discovery - Discover the running services on the hosts found in the previous step and utilize these as the attack path.
- Server Identification - Do banner grabbing the software and version in use.
- Hidden Content Discovery - Extract content and functionality that is not directly linked to or reachable from any visible content.
One thing to do here would be to scan for proxies and Web Application Firewalls (WAF). Traffic may also pass through load balancers and other devices.
Attack Web Servers
When the web infrastructure is complete it is time to scan the server for known vulnerabilities and attempt to perform an attack on the vulnerabilities found. Also, execute a denial of service attack.
Analyze Web Applications
Analyze the web application functionality and what technologies it is build upon in order to identify the available and exposed attack surface.
- Identify Entry Points for User Input - Review the generated HTTP requests to identify user input entry points.
- Identify Server-Side Functionality - Observe the applications being revealed to the client in order to identify any server-side structure and functionality.
- Identify Server-Side Technologies - Fingerprint the technologies in place on the server.
- Map the Attack Surface - Attempt to identify any available attack surfaces uncovered and the associated vulnerabilities.
When identifying user input entry point, consider as many possibilities as possible. A developer should never trust information such as the User-Agent, Referrer or any such information as trustworthy.
- URLs
- HTTP Headers
- Parameters
- Cookies
The Session ID can also be helpful in identifying the Server-Side technologies in use. Also file extensions and any other information presented to the attacker in one form or another.
- JSESSIONID identifies Java
- ASPSESSIONID identifies an IIS server
- ASP.NET_SessionId identifies ASP.NET
- PHPSESSIONID identifies PHP
Mapping the attack surface may be done by looking for the following
- Client-Side Validation - Injection Attacks and Authentication Attacks
- Database Interaction - SQL Injection and Data Leakage
- File Upload/Download - Directory Traversal
- Display of User Supplied Data - Cross-Site Scripting
- Dynamic Redirects - Redirection and Header Injection
- Login - Username Enumeration and Password Attacks
- Session State - Session Hijacking and Session Fixation
- Injection Attacks - Privilege Escalation
- Cleartext Communication - Data Theft and Session Hijacking
- Error Messages - Information Leakage
- Email Interaction - Email Injection
- Application Codes - Buffer Overflows
- Third-Party Applications - Buffer Overflows
- Web Server Software - Known Vulnerability Exploitation
Attack Authentication Mechanism
Attackers will likely attempt to exploit design and implementation issues such as failure to check password strength or insecure transport of credentials to bypass authentication mechanisms.
- User Name Enumeration - Verbose Login Failure Messages and Predictable Usernames
- Cookie Exploitation - Cookie Poisoning, Cookie Sniffing and Cookie Replay
- Session Attacks - Session Prediction, Session Brute-forcing and Session Poisoning
- Password Attacks - Password Functionality Exploits, Password Guessing and Brute-Force Attacks
If a web application gives too verbose an error message when a login attempt is failing, an attacker may learn that the user name is actually correct. An application should not differ between an incorrect username and an incorrect password. Both scenarios should give the same failure message to prevent the attacker from using the trial-and-error method. Some times during a password change the old password is not verified. Some applications does not have a limit on failed password change failures making it possible to guess passwords using that function. Some applications are vulnerable to the Remember Me exploit in where a username or session id is stored in cleartext in a cookie. This may enable an attacker to enumerate usernames or guess or predict sessions.
Attack Authorization Schemes
Attackers may attempt to manipulate HTTP requests to subvert the authorization scheme build in to the web application by modifying input fields user identification.
- User ID
- User name
- Access Group
- Cost
- Filenames
- File identifiers etc.
Some attacks may be done against the following
- Uniform Resource Identifiers (URI) - Parameter Tampering
- POST Data - HTTP Headers
- Query String and Cookies - Hidden Tags
Attack Session Management Mechanism
Attackers will likely attempt to break the application session management mechanism to bypass the authentication controls which will allow the attacker to impersonate an authenticated or privileged user. It is usually done using below techniques
- Session Token Generation
- Session Tokens Prediction
- Session Tokens Tampering
- Session Tokens Handling
- Man-In-The-Middle Attack
- Session Replay
- Session Hijacking
Perform Injection Attacks
An injection attack is performed by supply crafted malicious input that is correct according to the syntax of the language but is crafted to break the application or making the application do something it was not intended to do.
- Script Injection - If user input is injected into dynamically executed code it may be constructed in such a way that the user input is interpreted and executed
- OS Command Injection - Entering user input into an input field that is in turn used by the application to execute an operation system command
- SMTP Injection - Injecting SMTP commands into a web application that has the capability to send emails may lead to manipulated emails being sent
- SQL Injection - Some user input may be used by the web application in SQL queries and the user input can sometimes be crafted to alter the query
- LDAP Injection - Take advantage of non-validated user input passed from the application to pass LDAP filters to obtain information
- XPATH Injection - Entering malicious strings into a web application in order to manipulate or alter an XPath query to obtain information
- Buffer Overflow - Inject large amounts of bogus data beyond the capabilities of the receiving buffer
- Canonicalization - Manipulate variables that reference files with the dot-dot-slash (../) in order to access restricted directories in the application
Attack Data Connectivity
Database connection strings are used in order to connect applications to back end database engines. Database connectivity attacks exploit the way applications connect to the database.
- Connection String Injection
- Connection String Parameter Pollution (CSPP) Attacks
- Connection Pool Denial of Service
In this kind of attack a malicious user may attempt to inject parameters in a connection string, in which arguments are usually separated by a semicolon, by adding more semicolons and options of the attackers choice. Some times connection strings are build by concatenating user input with other information. An attacker may attempt to add options that help in further attacks such as disabling encryption by adding "; Encryption=off" or similar.
An attacker may also attempt to guess how the connection pool settings has been configured then construct very large SQL queries and execute numerous queries simultaneously to exhaust the connection pool.
Attack Web Application Client
This attack is performed by manipulation server-side information in the web application that then affects other users in order to access unauthorized data.
- Cross-Site Script - Redirection Attacks
- HTTP Header Injection - Frame Injection
- Request Forgery Attack - Session Fixation
- Privacy Attacks - ActiveX Attacks
Attack Web Services
Web services may work on top of legacy web applications or similar outdated products and this may reveal an underlaying application's logic vulnerability and open the possibility for exploitation of these vulnerabilities. The issue may be the number of layers working together. Everything from a web service implementing elements such as SOAP or XML that works with WSDL, Java orsimilar that use data from databases. The total complex of web applications open for various attacks such as SOAP Injection, XML Injection, WSDL Probing, Information Leakage, Application Logic Attacks, database attacks, DoS Attacks etc.
Comment