Publish Latest 2026-06-07

latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism.md

@@ -17,8 +17,9 @@ tags: WSTG
 
 Account lockout mechanisms are used to mitigate brute force attacks. Some of the attacks that can be defeated by using lockout mechanism:
 
-- Login password or username guessing attack.
-- Code guessing on any 2FA functionality or Security Questions.
+- Password guessing or brute-force attacks.
+- Security question guessing.
+- OTP code guessing for two-factor authentication (2FA/MFA).
 
 Account lockout mechanisms require a balance between protecting accounts from unauthorized access and protecting users from being denied authorized access. Accounts are typically locked after 3 to 5 unsuccessful attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator.
 
@@ -62,6 +63,7 @@ A CAPTCHA may hinder brute force attacks, but they can come with their own set o
 3. CAPTCHA server-side logic defaults to a successful solve.
 4. CAPTCHA challenge result is never validated server-side.
 5. CAPTCHA input field or parameter is manually processed, and is improperly validated or escaped.
+6. A single solved CAPTCHA can be re-used multiple times.
 
 To evaluate CAPTCHA effectiveness:
 
@@ -97,7 +99,7 @@ Factors to consider when implementing an account lockout mechanism:
 
 1. What is the risk of brute force password guessing against the application?
 2. Is a CAPTCHA sufficient to mitigate this risk?
-3. Is a client-side lockout mechanism being used (e.g., JavaScript)? (If so, disable the client-side code to test.)
+3. Is a client-side lockout mechanism being used (e.g., JavaScript)? (if so, disable the client-side code to test.)
 4. Number of unsuccessful log in attempts before lockout. If the lockout threshold is too low then valid users may be locked out too often. If the lockout threshold is too high then the more attempts an attacker can make to brute force the account before it will be locked. Depending on the application's purpose, a range of 5 to 10 unsuccessful attempts is a typical lockout threshold.
 5. How will accounts be unlocked?
     1. Manually by an administrator: this is the most secure lockout method, but may cause inconvenience to users and take up the administrator's "valuable" time.

latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.1-Testing_for_OAuth_Authorization_Server_Weaknesses.md

@@ -24,7 +24,7 @@ Failure to validate the parameters may lead to account takeover, unauthorized re
 In order to test for AS weaknesses, you will aim to:
 
 1. Retrieve credentials used for authorization.
-2. Grant yourself access to arbitrary resources through forceful browsing.
+2. Grant yourself access to arbitrary resources through forced browsing.
 3. Bypass the authorization.
 
 ### Testing for Insufficient Redirect URI Validation

latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.2-Testing_for_OAuth_Client_Weaknesses.md

@@ -24,7 +24,7 @@ Failure to protect the token exchange and credentials may result in unauthorized
 In order to test for client weaknesses, you will aim to:
 
 1. Retrieve credentials used for authorization.
-2. Grant yourself access to arbitrary resources through forceful browsing.
+2. Grant yourself access to arbitrary resources through forced browsing.
 3. Bypass the authorization.
 
 ### Testing for Exposed Client Secret

latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting.md

@@ -15,13 +15,13 @@ tags: WSTG
 
 ## 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.
+Reflected [Cross-site Scripting (XSS)](https://owasp.org/www-community/attacks/xss/) occurs 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.
 
 Reflected XSS are the most frequent type of XSS attacks found in the wild. Reflected XSS attacks are also known as non-persistent XSS attacks and, since the attack payload is delivered and executed via a single request and response, they are also referred to as first-order or type 1 XSS.
 
 When a web application is vulnerable to this type of attack, it will pass unvalidated input sent through requests back to the client. The common modus operandi of the attack includes a design step, in which the attacker creates and tests an offending URI, a social engineering step, in which she convinces her victims to load this URI on their browsers, and the eventual execution of the offending code using the victim's browser.
 
-Commonly the attacker's code is written in the JavaScript language, but other scripting languages are also used, e.g., ActionScript and VBScript. Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft, and change the content of the page (e.g., download links).
+Commonly the attacker's code is written in the JavaScript language, but other scripting languages such as ActionScript and VBScript can also be used. Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft, and change the content of the page (e.g., download links).
 
 One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding. In some cases, the web server or the web application could not be filtering some encodings of characters, so, for example, the web application might filter out `<script>`, but might not filter `%3cscript%3e` which simply includes another encoding of tags.
 
@@ -95,7 +95,7 @@ If no sanitization is applied this will result in the following popup:
 ![Alert](images/Alert.png)\
 *Figure 4.7.1-2: XSS Example 1*
 
-This indicates that there is an XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link.
+This indicates that there is an XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if the target clicks on the tester's link.
 
 #### Example 2
 
@@ -205,14 +205,13 @@ See the [XSS Filter Evasion Cheat Sheet](https://owasp.org/www-community/xss-fil
 
 ### Gray-Box Testing
 
-Gray-box testing is similar to black-box testing. In gray-box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and how the user input is rendered back to the user might be known by the pen-tester.
+Gray-box testing is similar to black-box testing. In gray-box testing, the pentester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and how the user input is rendered back to the user might be known by the pentester.
 
 If source code is available (white-box testing), all variables received from users should be analyzed. Moreover the tester should analyze any sanitization procedures implemented to decide if these can be circumvented.
 
 ## Tools
 
-- [PHP Charset Encoder(PCE)](https://cybersecurity.wtf/encoder/) helps you encode arbitrary texts to and from 65 kinds of character sets that you can use in your customized payloads.
-- [Hackvertor](https://hackvertor.co.uk/public) is an online tool which allows many types of encoding and obfuscation of JavaScript (or any string input).
+- [Hackvertor](https://hackvertor.co.uk/) is an online tool which allows many types of encoding and obfuscation of JavaScript (or any string input).
 - [XSS-Proxy](https://xss-proxy.sourceforge.net/) is an advanced Cross-Site-Scripting (XSS) attack tool.
 - [ratproxy](https://code.google.com/archive/p/ratproxy/) is a semi-automated, largely passive web application security audit tool, optimized for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments.
 - [Burp Proxy](https://portswigger.net/burp/) is an interactive HTTP/S proxy server for attacking and testing web applications.
@@ -234,4 +233,4 @@ If source code is available (white-box testing), all variables received from use
 
 - [CERT - Malicious HTML Tags Embedded in Client Web Requests](https://resources.sei.cmu.edu/asset_files/WhitePaper/2000_019_001_496188.pdf)
 - [cgisecurity.com - The Cross Site Scripting FAQ](https://www.cgisecurity.com/xss-faq.html)
-- [S. Frei, T. Dübendorfer, G. Ollmann, M. May - Understanding the Web browser threat](https://www.techzoom.net/Publications/Insecurity-Iceberg)
+- [S. Frei, T. Dübendorfer, G. Ollmann, M. May - Understanding the Web browser threat](https://www.researchgate.net/publication/230751208_Understanding_the_Web_browser_threat_Examination_of_vulnerable_online_Web_browser_populations_and_the_insecurity_iceberg)

latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting.md

@@ -28,12 +28,12 @@ This vulnerability can be used to conduct a number of browser-based attacks incl
 - Directed delivery of browser-based exploits
 - Other malicious activities
 
-Stored XSS does not need a malicious link to be exploited. A successful exploitation occurs when a user visits a page with a stored XSS. The following phases relate to a typical stored XSS attack scenario:
+Stored XSS does not need the victim to click a malicious link - exploitation occurs when a user visits a page with a stored XSS. The following phases relate to a typical stored XSS attack scenario:
 
-- Attacker stores malicious code into the vulnerable page
-- User authenticates in the application
-- User visits vulnerable page
-- Malicious code is executed by the user's browser
+- The attacker stores malicious code into the vulnerable page
+- The victim authenticates in the application
+- The victim views the vulnerable page
+- Malicious code is executed by the victim's browser
 
 This type of attack can also be exploited with browser exploitation frameworks such as [BeEF](https://beefproject.com) and [XSS Proxy](https://xss-proxy.sourceforge.net/). These frameworks allow for complex JavaScript exploit development.
 
@@ -62,11 +62,13 @@ The first step is to identify all points where user input is stored into the bac
 - Blog: if the blog application permits to users submitting comments
 - Log: if the application stores some users input into logs.
 
+> Note: This can also include URL paths, cookies, HTTP headers and other less-obvious types of user input, as well as GET and POST parameters.
+
 #### Analyze HTML Code
 
-Input stored by the application is normally used in HTML tags, but it can also be found as part of JavaScript content. At this stage, it is fundamental to understand if input is stored and how it is positioned in the context of the page. Differently from reflected XSS, the pen-tester should also investigate any out-of-band channels through which the application receives and stores users input.
+Input stored by the application is normally used in HTML tags, but it can also be found as part of JavaScript content. At this stage, it is fundamental to understand if input is stored and how it is positioned in the context of the page. Differently from reflected XSS, the pentester should also investigate any out-of-band channels through which the application receives and stores users input, such as via email or integration with external applications.
 
-**Note**: All areas of the application accessible by administrators should be tested to identify the presence of any data submitted by users.
+> Note: All areas of the application accessible by administrators should be tested to identify the presence of any data submitted by users.
 
 **Example**: Email stored data in `index2.php`
 
@@ -103,7 +105,7 @@ Ensure the input is submitted through the application. This normally involves di
 > <input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"><script>alert(document.cookie)</script>
 > ```
 >
-> The input is stored and the XSS payload is executed by the browser when reloading the page. If the input is escaped by the application, testers should test the application for XSS filters. For instance, if the string "SCRIPT" is replaced by a space or by a NULL character then this could be a potential sign of XSS filtering in action. Many techniques exist in order to evade input filters (see [testing for reflected XSS](01-Testing_for_Reflected_Cross_Site_Scripting.md)) chapter). It is strongly recommended that testers refer to [XSS Filter Evasion](https://owasp.org/www-community/xss-filter-evasion-cheatsheet) and [Mario](https://cybersecurity.wtf/encoder/) XSS Cheat pages, which provide an extensive list of XSS attacks and filtering bypasses. Refer to the whitepapers and tools section for more detailed information.
+> The input is stored and the XSS payload is executed by the browser when reloading the page. If the input is escaped by the application, testers should test the application for XSS filters. For instance, if the string "SCRIPT" is replaced by a space or by a NULL character then this could be a potential sign of XSS filtering in action. Many techniques exist in order to evade input filters (see [testing for reflected XSS](01-Testing_for_Reflected_Cross_Site_Scripting.md)) chapter). It is strongly recommended that testers refer to [XSS Filter Evasion](https://owasp.org/www-community/xss-filter-evasion-cheatsheet) and other XSS Cheat pages, which provide an extensive list of XSS attacks and filtering bypasses. Refer to the whitepapers and tools section for more detailed information.
 
 #### Leverage Stored XSS with BeEF
 
@@ -132,7 +134,7 @@ When the user loads the page `index2.php`, the script `hook.js` is executed by t
 
 #### File Upload
 
-If the web application allows file upload, it is important to check if it is possible to upload HTML content. For instance, if HTML or TXT files are allowed, XSS payload can be injected in the file uploaded. The pen-tester should also verify if the file upload allows setting arbitrary MIME types.
+If the web application allows file upload, it is important to check if it is possible to upload HTML content. For instance, if HTML or TXT files are allowed, XSS payload can be injected in the uploaded file. The pentester should also verify if the file upload allows setting arbitrary MIME types.
 
 Consider the following HTTP POST request for file upload:
 
@@ -162,11 +164,11 @@ Also consider that Internet Explorer does not handle MIME types in the same way
 
 Blind Cross-site Scripting is a form of stored XSS. It generally occurs when the attacker’s payload is saved on the server/infrastructure and later reflected back to the victim from the backend application. For example in feedback forms, an attacker can submit the malicious payload using the form, and once the backend user/admin of the application views the attacker’s submission via the backend application, the attacker’s payload will get executed. Blind Cross-site Scripting is hard to confirm in the real-world scenario but one of the best tools for this is [XSS Hunter](https://xsshunter.com/).
 
-> Note: Testers should carefully consider the privacy implications of using public or third party services while performing security tests. (See #tools.)
+> Note: Testers should carefully consider the privacy implications of using public or third party services while performing security tests. (See [#tools](#tools).)
 
 ### Gray-Box Testing
 
-Gray-box testing is similar to black-box testing. In gray-box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and data storage might be known by the pen-tester.
+Gray-box testing is similar to black-box testing. In gray-box testing, the pentester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and data storage might be known by the pentester.
 
 Depending on the information available, it is normally recommended that testers check how user input is processed by the application and then stored into the backend system. The following steps are recommended:
 
@@ -186,12 +188,12 @@ The following table summarizes some special variables and functions to look at w
 | `$_POST` - HTTP POST variables| `Request.Form` - HTTP POST | `request.getParameter` - HTTP GET/POST variables |
 | `$_REQUEST` – HTTP POST, GET and COOKIE variables | `Server.CreateObject` - used to upload files | |
 | `$_FILES` - HTTP File Upload variables | | |
+| `$_SERVER` - HTTP headers | | |
 
-**Note**: The table above is only a summary of the most important parameters but, all user input parameters should be investigated.
+> Note: The table above is only a summary of the most important parameters but, all user input parameters should be investigated.
 
 ## Tools
 
-- [PHP Charset Encoder(PCE)](https://cybersecurity.wtf/encoder/) helps you encode arbitrary texts to and from 65 kinds of character sets that you can use in your customized payloads.
 - [Hackvertor](https://hackvertor.co.uk/public) is an online tool which allows many types of encoding and obfuscation of JavaScript (or any string input).
 - [BeEF](https://www.beefproject.com) is the browser exploitation framework. A professional tool to demonstrate the real-time impact of browser vulnerabilities.
 - [XSS-Proxy](https://xss-proxy.sourceforge.net/) is an advanced Cross-Site-Scripting (XSS) attack tool.