From 7e98e2f7c0c889eb4aaf2a5be1aec9e148c2d9ad Mon Sep 17 00:00:00 2001 From: wstgbot <62450690+wstgbot@users.noreply.github.com> Date: Sun, 7 Jun 2026 00:57:29 +0000 Subject: [PATCH] Publish Latest 2026-06-07 Updates based on OWASP/wstg@a31f9c4 --- .../03-Testing_for_Weak_Lock_Out_Mechanism.md | 8 ++++-- ...r_OAuth_Authorization_Server_Weaknesses.md | 2 +- ...5.2-Testing_for_OAuth_Client_Weaknesses.md | 2 +- ...ting_for_Reflected_Cross_Site_Scripting.md | 13 ++++----- ...Testing_for_Stored_Cross_Site_Scripting.md | 28 ++++++++++--------- ...04-Testing_for_HTTP_Parameter_Pollution.md | 6 ++-- .../05-Testing_for_SQL_Injection.md | 2 +- .../05.2-Testing_for_MySQL.md | 2 +- .../05.3-Testing_for_SQL_Server.md | 10 +++---- .../05.6-Testing_for_NoSQL_Injection.md | 2 +- .../07-Testing_for_XML_Injection.md | 12 ++++---- .../08-Testing_for_SSI_Injection.md | 2 +- .../09-Testing_for_XPath_Injection.md | 2 +- .../10-Testing_for_IMAP_SMTP_Injection.md | 7 +++-- .../14-Testing_for_Incubated_Vulnerability.md | 4 +-- ...Testing_for_Server-Side_Request_Forgery.md | 3 +- .../10-Testing_WebSockets.md | 2 +- 17 files changed, 57 insertions(+), 50 deletions(-) diff --git a/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism.md b/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism.md index 48795589..8a8486d5 100644 --- a/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism.md +++ b/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. diff --git a/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.1-Testing_for_OAuth_Authorization_Server_Weaknesses.md b/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.1-Testing_for_OAuth_Authorization_Server_Weaknesses.md index 36c6c82e..84e49ad1 100644 --- a/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.1-Testing_for_OAuth_Authorization_Server_Weaknesses.md +++ b/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 diff --git a/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.2-Testing_for_OAuth_Client_Weaknesses.md b/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.2-Testing_for_OAuth_Client_Weaknesses.md index a4d8a42d..869a1f45 100644 --- a/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.2-Testing_for_OAuth_Client_Weaknesses.md +++ b/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 diff --git a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting.md b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting.md index 99f68be8..a34eeae7 100644 --- a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting.md +++ b/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 ` > ``` > -> 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. diff --git a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution.md b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution.md index 9f82675c..6210ee25 100644 --- a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution.md +++ b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution.md @@ -78,7 +78,9 @@ Given the URL and querystring: `https://example.com/?color=red&color=blue` ## How to Test -Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions. However, as in-depth business logic knowledge is necessary, testing HPP requires manual testing. Automatic tools can only partially assist auditors as they tend to generate too many false positives. In addition, HPP can manifest itself in client-side and server-side components. +Whether an specific page or API endpoint is vulnerable to HPP will depend on the interaction between multiple components, including the application, the web server, the web application firewall and any middleware. Where these vary for different parts of an application (such as a microservice architecture), this can result in some parts of the application being vulnerable and not others. + +As in-depth business logic knowledge is necessary, testing HPP requires manual testing. Automatic tools can only partially assist auditors as they tend to generate too many false positives. In addition, HPP can manifest itself in client-side and server-side components. ### Server-Side HPP @@ -119,7 +121,7 @@ and submit the new request. Analyze the response page to determine which value(s) were parsed. In the above example, the search results may show `kittens`, `puppies`, some combination of both (`kittens,puppies` or `kittens~puppies` or `['kittens','puppies']`), may give an empty result, or error page. -This behavior, whether using the first, last, or combination of input parameters with the same name, is very likely to be consistent across the entire application. Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation and other security mechanisms are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated, different web application components use different occurrences or testing generates an error, there is an increased likelihood of being able to use parameter pollution to trigger security vulnerabilities. +Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation and other security mechanisms are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated, different web application components use different occurrences or testing generates an error, there is an increased likelihood of being able to use parameter pollution to trigger security vulnerabilities. A more in-depth analysis would require three HTTP requests for each HTTP parameter: diff --git a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection.md b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection.md index a32f59a6..ae4c11bf 100644 --- a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection.md +++ b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection.md @@ -498,7 +498,7 @@ Automation: #### Boolean Exploitation Technique -The Boolean exploitation technique is very useful when the tester finds a [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection) situation, in which nothing is known about the outcome of an operation. For example, this behavior happens in cases where the programmer has created a custom error page that does not reveal anything about the structure of the query or the database. (The page does not return a SQL error, it may just return an HTTP 500, 404, or redirect). +The Boolean exploitation technique is very useful when the tester finds a [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection) situation, in which nothing is known about the outcome of an operation. For example, this behavior happens in cases where the programmer has created a custom error page that does not reveal anything about the structure of the query or the database, or return any SQL error - it may just return a HTTP 404 or 500, or a browser redirect. By using inference methods, it is possible to avoid this obstacle and thus succeed in recovering the values of some desired fields. This method consists of carrying out a series of boolean queries against the server, observing the answers, and finally deducing the meaning of such answers. We consider, as always, the `www.example.com` domain and we suppose that it contains a parameter named `id` vulnerable to SQL injection. This means that when carrying out the following request: diff --git a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.2-Testing_for_MySQL.md b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.2-Testing_for_MySQL.md index 544e5248..4e1ae6be 100644 --- a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.2-Testing_for_MySQL.md +++ b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.2-Testing_for_MySQL.md @@ -13,7 +13,7 @@ tags: WSTG [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection) vulnerabilities occur whenever input is used in the construction of a SQL query without being adequately constrained or sanitized. The use of dynamic SQL (the construction of SQL queries by concatenation of strings) opens the door to these vulnerabilities. SQL injection allows an attacker to access the SQL servers. It allows for the execution of SQL code under the privileges of the user used to connect to the database. -*MySQL server* has a few particularities so that some exploits need to be specially customized for this application. That's the subject of this section. +*MySQL server* has a few particularities so that some exploits need to be specially customized for this application. That's the subject of this section. Note that as MariaDB is a fork of MySQL, teh contents of this page will also be relevant for MariaDB. ## How to Test diff --git a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.3-Testing_for_SQL_Server.md b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.3-Testing_for_SQL_Server.md index dcfda3f4..57da23ca 100644 --- a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.3-Testing_for_SQL_Server.md +++ b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.3-Testing_for_SQL_Server.md @@ -50,7 +50,7 @@ Alternatively, we can use `sp_makewebtask`: `exec sp_makewebtask 'C:\Inetpub\wwwroot\test.txt', 'select * from master.dbo.sysobjects'--` -A successful execution will create a file that can be browsed by the pen tester. Keep in mind that `sp_makewebtask` is deprecated, and, even if it works in all SQL Server versions up to 2005, it might be removed in the future. +A successful execution will create a file that can be browsed by the pentester. Keep in mind that `sp_makewebtask` is deprecated, and, even if it works in all SQL Server versions up to 2005, it might be removed in the future. In addition, SQL Server built-in functions and environment variables are very handy. The following uses the function `db_name()` to trigger an error that will return the name of the database: @@ -168,7 +168,7 @@ Allows the execution of arbitrary SQL Code. The same happens with the User-Agent ### Example 7: SQL Server as a Port Scanner -In SQL Server, one of the most useful (at least for the penetration tester) commands is OPENROWSET, which is used to run a query on another DB Server and retrieve the results. The penetration tester can use this command to scan ports of other machines in the target network, injecting the following query: +In SQL Server, one of the most useful (at least for the pentester) commands is OPENROWSET, which is used to run a query on another DB Server and retrieve the results. The penetration tester can use this command to scan ports of other machines in the target network, injecting the following query: `select * from OPENROWSET('SQLOLEDB','uid=sa;pwd=foobar;Network=DBMSSOCN;Address=x.y.w.z,p;timeout=5','select 1')--` @@ -216,7 +216,7 @@ At this point, our executable is available on the target machine, ready to be ex ### Obtain Information When It Is Not Displayed (Out of Band) -Not all is lost when the web application does not return any information --such as descriptive error messages (cf. [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection)). For example, it might happen that one has access to the source code (e.g., because the web application is based on an open source software). Then, the pen tester can exploit all the SQL injection vulnerabilities discovered offline in the web application. Although an IPS might stop some of these attacks, the best way would be to proceed as follows: develop and test the attacks in a testbed created for that purpose, and then execute these attacks against the web application being tested. +Not all is lost when the web application does not return any information --such as descriptive error messages (cf. [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection)). For example, it might happen that one has access to the source code (e.g., because the web application is based on an open source software). Then, the pentester can exploit all the SQL injection vulnerabilities discovered offline in the web application. Although an IPS might stop some of these attacks, the best way would be to proceed as follows: develop and test the attacks in a testbed created for that purpose, and then execute these attacks against the web application being tested. Other options for out of band attacks are described in [Sample 4 above](#example-4-yet-another-useful-get-example). @@ -249,7 +249,7 @@ There is one more possibility for making a blind SQL injection attack when there `if exists (select * from pubs..pub_info) waitfor delay '0:0:5'` -Depending on the time that the query takes to return, we will know the answer. In fact, what we have here is two things: a `SQL injection vulnerability` and a `covert channel` that allows the penetration tester to get 1 bit of information for each query. Hence, using several queries (as many queries as bits in the required information) the pen tester can get any data that is in the database. Look at the following query +Depending on the time that the query takes to return, we will know the answer. In fact, what we have here is two things: a `SQL injection vulnerability` and a `covert channel` that allows the penetration tester to get 1 bit of information for each query. Hence, using several queries (as many queries as bits in the required information) the pentester can get any data that is in the database. Look at the following query ```sql declare @s varchar(8000) @@ -265,7 +265,7 @@ Measuring the response time and using different values for `@i`, we can deduce t This query will wait for 5 seconds if bit `@bit` of byte `@byte` of the name of the current database is 1, and will return at once if it is 0. Nesting two cycles (one for `@byte` and one for `@bit`) we will we able to extract the whole piece of information. -However, it might happen that the command `waitfor` is not available (e.g., because it is filtered by an IPS/web application firewall). This doesn't mean that blind SQL injection attacks cannot be done, as the pen tester should only come up with any time consuming operation that is not filtered. For example +However, it might happen that the command `waitfor` is not available (e.g., because it is filtered by an IPS/web application firewall). This doesn't mean that blind SQL injection attacks cannot be done, as the pentester should only come up with any time consuming operation that is not filtered. For example ```sql declare @i int select @i = 0 diff --git a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.6-Testing_for_NoSQL_Injection.md b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.6-Testing_for_NoSQL_Injection.md index e547ca35..5a6a09b8 100644 --- a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.6-Testing_for_NoSQL_Injection.md +++ b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.6-Testing_for_NoSQL_Injection.md @@ -57,7 +57,7 @@ Even if the input used within queries is completely sanitized or parameterized, For example within MongoDB, the `$where` syntax itself is a reserved query operator. It needs to be passed into the query exactly as shown; any alteration would cause a database error. However, because `$where` is also a valid PHP variable name, it may be possible for an attacker to insert code into the query by creating a PHP variable named `$where`. The PHP MongoDB documentation explicitly warns developers: -Please make sure that for all special query operators (starting with `$`) you use single quotes so that PHP doesn't try to replace `$exists` with the value of the variable `$exists`. +> Please make sure that for all special query operators (starting with `$`) you use single quotes so that PHP doesn't try to replace `$exists` with the value of the variable `$exists`. Even if a query depended on no user input, such as the following example, an attacker could exploit MongoDB by replacing the operator with malicious data. diff --git a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XML_Injection.md b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XML_Injection.md index 5e50f16b..6219731f 100644 --- a/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XML_Injection.md +++ b/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/07-Testing_for_XML_Injection.md @@ -15,9 +15,9 @@ tags: WSTG ## Summary -XML Injection testing is when a tester tries to inject an XML doc to the application. If the XML parser fails to contextually validate data, then the test will yield a positive result. +XML Injection testing is when a tester tries to inject an XML document into the application. If the XML parser fails to contextually validate data, then the test will yield a positive result. -This section describes practical examples of XML Injection. First, an XML style communication will be defined and its working principles explained. Then, the discovery method in which we try to insert XML metacharacters. Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection). +This section describes practical examples of XML Injection. First, an XML style communication will be defined and its working principles explained. Then, the discovery method in which we try to insert XML metacharacters. Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (tag injection). ## Test Objectives @@ -26,7 +26,7 @@ This section describes practical examples of XML Injection. First, an XML style ## How to Test -Let's suppose there is a web application using an XML style communication in order to perform user registration. This is done by creating and adding a new `user>`node in an `xmlDb` file. +Let's suppose there is a web application using an XML style communication in order to perform user registration. This is done by creating and adding a new ``node in an `xmlDb` file. Let's suppose the xmlDB file is like the following: @@ -152,7 +152,7 @@ the application will build a new node: but, because of the presence of the open '<', the resulting XML document is invalid. -- Comment tag: `` - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter: +- Comment tag: `` - This sequence of characters is interpreted as the beginning or end of a comment. So by injecting one of them in Username parameter: `Username = foo