diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel.md deleted file mode 100644 index cc00ac98b7..0000000000 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel.md +++ /dev/null @@ -1,7 +0,0 @@ -# Testing for Credentials Transported over an Encrypted Channel - -|ID | -|------------| -|WSTG-ATHN-01| - -This content has been merged into: [Testing for Sensitive Information Sent via Unencrypted Channels](../09-Testing_for_Weak_Cryptography/03-Testing_for_Sensitive_Information_Sent_via_Unencrypted_Channels.md) diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/01-Testing_for_Default_Credentials.md similarity index 99% rename from document/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials.md rename to document/4-Web_Application_Security_Testing/04-Authentication_Testing/01-Testing_for_Default_Credentials.md index 1dc00bd70c..fb310db3a2 100644 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials.md +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/01-Testing_for_Default_Credentials.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-ATHN-02| +|WSTG-ATHN-01| ## Summary diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Weak_Lock_Out_Mechanism.md similarity index 99% rename from document/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism.md rename to document/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Weak_Lock_Out_Mechanism.md index 47deaed10c..b1b51a6c27 100644 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism.md +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Weak_Lock_Out_Mechanism.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-ATHN-03| +|WSTG-ATHN-02| ## Summary diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Bypassing_Authentication_Schema.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Bypassing_Authentication_Schema.md similarity index 96% rename from document/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Bypassing_Authentication_Schema.md rename to document/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Bypassing_Authentication_Schema.md index e3b8d0035c..d79e985f47 100644 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Bypassing_Authentication_Schema.md +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Bypassing_Authentication_Schema.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-ATHN-04| +|WSTG-ATHN-03| ## Summary @@ -43,7 +43,7 @@ If a web application implements access control only on the log in page, the auth Another problem related to authentication design is when the application verifies a successful log in on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request or when the parameters are stored in a cookie. ```html -https://www.site.com/page.asp?authenticated=no +http://www.site.com/page.asp?authenticated=no raven@blackbox /home $nc www.site.com 80 GET /page.asp?authenticated=yes HTTP/1.0 @@ -121,14 +121,13 @@ a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";} // original value: a:2:{s:11 Let's disassemble what we did in this string: 1. `autologinid` is now a boolean set to `true`: this can be seen by replacing the MD5 value of the password hash (`s:32:"8b8e9715d12e4ca12c4c3eb4865aaf6a"`) with `b:1` -2. `userid` is now set to the admin id: this can be seen in the last piece of the string, where we replaced our regular user ID (`s:4:"1337"`) with `s:1:"2"` +2. `userid` is now set to the admin ID: this can be seen in the last piece of the string, where we replaced our regular user ID (`s:4:"1337"`) with `s:1:"2"` ## Tools - [WebGoat](https://owasp.org/www-project-webgoat/) -- [Zed Attack Proxy (ZAP)](https://www.zaproxy.org) +- [OWASP Zed Attack Proxy (ZAP)](https://www.zaproxy.org) ## References - [Niels Teusink: phpBB 2.0.12 authentication bypass](http://blog.teusink.net/2008/12/classic-bug-phpbb-2012-authentication.html) -- [David Endler: "Session ID Brute Force Exploitation and Prediction"](https://www.cgisecurity.com/lib/SessionIDs.pdf) diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/05-Testing_for_Vulnerable_Remember_Password.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Vulnerable_Remember_Password.md similarity index 99% rename from document/4-Web_Application_Security_Testing/04-Authentication_Testing/05-Testing_for_Vulnerable_Remember_Password.md rename to document/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Vulnerable_Remember_Password.md index 608f228019..e9a15bcabe 100644 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/05-Testing_for_Vulnerable_Remember_Password.md +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Vulnerable_Remember_Password.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-ATHN-05| +|WSTG-ATHN-04| ## Summary diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/06-Testing_for_Browser_Cache_Weaknesses.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/05-Testing_for_Browser_Cache_Weaknesses.md similarity index 99% rename from document/4-Web_Application_Security_Testing/04-Authentication_Testing/06-Testing_for_Browser_Cache_Weaknesses.md rename to document/4-Web_Application_Security_Testing/04-Authentication_Testing/05-Testing_for_Browser_Cache_Weaknesses.md index 96873e55f5..3def0e12c3 100644 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/06-Testing_for_Browser_Cache_Weaknesses.md +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/05-Testing_for_Browser_Cache_Weaknesses.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-ATHN-06| +|WSTG-ATHN-05| ## Summary diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/06-Testing_for_Weak_Password_Policy.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/06-Testing_for_Weak_Password_Policy.md new file mode 100644 index 0000000000..fedd742369 --- /dev/null +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/06-Testing_for_Weak_Password_Policy.md @@ -0,0 +1,36 @@ +# Testing for Weak Authentication Methods + +|ID | +|------------| +|WSTG-ATHN-06| + +## Summary + +The most prevalent and most easily administered authentication mechanism is a static password. The password represents the keys to the kingdom, but is often subverted by users in the name of usability. In each of the recent high profile hacks that have revealed user credentials, it is lamented that most common passwords are still: `123456`, `password` and `qwerty`. + +Additionally, applications may utilize alternative credentials that are treated the same as a password, but are considerably weaker, such as a birthdates, social security numbers, PINs, or security questions. In some scenarios, these more easily guessed credentials may act as the only user supplied value for authentication. + +## Test Objectives + +- Determine the resistance of the application against brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse, and aging requirements of passwords. + +## How to Test + +1. What characters are permitted and forbidden for use within a password? Is the user required to use characters from different character sets such as lower and uppercase letters, digits and special symbols? +2. How often can a user change their password? How quickly can a user change their password after a previous change? Users may bypass password history requirements by changing their password 5 times in a row so that after the last password change they have configured their initial password again. +3. When must a user change their password? + - Both [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) and [NCSC](https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry) recommend **against** forcing regular password expiry, although it may be required by standards such as PCI DSS. +4. How often can a user reuse a password? Does the application maintain a history of the user's previous used 8 passwords? +5. How different must the next password be from the last password? +6. Is the user prevented from using his username or other account information (such as first or last name) in the password? +7. What are the minimum and maximum password lengths that can be set, and are they appropriate for the sensitivity of the account and application? +8. Is it possible to set common passwords such as `Password1` or `123456`? +9. Is the credential chosen for the user by the application, such as a social security number or a birthdate? Is the credential that's utilized in lieu of a standard password easily obtainable, predictable, or susceptible to brute-force attacks? + +## Remediation + +To mitigate the risk of easily guessed passwords facilitating unauthorized access there are two solutions: introduce additional authentication controls (i.e. two-factor authentication) or introduce a strong password policy. The simplest and cheapest of these is the introduction of a strong password policy that ensures password length, complexity, reuse and aging; although ideally both of them should be implemented. + +## References + +- [Brute Force Attacks](https://owasp.org/www-community/attacks/Brute_force_attack) diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Authentication_Methods.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Authentication_Methods.md index 0c900d5403..fedd742369 100644 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Authentication_Methods.md +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Authentication_Methods.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-ATHN-07| +|WSTG-ATHN-06| ## Summary diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/08-Testing_for_Weak_Security_Question_Answer.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Security_Question_Answer.md similarity index 97% rename from document/4-Web_Application_Security_Testing/04-Authentication_Testing/08-Testing_for_Weak_Security_Question_Answer.md rename to document/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Security_Question_Answer.md index 8782016ca0..2a799e0b4d 100644 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/08-Testing_for_Weak_Security_Question_Answer.md +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Security_Question_Answer.md @@ -2,11 +2,11 @@ |ID | |------------| -|WSTG-ATHN-08| +|WSTG-ATHN-07| ## Summary -Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords (see [Testing for weak password change or reset functionalities](09-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md), or as extra security on top of the password. +Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords (see [Testing for weak password change or reset functionalities](08-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md), or as extra security on top of the password. They are typically generated upon account creation and require the user to select from some pre-generated questions and supply an appropriate answer. They may allow the user to generate their own question and answer pairs. Both methods are prone to insecurities. Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds. Security questions and answers rely on the secrecy of the answer. Questions and answers should be chosen so that the answers are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that sites implement promote answers that are pseudo-private. @@ -45,7 +45,7 @@ Try to create security questions by creating a new account or by configuring you ### Testing for Brute-forcible Answers -Use the methods described in [Testing for Weak lock out mechanism](03-Testing_for_Weak_Lock_Out_Mechanism.md) to determine if a number of incorrectly supplied security answers trigger a lockout mechanism. +Use the methods described in [Testing for Weak lock out mechanism](02-Testing_for_Weak_Lock_Out_Mechanism.md) to determine if a number of incorrectly supplied security answers trigger a lockout mechanism. The first thing to take into consideration when trying to exploit security questions is the number of questions that need to be answered. The majority of applications only need the user to answer a single question, whereas some critical applications may require the user to answer two or even more questions. diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/08-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md similarity index 96% rename from document/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md rename to document/4-Web_Application_Security_Testing/04-Authentication_Testing/08-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md index 71424552da..53f652f429 100644 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/08-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md @@ -2,11 +2,11 @@ |ID | |------------| -|WSTG-ATHN-09| +|WSTG-ATHN-08| ## Summary -For any application that requires the user to authenticate with a password, there must be a mechanism by which the user can regain access to their account if they forget their password. Although this can sometimes be a manual process that involves contacting the owner of the website or a support team, users are frequently allowed to carry out a self-service password reset, and to regain access to their account by providing some other evidence of their identity. +For any application that requires the user to authenticate with a password, there must be a mechanism by which the user can regain access to their account if they forget their password. Although this can sometimes be a manual process that involves contacting the owner of the site or a support team, users are frequently allowed to carry out a self-service password reset, and to regain access to their account by providing some other evidence of their identity. As this functionality provides a direct route to compromise the user's account, it is crucial that it is implemented securely. @@ -107,7 +107,7 @@ In this model, the user is emailed a link that contains a token. They can then c - Can you inject a different host header? - If the application trusts the value of the `Host` header and uses this to generate the password reset link, it may be possible to steal tokens by injecting a modified `Host` header into the request. See the [Testing for Host Header Injection](../07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection.md) guide for further information. + If the application trusts the value of the `Host` header and uses this to generate the password reset link, it may be possible to steal tokens by injecting a modified `Host` header into the request. See the [Testing for Host Header Injection](../07-Input_Validation_Testing/16-Testing_for_Host_Header_Injection.md) guide for further information. - Is the link exposed to third parties? @@ -147,7 +147,7 @@ Rather than sending a token in an email, an alternative approach is to send it v Sending an SMS or triggering an automated phone call to a user is significantly more disruptive than sending an email, and could be used to harass a user, or even carry out a denial of service attack against their phone. The application should implement rate limiting to prevent this. - Additionally, SMS messages and phone calls often incur financial costs for the sending party. If an attacker is able to cause a large number of messages to be sent, this could result in significant costs for the website operator. This is especially true if they are sent to international or premium rate numbers. However, allowing international numbers may be a requirement of the application. + Additionally, SMS messages and phone calls often incur financial costs for the sending party. If an attacker is able to cause a large number of messages to be sent, this could result in significant costs for the site operator. This is especially true if they are sent to international or premium rate numbers. However, allowing international numbers may be a requirement of the application. - Is SMS or a phone call considered sufficiently secure? @@ -161,7 +161,7 @@ Rather than sending a token in an email, an alternative approach is to send it v Rather than sending them a link or new password, security questions can be used as a mechanism to authenticate the user. This is considered to be a weak approach, and should not be used if better options are available. -See the [Testing for Weak Security Questions](08-Testing_for_Weak_Security_Question_Answer.md) guide for further information. +See the [Testing for Weak Security Questions](07-Testing_for_Weak_Security_Question_Answer.md) guide for further information. ### Authenticated Identity and Configuration Changes diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/10-Testing_for_Weaker_Authentication_in_Alternative_Channel.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weaker_Authentication_in_Alternative_Channel.md similarity index 64% rename from document/4-Web_Application_Security_Testing/04-Authentication_Testing/10-Testing_for_Weaker_Authentication_in_Alternative_Channel.md rename to document/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weaker_Authentication_in_Alternative_Channel.md index a032f76bd3..a7192701c5 100644 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/10-Testing_for_Weaker_Authentication_in_Alternative_Channel.md +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weaker_Authentication_in_Alternative_Channel.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-ATHN-10| +|WSTG-ATHN-09| ## Summary @@ -10,12 +10,12 @@ Even if the primary authentication mechanisms do not include any vulnerabilities The alternative user interaction channels could be utilized to circumvent the primary channel, or expose information that can then be used to assist an attack against the primary channel. Some of these channels may themselves be separate web applications using different hostnames or paths. For example: -- Standard website -- Mobile, or specific device, optimized website -- Accessibility optimized website -- Alternative country and language websites -- Parallel websites that utilize the same user accounts (e.g. another website offering different functionally of the same organization, a partner website with which user accounts are shared) -- Development, test, UAT and staging versions of the standard website +- Standard site +- Mobile, or specific device, optimized site +- Accessibility optimized site +- Alternative country and language sites +- Parallel sites that utilize the same user accounts (e.g. another site offering different functionally of the same organization, a partner site with which user accounts are shared) +- Development, test, UAT and staging versions of the standard site But they could also be other types of application or business processes: @@ -24,7 +24,7 @@ But they could also be other types of application or business processes: - Call center operators - Interactive voice response or phone tree systems -Note that the focus of this test is on alternative channels; some authentication alternatives might appear as different content delivered via the same website and would almost certainly be in scope for testing. These are not discussed further here, and should have been identified during information gathering and primary authentication testing. For example: +Note that the focus of this test is on alternative channels; some authentication alternatives might appear as different content delivered via the same site and would almost certainly be in scope for testing. These are not discussed further here, and should have been identified during information gathering and primary authentication testing. For example: - Progressive enrichment and graceful degradation that change functionality - Site use without cookies @@ -35,9 +35,9 @@ Even if the scope of the test does not allow the alternative channels to be test ## Example -The primary website is `https://www.example.com` and authentication functions always take place on pages using TLS `https://www.example.com/myaccount/`. +The primary site is `https://www.example.com` and authentication functions always take place on pages using TLS `https://www.example.com/myaccount/`. -However, a separate mobile-optimized website exists that does not use TLS at all, and has a weaker password recovery mechanism `https://m.example.com/myaccount/`. +However, a separate mobile-optimized site exists that does not use TLS at all, and has a weaker password recovery mechanism `https://m.example.com/myaccount/`. ## Test Objectives @@ -48,15 +48,15 @@ However, a separate mobile-optimized website exists that does not use TLS at all ### Understand the Primary Mechanism -Fully test the website's primary authentication functions. This should identify how accounts are issued, created or changed and how passwords are recovered, reset, or changed. Additionally knowledge of any elevated privilege authentication and authentication protection measures should be known. These precursors are necessary to be able to compare with any alternative channels. +Fully test the site's primary authentication functions. This should identify how accounts are issued, created or changed and how passwords are recovered, reset, or changed. Additionally knowledge of any elevated privilege authentication and authentication protection measures should be known. These precursors are necessary to be able to compare with any alternative channels. ### Identify Other Channels Other channels can be found by using the following methods: - Reading site content, especially the home page, contact us, help pages, support articles and FAQs, T&Cs, privacy notices, the robots.txt file and any sitemap.xml files. -- Searching HTTP proxy logs, recorded during previous information gathering and testing, for strings such as "mobile", "android", blackberry", "ipad", "iphone", "mobile app", "e-reader", "wireless", "auth", "sso", "single sign on" in URL paths and body content. -- Use search engines to find different websites from the same organization, or using the same domain name, that have similar home page content or which also have authentication mechanisms. +- Searching HTTP proxy logs, recorded during previous information gathering and testing, for strings such as "mobile", "Android", blackberry", "iPad", "iPhone", "mobile app", "e-reader", "wireless", "auth", "sso", "single sign on" in URL paths and body content. +- Use search engines to find different sites from the same organization, or using the same domain name, that have similar home page content or which also have authentication mechanisms. For each possible channel confirm whether user accounts are shared across these, or provide access to the same or similar functionality. @@ -64,7 +64,7 @@ For each possible channel confirm whether user accounts are shared across these, For each alternative channel where user accounts or functionality are shared, identify if all the authentication functions of the primary channel are available, and if anything extra exists. It may be useful to create a grid like the one below: - | Primary | Mobile | Call Center | Partner Website | + | Primary | Mobile | Call Center | Partner site | |---------|---------|--------------|-----------------| | Register| Yes | - | - | | Log in | Yes | Yes | Yes(SSO) | @@ -72,13 +72,13 @@ For each alternative channel where user accounts or functionality are shared, id |Password reset | Yes | Yes | - | | - | Change password | - | - | -In this example, mobile has an extra function "change password" but does not offer "log out". A limited number of tasks are also possible by phoning the call center. Call centers can be interesting, because their identity confirmation checks might be weaker than the website's, allowing this channel to be used to aid an attack against a user's account. +In this example, mobile has an extra function "change password" but does not offer "log out". A limited number of tasks are also possible by phoning the call center. Call centers can be interesting, because their identity confirmation checks might be weaker than the site's, allowing this channel to be used to aid an attack against a user's account. While enumerating these it is worth taking note of how session management is undertaken, in case there is overlap across any channels (e.g. cookies scoped to the same parent domain name, concurrent sessions allowed across channels, but not on the same channel). ### Review and Test -Alternative channels should be mentioned in the testing report, even if they are marked as "information only" or "out of scope". In some cases the test scope might include the alternative channel (e.g. because it is just another path on the target host name), or may be added to the scope after discussion with the owners of all the channels. If testing is permitted and authorized, all the other authentication tests in this guide should then be performed, and compared against the primary channel. +Alternative channels should be mentioned in the testing report, even if they are marked as "information only" or "out of scope". In some cases the test scope might include the alternative channel (e.g. because it is just another path on the target hostname), or may be added to the scope after discussion with the owners of all the channels. If testing is permitted and authorized, all the other authentication tests in this guide should then be performed, and compared against the primary channel. ## Related Test Cases diff --git a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/11-Testing_Multi-Factor_Authentication.md b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/10-Testing_Multi-Factor_Authentication.md similarity index 97% rename from document/4-Web_Application_Security_Testing/04-Authentication_Testing/11-Testing_Multi-Factor_Authentication.md rename to document/4-Web_Application_Security_Testing/04-Authentication_Testing/10-Testing_Multi-Factor_Authentication.md index 2dba9c6cd6..91f33d174c 100644 --- a/document/4-Web_Application_Security_Testing/04-Authentication_Testing/11-Testing_Multi-Factor_Authentication.md +++ b/document/4-Web_Application_Security_Testing/04-Authentication_Testing/10-Testing_Multi-Factor_Authentication.md @@ -2,11 +2,11 @@ |ID | |------------| -|WSTG-ATHN-11| +|WSTG-ATHN-10| ## Summary -Many applications implement Multi-Factor Authentication (MFA) as an additional layer of security to protect the login process. This is also known as two-factor authentication (2FA) or two-step verification (2SV) - although these are not strictly the same thing. MFA means asking the user to provide *at least* two different [authentication factors](#types-of-mfa) when logging in. +Many applications implement Multi-Factor Authentication (MFA) as an additional layer of security to protect the login process. This is also known as two-factor authentication (2FA) or two-step verification (2SV) - although these are not strictly the same thing. MFA means asking the user to provide *at least* two different [authentication factors](#types-of-mfa) when logging in. MFA adds additional complexity to both the authentication functionality, and also to other security-related areas (such as credential management and password recovery), meaning that it is critical for it to be implemented in a correct and robust manner. @@ -56,7 +56,7 @@ In some cases, there may also be intentional MFA bypasses implemented, such as n - From specific IP addresses (which may be spoofable using the `X-Forwarded-For` HTTP header). - When a specific HTTP header is set (such as a non-standard header like `X-Debug`). -- For a specific hard-coded account (such as a "root" or "breakglass" account). +- For a specific hardcoded account (such as a "root" or "breakglass" account). Where an application supports both local and federated logins, it may be possible to bypass the MFA if there is no strong separation between these two types of accounts. For example, if a user registers a local account and configures MFA for it, but does not have MFA configured on their account on the federated login provider, it may be possible for an attacker to re-register (or link) a federated account on the target application with the same email address by compromising the user's account on the federated login provider. @@ -88,11 +88,11 @@ See the ["Backup Codes" section in the Forgotten Password Cheat Sheet](https://c #### MFA Reset Process -If the application implements an MFA reset process, this should be tested in the same way that the [password reset process](09-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md) is tested. It is important that this process is *at least* as strong as the MFA implementation for the application. +If the application implements an MFA reset process, this should be tested in the same way that the [password reset process](08-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md) is tested. It is important that this process is *at least* as strong as the MFA implementation for the application. #### Alternative Authentication -Some applications will allow the user to prove their identity through other means, such as the use of [security questions](08-Testing_for_Weak_Security_Question_Answer.md). This usually represents a significant weakness, as security questions provide a far lower level of security than MFA. +Some applications will allow the user to prove their identity through other means, such as the use of [security questions](07-Testing_for_Weak_Security_Question_Answer.md). This usually represents a significant weakness, as security questions provide a far lower level of security than MFA. ### One-Time Passwords @@ -111,7 +111,7 @@ The OTP is typically entered after the user has provided their username and pass - Is the account locked out after multiple failed MFA attempts? - Is the user's IP address blocked after multiple failed MFA attempts across different accounts? - Are failed MFA attempts logged? -- Is the form vulnerable to injection attacks, including [SQL wildcard injection](../07-Input_Validation_Testing/05-Testing_for_SQL_Injection.md#sql-wildcard-injection)? +- Is the form vulnerable to injection attacks, including [SQL wildcard injection](../07-Input_Validation_Testing/03-Testing_for_SQL_Injection.md#sql-wildcard-injection)? Depending on the type of OTPs used, there are also some other specific checks that should be performed: @@ -196,8 +196,8 @@ If a valid certificate can be obtained, then it should also be verified that the ## Related Test Cases -- [Testing for Weak Lock Out Mechanism](03-Testing_for_Weak_Lock_Out_Mechanism.md) -- [Testing for Weak Password Change or Reset Functionalities](09-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md) +- [Testing for Weak Lock Out Mechanism](02-Testing_for_Weak_Lock_Out_Mechanism.md) +- [Testing for Weak Password Change or Reset Functionalities](08-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md) ## Remediation diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_HTTP_Verb_Tampering.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_HTTP_Verb_Tampering.md similarity index 93% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_HTTP_Verb_Tampering.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_HTTP_Verb_Tampering.md index 5c47fbcbc4..6b919f4940 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_HTTP_Verb_Tampering.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_HTTP_Verb_Tampering.md @@ -2,6 +2,6 @@ |ID | |------------| -|WSTG-INPV-03| +|WSTG-INPV-01| This content has been merged into: [Test HTTP Methods](../02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods.md) diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_HTTP_Parameter_Pollution.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_HTTP_Parameter_Pollution.md index bcbe3cc371..54aa95cb20 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_HTTP_Parameter_Pollution.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-04| +|WSTG-INPV-02| ## Summary diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_SQL_Injection.md similarity index 97% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_SQL_Injection.md index d92166c1bc..d4223e0303 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_SQL_Injection.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-05| +|WSTG-INPV-03| ## Summary @@ -179,7 +179,7 @@ When the testers move to a more advanced SQL injection exploitation they need to The first way to find out what backend database is used is by observing the error returned by the application. The following are some examples of error messages: -MySql: +MySQL: ```html You have an error in your SQL syntax; check the manual @@ -213,7 +213,7 @@ Query failed: ERROR: syntax error at or near If there is no error message or a custom error message, the tester can try to inject it into string fields using varying concatenation techniques: -- MySql: ‘test’ + ‘ing’ +- MySQL: ‘test’ + ‘ing’ - SQL Server: ‘test’ ‘ing’ - Oracle: ‘test’||’ing’ - PostgreSQL: ‘test’||’ing’ @@ -599,11 +599,11 @@ Consider also the request to a script that executes the query above: `https://www.example.com/product.php?id=10` -The malicious request would be (e.g. MySql 5.x): +The malicious request would be (e.g. MySQL 5.x): `https://www.example.com/product.php?id=10 AND IF(version() like ‘5%’, sleep(10), ‘false’))--` -In this example the tester is checking whether the MySql version is 5.x or not, making the server to delay the answer by 10 seconds. The tester can increase the delay time and monitor the responses. The tester also doesn’t need to wait for the response. Sometimes he can set a very high value (e.g. 100) and cancel the request after some seconds. +In this example the tester is checking whether the MySQL version is 5.x or not, making the server to delay the answer by 10 seconds. The tester can increase the delay time and monitor the responses. The tester also doesn’t need to wait for the response. Sometimes he can set a very high value (e.g. 100) and cancel the request after some seconds. #### Stored Procedure Injection @@ -786,16 +786,16 @@ This technique could also be used to determine exact discount codes through incr ## Remediation -- To secure the application from SQL injection vulnerabilities, refer to the [SQL Injection Prevention CheatSheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html). -- To secure the SQL server, refer to the [Database Security CheatSheet](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html). +- To secure the application from SQL injection vulnerabilities, refer to the [SQL Injection Prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html). +- To secure the SQL server, refer to the [Database Security cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html). -For generic input validation security, refer to the [Input Validation CheatSheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html). +For generic input validation security, refer to the [Input Validation cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html). ## Tools - [SQL Injection Fuzz Strings (from wfuzz tool) - Fuzzdb](https://github.com/fuzzdb-project/fuzzdb/tree/master/attack/sql-injection) - [Bernardo Damele A. G.: sqlmap, automatic SQL injection tool](https://sqlmap.org/) -- [Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool](https://github.com/dtrip/mysqloit) +- [Muhaimin Dzulfakar: MySQLoit, MySQL Injection takeover tool](https://github.com/dtrip/mysqloit) - [SQL Injection - PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection) ## References @@ -806,14 +806,14 @@ For generic input validation security, refer to the [Input Validation CheatSheet Technology-specific Testing Guide pages have been created for the following DBMSs: -- [Oracle](05.1-Testing_for_Oracle.md) -- [MySQL](05.2-Testing_for_MySQL.md) -- [SQL Server](05.3-Testing_for_SQL_Server.md) -- [PostgreSQL](05.4-Testing_PostgreSQL.md) -- [MS Access](05.5-Testing_for_MS_Access.md) -- [NoSQL](05.6-Testing_for_NoSQL_Injection.md) -- [ORM](05.7-Testing_for_ORM_Injection.md) -- [Client-side](05.8-Testing_for_Client-side.md) +- [Oracle](03.1-Testing_for_Oracle.md) +- [MySQL](03.2-Testing_for_MySQL.md) +- [SQL Server](03.3-Testing_for_SQL_Server.md) +- [PostgreSQL](03.4-Testing_PostgreSQL.md) +- [MS Access](03.5-Testing_for_MS_Access.md) +- [NoSQL](03.6-Testing_for_NoSQL_Injection.md) +- [ORM](03.7-Testing_for_ORM_Injection.md) +- [Client-side](03.8-Testing_for_Client-side.md) ### Whitepapers diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.1-Testing_for_Oracle.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.1-Testing_for_Oracle.md similarity index 98% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.1-Testing_for_Oracle.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.1-Testing_for_Oracle.md index f97995f1f1..516937ebbb 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.1-Testing_for_Oracle.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.1-Testing_for_Oracle.md @@ -106,7 +106,7 @@ On older versions of the PL/SQL Gateway, it is possible to directly access the p `https://www.example.com/pls/dad/owa_util.signature` -returns the following output on the webpage +returns the following output on the web page `"This page was produced by the PL/SQL Web Toolkit on date"` @@ -334,10 +334,6 @@ returns an error or a `404`, then there might be a SQL injection flaw. This can If this request returns books by Charles Dickens, you've confirmed the presence of the SQL injection vulnerability. -## Tools - -- [Orascan (Oracle Web Application VA scanner), NGS SQuirreL (Oracle RDBMS VA Scanner)](https://www.nccgroup.trust/globalassets/service-pages/documents/security-consulting/information-security-software/ncc-squirrel-suite.pdf) - ## References ### Whitepapers diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.2-Testing_for_MySQL.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.2-Testing_for_MySQL.md similarity index 97% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.2-Testing_for_MySQL.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.2-Testing_for_MySQL.md index eb2c472ec6..fa4ab32c14 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.2-Testing_for_MySQL.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.2-Testing_for_MySQL.md @@ -19,7 +19,7 @@ MySQL comes with at least four versions which are used in production worldwide, It should be noted that for MySQL versions before 4.0.x, only Boolean or time-based Blind Injection attacks could be used, since the subquery functionality or `UNION` statements were not implemented. -From now on, we will assume that there is a classic SQL injection vulnerability, which can be triggered by a request similar to the one described in the Section on [Testing for SQL Injection](05-Testing_for_SQL_Injection.md). +From now on, we will assume that there is a classic SQL injection vulnerability, which can be triggered by a request similar to the one described in the Section on [Testing for SQL Injection](03-Testing_for_SQL_Injection.md). `https://www.example.com/page.php?id=2` @@ -212,7 +212,7 @@ For a complete list, refer to the [MySQL manual](https://dev.mysql.com/doc/refma ## Tools - [Bernardo Damele A. G.: sqlmap, automatic SQL injection tool](https://sqlmap.org/) -- [Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool](https://code.google.com/archive/p/mysqloit/) +- [Muhaimin Dzulfakar: MySqloit, MySQL Injection takeover tool](https://code.google.com/archive/p/mysqloit/) ## References @@ -222,4 +222,4 @@ For a complete list, refer to the [MySQL manual](https://dev.mysql.com/doc/refma ### Case Studies -- [Zeelock: Blind Injection in MySQL Databases](https://archive.cert.uni-stuttgart.de/bugtraq/2005/02/msg00289.html) +- [All Your Databases Belong To Me! A Blind SQLi Case Study](https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/all-your-databases-belong-to-me-a-blind-sqli-case-study) diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.3-Testing_for_SQL_Server.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.3-Testing_for_SQL_Server.md similarity index 100% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.3-Testing_for_SQL_Server.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.3-Testing_for_SQL_Server.md diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.4-Testing_PostgreSQL.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.4-Testing_PostgreSQL.md similarity index 100% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.4-Testing_PostgreSQL.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.4-Testing_PostgreSQL.md diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.5-Testing_for_MS_Access.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.5-Testing_for_MS_Access.md similarity index 100% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.5-Testing_for_MS_Access.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.5-Testing_for_MS_Access.md diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.6-Testing_for_NoSQL_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.6-Testing_for_NoSQL_Injection.md similarity index 97% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.6-Testing_for_NoSQL_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.6-Testing_for_NoSQL_Injection.md index b8ba4865c2..5760785487 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.6-Testing_for_NoSQL_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.6-Testing_for_NoSQL_Injection.md @@ -71,5 +71,5 @@ One way to potentially assign data to PHP variables is via HTTP Parameter Pollut - [Felipe Aragon from Syhunt: "NoSQL/SSJS Injection"](hhttps://www.syhunt.com/en/?n=Articles.NoSQLInjection) - [MongoDB Documentation: "How does MongoDB address SQL or Query injection?"](https://docs.mongodb.org/manual/faq/developers/#how-does-mongodb-address-sql-or-query-injection) - [PHP Documentation: "MongoDB Driver Classes"](https://www.php.net/manual/en/book.mongodb.php) -- [Hacking NodeJS and MongoDB](https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html) -- [Attacking NodeJS and MongoDB](https://blog.websecurify.com/2014/08/attacks-nodejs-and-mongodb-part-to.html) +- [Hacking Node.js and MongoDB](https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html) +- [Attacking Node.js and MongoDB](https://blog.websecurify.com/2014/08/attacks-nodejs-and-mongodb-part-to.html) diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.7-Testing_for_ORM_Injection.md similarity index 100% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.7-Testing_for_ORM_Injection.md diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.8-Testing_for_Client-side.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.8-Testing_for_Client-side.md similarity index 100% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.8-Testing_for_Client-side.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03.8-Testing_for_Client-side.md diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/06-Testing_for_LDAP_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_LDAP_Injection.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/06-Testing_for_LDAP_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_LDAP_Injection.md index f870e08b7b..ce2719f468 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/06-Testing_for_LDAP_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_LDAP_Injection.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-06| +|WSTG-INPV-04| ## Summary diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XML_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_XML_Injection.md similarity index 98% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XML_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_XML_Injection.md index 3c5877a7b4..1d4f08b9b9 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XML_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_XML_Injection.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-07| +|WSTG-INPV-05| ## Summary @@ -256,7 +256,7 @@ To test for XXE vulnerabilities, one can use the following input: &xxe; ``` -This test could crash the web server (on a UNIX system), if the XML parser attempts to substitute the entity with the contents of the /dev/random file. +This test could crash the web server (on a Unix system), if the XML parser attempts to substitute the entity with the contents of the /dev/random file. Other useful tests are the following: @@ -422,5 +422,5 @@ The followings source code keyword may apply to C. ## References - [XML Injection](https://www.whitehatsec.com/glossary/content/xml-injection) -- [Gregory Steuck, "XXE (Xml eXternal Entity) attack"](https://www.securityfocus.com/archive/1/297714) +- [Gregory Steuck, "XXE (XML eXternal Entity) attack"](https://www.securityfocus.com/archive/1/297714) - [OWASP XXE Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/08-Testing_for_SSI_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/06-Testing_for_SSI_Injection.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/08-Testing_for_SSI_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/06-Testing_for_SSI_Injection.md index 58a85fdc09..66cf55a1ef 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/08-Testing_for_SSI_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/06-Testing_for_SSI_Injection.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-08| +|WSTG-INPV-06| ## Summary diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09-Testing_for_XPath_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XPath_Injection.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09-Testing_for_XPath_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XPath_Injection.md index 9bb7c05f2b..f42ef18d38 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09-Testing_for_XPath_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XPath_Injection.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-09| +|WSTG-INPV-07| ## Summary diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/10-Testing_for_IMAP_SMTP_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/08-Testing_for_IMAP_SMTP_Injection.md similarity index 95% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/10-Testing_for_IMAP_SMTP_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/08-Testing_for_IMAP_SMTP_Injection.md index 539ee71801..423c0bb335 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/10-Testing_for_IMAP_SMTP_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/08-Testing_for_IMAP_SMTP_Injection.md @@ -2,20 +2,20 @@ |ID | |------------| -|WSTG-INPV-10| +|WSTG-INPV-08| ## Summary This threat affects all applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not being properly sanitized. -The IMAP/SMTP Injection technique is more effective if the mail server is not directly accessible from Internet. Where full communication with the backend mail server is possible, it is recommended to conduct direct testing. +The IMAP/SMTP Injection technique is more effective if the mail server is not directly accessible from internet. Where full communication with the backend mail server is possible, it is recommended to conduct direct testing. -An IMAP/SMTP Injection makes it possible to access a mail server which otherwise would not be directly accessible from the Internet. In some cases, these internal systems do not have the same level of infrastructure security and hardening that is applied to the front-end web servers. Therefore, mail server results may be more vulnerable to attacks by end users (see the scheme presented in Figure 1). +An IMAP/SMTP Injection makes it possible to access a mail server which otherwise would not be directly accessible from the internet. In some cases, these internal systems do not have the same level of infrastructure security and hardening that is applied to the frontend web servers. Therefore, mail server results may be more vulnerable to attacks by end users (see the scheme presented in Figure 1). ![IMAP SMTP Injection](images/Imap-smtp-injection.png)\ *Figure 4.7.10-1: Communication with the mail servers using the IMAP/SMTP Injection technique* -Figure 1 depicts the flow of traffic generally seen when using webmail technologies. Step 1 and 2 is the user interacting with the webmail client, whereas step 2 is the tester bypassing the webmail client and interacting with the back-end mail servers directly. +Figure 1 depicts the flow of traffic generally seen when using webmail technologies. Step 1 and 2 is the user interacting with the webmail client, whereas step 2 is the tester bypassing the webmail client and interacting with the backend mail servers directly. This technique allows a wide variety of actions and attacks. The possibilities depend on the type and scope of injection and the mail server technology being tested. @@ -37,7 +37,7 @@ Some examples of attacks using the IMAP/SMTP Injection technique are: ### Identifying Vulnerable Parameters -In order to detect vulnerable parameters, the tester has to analyze the application's ability in handling input. Input validation testing requires the tester to send bogus, or malicious, requests to the server and analyse the response. In a secure application, the response should be an error with some corresponding action telling the client that something has gone wrong. In a vulnerable application, the malicious request may be processed by the back-end application that will answer with a `HTTP 200 OK` response message. +In order to detect vulnerable parameters, the tester has to analyze the application's ability in handling input. Input validation testing requires the tester to send bogus, or malicious, requests to the server and analyse the response. In a secure application, the response should be an error with some corresponding action telling the client that something has gone wrong. In a vulnerable application, the malicious request may be processed by the backend application that will answer with a `HTTP 200 OK` response message. It is important to note that the requests being sent should match the technology being tested. Sending SQL injection strings for Microsoft SQL server when a MySQL server is being used will result in false positive responses. In this case, sending malicious IMAP commands is modus operandi since IMAP is the underlying protocol being tested. diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11-Testing_for_Code_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09-Testing_for_Code_Injection.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11-Testing_for_Code_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09-Testing_for_Code_Injection.md index af36e81a16..0f383cbe33 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11-Testing_for_Code_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09-Testing_for_Code_Injection.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-11| +|WSTG-INPV-09| ## Summary diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09.1-Testing_for_File_Inclusion.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09.1-Testing_for_File_Inclusion.md index 0a2b37387c..40d6d3c08a 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09.1-Testing_for_File_Inclusion.md @@ -91,7 +91,7 @@ In order to test this vulnerability, the following procedure could be followed t 1. Create the PHP file to be executed, for example with the content `` and save it as `code.php`. 2. Compress it as a new ZIP file called `target.zip`. -3. Rename the `target.zip` file to `target.jpg` to bypass the extension validation and upload it to the target website as your avatar image. +3. Rename the `target.zip` file to `target.jpg` to bypass the extension validation and upload it to the target site as your avatar image. 4. Supposing that the `target.jpg` file is stored locally on the server to the `../avatar/target.jpg` path, exploit the vulnerability with the PHP ZIP wrapper by injecting the following payload to the vulnerable URL: `zip://../avatar/target.jpg%23code` (remember that `%23` corresponds to `#`). Since on our sample the `.php` extension is concatenated to our payload, the request to `https://vulnerable_host/preview.php?file=zip://../avatar/target.jpg%23code` will result in the execution of the `code.php` file existing in the malicious ZIP file. diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/10-Testing_for_Command_Injection.md similarity index 98% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/10-Testing_for_Command_Injection.md index e9c5f472b1..88c8779693 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/10-Testing_for_Command_Injection.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-12| +|WSTG-INPV-10| ## Summary @@ -36,7 +36,7 @@ Example: ### Example -Consider the case of an application that contains a set of documents that you can browse from the Internet. If you fire up a personal proxy (such as ZAP or Burp Suite), you can obtain a POST HTTP like the following (`https://www.example.com/public/doc`): +Consider the case of an application that contains a set of documents that you can browse from the internet. If you fire up a personal proxy (such as ZAP or Burp Suite), you can obtain a POST HTTP like the following (`https://www.example.com/public/doc`): ```txt POST /public/doc HTTP/1.1 diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/13-Testing_for_Buffer_Overflow.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11-Testing_for_Buffer_Overflow.md similarity index 85% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/13-Testing_for_Buffer_Overflow.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11-Testing_for_Buffer_Overflow.md index 9c1ba53a6a..c836db469a 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/13-Testing_for_Buffer_Overflow.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11-Testing_for_Buffer_Overflow.md @@ -2,6 +2,6 @@ |ID | |------------| -|WSTG-INPV-13| +|WSTG-INPV-11| This content has been removed diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/13-Testing_for_Format_String_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Format_String_Injection.md similarity index 97% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/13-Testing_for_Format_String_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Format_String_Injection.md index 94ffcd128d..6a00031c2c 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/13-Testing_for_Format_String_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Format_String_Injection.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-13| +|WSTG-INPV-12| ## Summary @@ -15,7 +15,7 @@ The worst case for format strings vulnerabilities occur in languages that don't These format string functions cannot write to memory, but attackers can still cause information disclosure by changing format strings to output values the developers did not intend to send: -- Python 2.6 and 2.7 [str.format](https://docs.python.org/2/library/string.html) and Python 3 unicode [str.format](https://docs.python.org/3/library/stdtypes.html#str.format) can be modified by injecting strings that can point to [other variables](https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/) in memory +- Python 2.6 and 2.7 [str.format](https://docs.python.org/2/library/string.html) and Python 3 Unicode [str.format](https://docs.python.org/3/library/stdtypes.html#str.format) can be modified by injecting strings that can point to [other variables](https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/) in memory The following format string functions can cause runtime errors if the attacker adds conversion specifiers: @@ -82,7 +82,7 @@ Testers can perform a manual test using a web browser or other web API debugging `https://vulnerable_host/userinfo?username=%25s%25s%25s%25n` -If the web site is vulnerable, the browser or tool should receive an error, which may include a timeout or an HTTP return code 500. +If the site is vulnerable, the browser or tool should receive an error, which may include a timeout or an HTTP return code 500. The Java code returns the error diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/14-Testing_for_Incubated_Vulnerability.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/13-Testing_for_Incubated_Vulnerability.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/14-Testing_for_Incubated_Vulnerability.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/13-Testing_for_Incubated_Vulnerability.md index e982f3b0c9..d868f9340a 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/14-Testing_for_Incubated_Vulnerability.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/13-Testing_for_Incubated_Vulnerability.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-14| +|WSTG-INPV-13| ## Summary diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/15-Testing_for_HTTP_Splitting_Smuggling.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/14-Testing_for_HTTP_Splitting_Smuggling.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/15-Testing_for_HTTP_Splitting_Smuggling.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/14-Testing_for_HTTP_Splitting_Smuggling.md index da1f4fb5da..54a04bdc2d 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/15-Testing_for_HTTP_Splitting_Smuggling.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/14-Testing_for_HTTP_Splitting_Smuggling.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-15| +|WSTG-INPV-14| ## Summary @@ -60,7 +60,7 @@ Content-Length: 35 ``` -The web cache will see two different responses, so if the attacker sends, immediately after the first request, a second one asking for `/index.html`, the web cache will match this request with the second response and cache its content, so that all subsequent requests directed to `victim.com/index.html` passing through that web cache will receive the "system down" message. In this way, an attacker would be able to effectively deface the site for all users using that web cache (the whole Internet, if the web cache is a reverse proxy for the web application). +The web cache will see two different responses, so if the attacker sends, immediately after the first request, a second one asking for `/index.html`, the web cache will match this request with the second response and cache its content, so that all subsequent requests directed to `victim.com/index.html` passing through that web cache will receive the "system down" message. In this way, an attacker would be able to effectively deface the site for all users using that web cache (the whole internet, if the web cache is a reverse proxy for the web application). Alternatively, the attacker could pass to those users a JavaScript snippet that mounts a cross site scripting attack, e.g., to steal the cookies. Note that while the vulnerability is in the application, the target here is its users. Therefore, in order to look for this vulnerability, the tester needs to identify all user controlled input that influences one or more headers in the response, and check whether they can successfully inject a CR+LF sequence in it. diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/16-Testing_for_HTTP_Incoming_Requests.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/15-Testing_for_HTTP_Incoming_Requests.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/16-Testing_for_HTTP_Incoming_Requests.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/15-Testing_for_HTTP_Incoming_Requests.md index 946fba06b6..da68a97991 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/16-Testing_for_HTTP_Incoming_Requests.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/15-Testing_for_HTTP_Incoming_Requests.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-16| +|WSTG-INPV-15| ## Summary diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/16-Testing_for_Host_Header_Injection.md similarity index 91% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/16-Testing_for_Host_Header_Injection.md index 534ed0f375..80a9d8e693 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/16-Testing_for_Host_Header_Injection.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-17| +|WSTG-INPV-16| ## Summary @@ -116,7 +116,7 @@ https://www.attacker.com/reset.php?token=12345 In some cases a server may have virtual hosts that are not intended to be externally accessible. This is most common with a [split-horizon](https://en.wikipedia.org/wiki/Split-horizon_DNS) DNS setup (where internal and external DNS servers return different records for the same domain). -For example, an organization may have a single webserver on their internal network, which hosts both their public website (on `www.example.org`) and their internal Intranet (on `intranet.example.org`, but that record only exists on the internal DNS server). Although it would not be possible to browse directly to `intranet.example.org` from outside the network (as the domain would not resolve), it may be possible to access to Intranet by making a request from outside with the following `Host` header: +For example, an organization may have a single webserver on their internal network, which hosts both their public site (on `www.example.org`) and their internal Intranet (on `intranet.example.org`, but that record only exists on the internal DNS server). Although it would not be possible to browse directly to `intranet.example.org` from outside the network (as the domain would not resolve), it may be possible to access to Intranet by making a request from outside with the following `Host` header: ```http Host: intranet.example.org diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-side_Template_Injection.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Server-side_Template_Injection.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-side_Template_Injection.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Server-side_Template_Injection.md index b9a9d592e1..9d7391c2e3 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-side_Template_Injection.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Server-side_Template_Injection.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-18| +|WSTG-INPV-17| ## Summary diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/19-Testing_for_Server-Side_Request_Forgery.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-Side_Request_Forgery.md similarity index 87% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/19-Testing_for_Server-Side_Request_Forgery.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-Side_Request_Forgery.md index f1b57d958e..2f1d9ae649 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/19-Testing_for_Server-Side_Request_Forgery.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-Side_Request_Forgery.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-19| +|WSTG-INPV-18| ## Summary @@ -16,7 +16,7 @@ Web applications often interact with internal or external resources. While you m ## How to Test -When testing for SSRF, you attempt to make the targeted server inadvertently load or save content that could be malicious. The most common test is for local and remote file inclusion. There is also another facet to SSRF: a trust relationship that often arises where the application server is able to interact with other back-end systems that are not directly reachable by users. These back-end systems often have non-routable private IP addresses or are restricted to certain hosts. Since they are protected by the network topology, they often lack more sophisticated controls. These internal systems often contain sensitive data or functionality. +When testing for SSRF, you attempt to make the targeted server inadvertently load or save content that could be malicious. The most common test is for local and remote file inclusion. There is also another facet to SSRF: a trust relationship that often arises where the application server is able to interact with other backend systems that are not directly reachable by users. These backend systems often have non-routable private IP addresses or are restricted to certain hosts. Since they are protected by the network topology, they often lack more sophisticated controls. These internal systems often contain sensitive data or functionality. Consider the following request: @@ -94,14 +94,14 @@ For additional payloads and bypass techniques, see the [references](#references) ## Remediation -SSRF is known to be one of the hardest attacks to defeat without the use of allow lists that require specific IPs and URLs to be allowed. For more on SSRF prevention, read the [Server Side Request Forgery Prevention Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html). +SSRF is known to be one of the hardest attacks to defeat without the use of allow lists that require specific IPs and URLs to be allowed. For more on SSRF prevention, read the [Server-side Request Forgery Prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html). ## References - [swisskyrepo: SSRF Payloads](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery) - [Reading Internal Files Using SSRF Vulnerability](https://medium.com/@neerajedwards/reading-internal-files-using-ssrf-vulnerability-703c5706eefb) - [Abusing the AWS Metadata Service Using SSRF Vulnerabilities](https://blog.christophetd.fr/abusing-aws-metadata-service-using-ssrf-vulnerabilities/) -- [OWASP Server Side Request Forgery Prevention Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) +- [OWASP Server-side Request Forgery Prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) - [Portswigger: SSRF](https://portswigger.net/web-security/ssrf) - [Portswigger: Blind SSRF](https://portswigger.net/web-security/ssrf/blind) - [Bugcrowd Webinar: SSRF](https://www.bugcrowd.com/resources/webinars/server-side-request-forgery/) diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/20-Testing_for_Mass_Assignment.md b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/19-Testing_for_Mass_Assignment.md similarity index 98% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/20-Testing_for_Mass_Assignment.md rename to document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/19-Testing_for_Mass_Assignment.md index 1f7e2cc84d..c5debcc59b 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/20-Testing_for_Mass_Assignment.md +++ b/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/19-Testing_for_Mass_Assignment.md @@ -2,7 +2,7 @@ |ID | |------------| -|WSTG-INPV-20| +|WSTG-INPV-19| ## Summary @@ -81,7 +81,7 @@ The user is then created with the `isAdmin` property set to `true`, giving them #### Detect Handlers -In order to determine which part of the application is vulnerable to mass assignment, enumerate all parts of the application that accept content from the user and can potentially be mapped with a model. This includes all HTTP requests (most likely GET, POST, and PUT) that appear to allow create or update operations on the back end. +In order to determine which part of the application is vulnerable to mass assignment, enumerate all parts of the application that accept content from the user and can potentially be mapped with a model. This includes all HTTP requests (most likely GET, POST, and PUT) that appear to allow create or update operations on the backend. One of the most simple indicators for potential mass assignments is the presence of bracket syntax for input parameter names, as for example: ```html @@ -94,7 +94,7 @@ If the application does not implement any control (e.g. list of allowed fields) #### Identify Sensitive Fields Since in black-box testing the tester does not have visibility on the source code, it is necessary to find other ways in order to gather information about the attributes associated to the objects. -Analyze the responses received by the back end, in particular pay attention to: +Analyze the responses received by the backend, in particular pay attention to: - HTML page source code - Custom JavaScript code diff --git a/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01-Testing_for_Cross_Site_Scripting.md b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01-Testing_for_Cross_Site_Scripting.md new file mode 100644 index 0000000000..8dcff56c9d --- /dev/null +++ b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01-Testing_for_Cross_Site_Scripting.md @@ -0,0 +1,113 @@ +# Testing for Cross Site Scripting + +|ID | +|------------| +|WSTG-CLNT-01| + +## Summary + +Cross-Site Scripting (XSS) testing checks if it is possible to inject malicious scripts into a web application, which are then executed by users' browsers. XSS vulnerabilities occur when user-supplied input is not properly validated or sanitized before being included in the application's output. Successful exploitation of an XSS vulnerability allows attackers to execute arbitrary JavaScript code within the context of a victim's browser, leading to various attacks such as session hijacking, defacement, or stealing sensitive information. + +XSS attacks can be classified into the following three types: + +Stored XSS: The malicious script is permanently stored on the target server and is served to users when they access a particular page or view specific content. + +Reflected XSS: The malicious script is embedded in a URL and is reflected back to the user by the web application, typically as part of an error message or search result. + +DOM-based XSS: The vulnerability arises from insecure handling of client-side JavaScript in the Document Object Model (DOM) of a web page. The malicious script is directly executed by the victim's browser. + +An XSS attack occurs when an attacker can inject untrusted data into a web application, which is then included in a response that is sent to other users. This untrusted data can be included in various contexts within an HTML document, including: + +HTML tags: If user-supplied input is inserted without proper encoding into HTML tags, it can lead to script execution. For example: + +```js + +``` + +HTML attributes: If user-supplied input is included in HTML attributes without proper encoding, it can be exploited to execute scripts. For example: + +```js + +``` + +JavaScript code: If user-supplied input is directly inserted into JavaScript code without proper escaping or validation, it can lead to script execution. For example: + +```js +var userInput = '<%= userInput %>'; +``` + +URLs: If user-supplied input is included in URLs without proper encoding, it can result in script execution. For example: + +```js +https://example.com/search?q= +``` + +XSS vulnerabilities can have severe consequences, ranging from stealing sensitive user information to performing actions on behalf of the user, such as modifying account settings or making unauthorized transactions. + +## Test Objectives + +Identify input fields or parameters vulnerable to XSS attacks. +Assess the impact and severity of XSS vulnerabilities. +Validate the effectiveness of input validation and output encoding mechanisms in preventing XSS attacks. + +## How to Test + +### Detection Techniques + +The first step in XSS testing is to identify all user-supplied input fields or parameters within the web application. This includes input fields in web forms, query string parameters in URLs, hidden form fields, cookies, headers, and any other input sources that are used to generate dynamic content. + +Once the input fields or parameters are identified, the following techniques can be employed to detect XSS vulnerabilities: + +HTML Injection: Inject HTML tags and check if they are rendered as part of the web page. For example: + +```js + +``` + +If the injected HTML tags are not properly sanitized, they will be interpreted and executed by the browser. + +Attribute Injection: Inject special characters or event handlers into HTML attributes and check if they are executed. For example: + +```js +"> +``` + +If the injected content is rendered without proper encoding, the browser will interpret it as part of the attribute value, leading to script execution. + +JavaScript Injection: Inject JavaScript code into areas of the application where it is expected to be executed. This includes JavaScript code within ` +``` + +If the injected script is not properly encoded, it will be interpreted as part of the URL and executed by the browser. + +Context-Specific Injection: Test for XSS vulnerabilities in specific contexts such as input fields used in search functionality, comment sections, messaging systems, or any other areas where user-supplied input is displayed to other users. + +During testing, it is important to observe the behavior of the application and analyze the responses received. Look for any unexpected execution of scripts or the presence of injected content within the rendered HTML source code. Additionally, monitor the network traffic to identify any requests or responses that contain suspicious or unexpected content. + +It is recommended to test various browsers to ensure cross-browser compatibility of the identified XSS vulnerabilities. + +## Remediation + +To mitigate XSS vulnerabilities, the following best practices should be implemented: + +Input Validation: Perform strict input validation on all user-supplied input. Accept only the expected characters and reject or sanitize any input that contains special characters or script-like content. + +Output Encoding: Encode all user-supplied input that is rendered within HTML, JavaScript, or URL contexts. Use proper encoding mechanisms specific to the context, such as HTML entity encoding, JavaScript escaping, or URL encoding. + +Content Security Policy (CSP): Implement a strong CSP to restrict the execution of scripts from external sources and enforce a allow list(s) of trusted sources for content. + +HTTP Only Cookies: Set the "HttpOnly" flag for session cookies to prevent access from client-side scripts, reducing the risk of session theft via XSS. + +X-XSS-Protection Header: Enable the X-XSS-Protection header with the "1; mode=block" directive to instruct browsers to block or sanitize detected XSS attacks. + +Contextual Output Encoding: Apply output encoding based on the context in which the user-supplied input is rendered. Different encoding mechanisms may be required for HTML, JavaScript, or URL contexts. diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting.md b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.1-Testing_for_Reflected_Cross_Site_Scripting.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting.md rename to document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.1-Testing_for_Reflected_Cross_Site_Scripting.md index b7b1aa550f..da7e913457 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting.md +++ b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.1-Testing_for_Reflected_Cross_Site_Scripting.md @@ -1,9 +1,5 @@ # Testing for Reflected Cross Site Scripting -|ID | -|------------| -|WSTG-INPV-01| - ## Summary Reflected [Cross-site Scripting (XSS)](https://owasp.org/www-community/attacks/xss/) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim. @@ -62,7 +58,7 @@ Within the context of an HTML action or JavaScript code, a different set of spec - `'` (apostrophe or single quote) - `"` (double quote) - `\` (backslash) -- `\uXXXX` (unicode values) +- `\uXXXX` (Unicode values) For a more complete reference, see the [Mozilla JavaScript guide](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Values,_variables,_and_literals#Using_special_characters_in_strings). diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting.md b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.2-Testing_for_Stored_Cross_Site_Scripting.md similarity index 99% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting.md rename to document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.2-Testing_for_Stored_Cross_Site_Scripting.md index 8a3eeea5f1..c8c67e9d52 100644 --- a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting.md +++ b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.2-Testing_for_Stored_Cross_Site_Scripting.md @@ -1,9 +1,5 @@ # Testing for Stored Cross Site Scripting -|ID | -|------------| -|WSTG-INPV-02| - ## Summary Stored [Cross-site Scripting (XSS)](https://owasp.org/www-community/attacks/xss/) is the most dangerous type of Cross Site Scripting. Web applications that allow users to store data are potentially exposed to this type of attack. This chapter illustrates examples of stored cross site scripting injection and related exploitation scenarios. diff --git a/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01-Testing_for_DOM-based_Cross_Site_Scripting.md b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.3-Testing_for_DOM-based_Cross_Site_Scripting.md similarity index 90% rename from document/4-Web_Application_Security_Testing/11-Client-side_Testing/01-Testing_for_DOM-based_Cross_Site_Scripting.md rename to document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.3-Testing_for_DOM-based_Cross_Site_Scripting.md index ac36988f73..e01c74c666 100644 --- a/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01-Testing_for_DOM-based_Cross_Site_Scripting.md +++ b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.3-Testing_for_DOM-based_Cross_Site_Scripting.md @@ -1,9 +1,5 @@ # Testing for DOM-Based Cross Site Scripting -|ID | -|------------| -|WSTG-CLNT-01| - ## Summary [DOM-based cross-site scripting](https://owasp.org/www-community/attacks/DOM_Based_XSS) is the de-facto name for [XSS](https://owasp.org/www-community/attacks/xss/) bugs that are the result of active browser-side content on a page, typically JavaScript, obtaining user input through a [source](https://github.com/wisec/domxsswiki/wiki/sources) and using it in a [sink](https://github.com/wisec/domxsswiki/wiki/Sinks), leading to the execution of injected code. This document only discusses JavaScript bugs which lead to XSS. @@ -35,7 +31,7 @@ The [consequences](https://owasp.org/www-community/attacks/xss/) of DOM-based XS ## How to Test -JavaScript applications differ significantly from other types of applications because they are often dynamically generated by the server. To understand what code is being executed, the website being tested needs to be crawled to determine all the instances of JavaScript being executed and where user input is accepted. Many websites rely on large libraries of functions, which often stretch into the hundreds of thousands of lines of code and have not been developed in-house. In these cases, top-down testing often becomes the only viable option, since many bottom level functions are never used, and analyzing them to determine which are sinks will use up more time than is often available. The same can also be said for top-down testing if the inputs or lack thereof is not identified to begin with. +JavaScript applications differ significantly from other types of applications because they are often dynamically generated by the server. To understand what code is being executed, the site being tested needs to be crawled to determine all the instances of JavaScript being executed and where user input is accepted. Many sites rely on large libraries of functions, which often stretch into the hundreds of thousands of lines of code and have not been developed in-house. In these cases, top-down testing often becomes the only viable option, since many bottom level functions are never used, and analyzing them to determine which are sinks will use up more time than is often available. The same can also be said for top-down testing if the inputs or lack thereof is not identified to begin with. User input comes in two main forms: diff --git a/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.1-Testing_for_Self_DOM_Based_Cross_Site_Scripting.md b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.4-Testing_for_Self_DOM_Based_Cross_Site_Scripting.md similarity index 99% rename from document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.1-Testing_for_Self_DOM_Based_Cross_Site_Scripting.md rename to document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.4-Testing_for_Self_DOM_Based_Cross_Site_Scripting.md index bfeeb5b7bb..fbd45874f9 100644 --- a/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.1-Testing_for_Self_DOM_Based_Cross_Site_Scripting.md +++ b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/01.4-Testing_for_Self_DOM_Based_Cross_Site_Scripting.md @@ -19,7 +19,7 @@ The process of testing for Self DOM-Based cross site scripting follows: This specific example is from this [hackerone ticket](https://hackerone.com/reports/406587). -In the example the following JavaScript function is executed on the website `https://example.com`. +In the example the following JavaScript function is executed on the site `https://example.com`. ```js //Marketo Form Code diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/images/Alert.png b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/images/Alert.png similarity index 100% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/images/Alert.png rename to document/4-Web_Application_Security_Testing/11-Client-side_Testing/images/Alert.png diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/images/Stored_input_example.jpg b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/images/Stored_input_example.jpg similarity index 100% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/images/Stored_input_example.jpg rename to document/4-Web_Application_Security_Testing/11-Client-side_Testing/images/Stored_input_example.jpg diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/images/Stored_xss_example.jpg b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/images/Stored_xss_example.jpg similarity index 100% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/images/Stored_xss_example.jpg rename to document/4-Web_Application_Security_Testing/11-Client-side_Testing/images/Stored_xss_example.jpg diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/images/XSS_Example1.png b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/images/XSS_Example1.png similarity index 100% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/images/XSS_Example1.png rename to document/4-Web_Application_Security_Testing/11-Client-side_Testing/images/XSS_Example1.png diff --git a/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/images/XSS_Example2.png b/document/4-Web_Application_Security_Testing/11-Client-side_Testing/images/XSS_Example2.png similarity index 100% rename from document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/images/XSS_Example2.png rename to document/4-Web_Application_Security_Testing/11-Client-side_Testing/images/XSS_Example2.png