DEFINITIONS = [
    {
        "issue_type_id": "1048832",
        "name": "OS command injection",
        "description": "<p>Operating system command injection vulnerabilities arise when an application incorporates user-controllable data into a command that is processed by a shell command interpreter. If the user data is not strictly validated, an attacker can use shell metacharacters to modify the command that is executed, and inject arbitrary further commands that will be executed by the server.</p>\n<p>OS command injection vulnerabilities are usually very serious and may lead to compromise of the server hosting the application, or of the application's own data and functionality. It may also be possible to use the server as a platform for attacks against other systems. The exact potential for exploitation depends upon the security context in which the command is executed, and the privileges that this context has regarding sensitive resources on the server.</p>",
        "remediation": "<p>If possible, applications should avoid incorporating user-controllable data into operating system commands. In almost every situation, there are safer alternative methods of performing server-level tasks, which cannot be manipulated to perform additional commands than the one intended.</p>\n<p>If it is considered unavoidable to incorporate user-supplied data into operating system commands, the following two layers of defense should be used to prevent attacks: </p>\n<ul>\n  <li>The user data should be strictly validated. Ideally, a whitelist of specific accepted values should be used. Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable shell metacharacter or whitespace, should be rejected.</li>\n  <li>The application should use command APIs that launch a specific process via its name and command-line parameters, rather than passing a command string to a shell interpreter that supports command chaining and redirection. For example, the Java API Runtime.exec and the ASP.NET API Process.Start do not support shell metacharacters. This defense can mitigate the impact of an attack even in the event that an attacker circumvents the input validation defenses.</li>\n</ul>",
        "references": "<ul>\n<li><a href=\"https://portswigger.net/web-security/os-command-injection\">OS command injection</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/77.html\">CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/78.html\">CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1049088",
        "name": "SQL injection",
        "description": "<p>SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.</p>\n<p>A wide range of damaging attacks can often be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and taking control of the database server. </p>",
        "remediation": "<p>The most effective way to prevent SQL injection attacks is to use parameterized queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already been defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterized queries. It is strongly recommended that you parameterize <i>every</i> variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.</p>\n<p>You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective: </p>\n<ul>\n  <li>One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense is designed to prevent malformed data from terminating the string into which it is inserted. However, if the data being incorporated into queries is numeric, then the defense may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defense to be bypassed.</li>\n  <li>Another often cited defense is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.</li>\n</ul>",
        "references": "<ul>\n<li><a href=\"https://portswigger.net/web-security/sql-injection\">SQL injection</a></li>\n<li><a href=\"https://support.portswigger.net/customer/portal/articles/1965677-using-burp-to-test-for-injection-flaws\">Using Burp to Test for Injection Flaws</a></li>\n<li><a href=\"https://portswigger.net/web-security/sql-injection/cheat-sheet\">SQL Injection Cheat Sheet</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/89.html\">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')\n</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1049104",
        "name": "SQL injection (second order)",
        "description": "<p>SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.</p>\n<p>A wide range of damaging attacks can often be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and taking control of the database server. </p>\n \n<p>Second-order SQL injection arises when user-supplied data is stored by the application and later incorporated into SQL queries in an unsafe way. To detect the vulnerability, it is normally necessary to submit suitable data in one location, and then use some other application function that processes the data in an unsafe way.</p>",
        "remediation": "<p>The most effective way to prevent SQL injection attacks is to use parameterized queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already been defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterized queries. It is strongly recommended that you parameterize <i>every</i> variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.</p>\n<p>You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective: </p>\n<ul>\n  <li>One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense is designed to prevent malformed data from terminating the string into which it is inserted. However, if the data being incorporated into queries is numeric, then the defense may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defense to be bypassed.</li>\n  <li>Another often cited defense is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.</li>\n</ul>",
        "references": "<ul>\n<li><a href=\"https://portswigger.net/web-security/sql-injection\">SQL injection</a></li>\n<li><a href=\"https://support.portswigger.net/customer/portal/articles/1965677-using-burp-to-test-for-injection-flaws\">Using Burp to Test for Injection Flaws</a></li>\n<li><a href=\"https://portswigger.net/web-security/sql-injection/cheat-sheet\">SQL Injection Cheat Sheet</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/89.html\">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')\n</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1049216",
        "name": "ASP.NET tracing enabled",
        "description": "<p>ASP.NET tracing is a debugging feature that is designed for use during development to help troubleshoot problems. It discloses sensitive information to users, and if enabled in production contexts may present a serious security threat.</p>\n<p>Application-level tracing enables any user to retrieve full details about recent requests to the application, including those of other users. This information typically includes session tokens and request parameters, which may enable an attacker to compromise other users and even take control of the entire application.</p>\n<p>Page-level tracing returns the same information, but relating only to the current request. This may still contain sensitive data in session and server variables that would be of use to an attacker.</p>",
        "remediation": "<p>To disable tracing, open the Web.config file for the application, and find the &lt;trace&gt; element within the &lt;system.web&gt; section. Either set the enabled attribute to \"false\" (to disable tracing) or set the localOnly attribute to \"true\" (to enable tracing only on the server itself).</p>\n<p>Note that even with tracing disabled in this way, it is possible for individual pages to turn on page-level tracing either within the Page directive of the ASP.NET page, or programmatically through application code. If you observe tracing output only on some application pages, you should review the page source and the code behind, to find the reason why tracing is occurring.</p>\n<p>It is strongly recommended that you refer to your platform's documentation relating to this issue, and do not rely solely on the above remediation.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/10.html\">CWE-10: ASP.NET Environment Issues\n</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/11.html\">CWE-11: ASP.NET Misconfiguration: Creating Debug Binary</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1049344",
        "name": "File path traversal",
        "description": "<p>File path traversal vulnerabilities arise when user-controllable data is used within a filesystem operation in an unsafe manner. Typically, a user-supplied filename is appended to a directory prefix in order to read or write the contents of a file. If vulnerable, an attacker can supply path traversal sequences (using dot-dot-slash characters) to break out of the intended directory and read or write files elsewhere on the filesystem.</p>\n<p>This is typically a very serious vulnerability, enabling an attacker to access sensitive files containing configuration data, passwords, database records, log data, source code, and program scripts and binaries. </p>",
        "remediation": "<p>Ideally, application functionality should be designed in such a way that user-controllable data does not need to be passed to filesystem operations. This can normally be achieved by referencing known files via an index number rather than their name, and using application-generated filenames to save user-supplied file content.</p>\n<p>If it is considered unavoidable to pass user-controllable data to a filesystem operation, three layers of defense can be employed to prevent path traversal attacks: </p>\n<ul><li>User-controllable data should be strictly validated before being passed to any filesystem operation. In particular, input containing dot-dot sequences should be blocked.</li><li>After validating user input, the application can use a suitable filesystem API to verify that the file to be accessed is actually located within the base directory used by the application. In Java, this can be achieved by instantiating a java.io.File object using the user-supplied filename and then calling the getCanonicalPath method on this object. If the string returned by this method does not begin with the name of the start directory, then the user has somehow bypassed the application's input filters, and the request should be rejected. In ASP.NET, the same check can be performed by passing the user-supplied filename to the System.Io.Path.GetFullPath method and checking the returned string in the same way as described for Java.</li><li>The directory used to store files that are accessed using user-controllable data can be located on a separate logical volume to other sensitive application and operating system files, so that these cannot be reached via path traversal attacks. In Unix-based systems, this can be achieved using a chrooted filesystem; on Windows, this can be achieved by mounting the base directory as a new logical drive and using the associated drive letter to access its contents.</li></ul>",
        "references": "<ul>\n\t<li>\n\t<a href=\"https://portswigger.net/web-security/file-path-traversal\">File path traversal</a>\n\t\t</li>\n\t</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/22.html\">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/23.html\">CWE-23: Relative Path Traversal</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/35.html\">CWE-35: Path Traversal: '.../...//'</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/36.html\">CWE-36: Absolute Path Traversal</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1049600",
        "name": "XML external entity injection",
        "description": "<p>XML external entity (XXE) injection vulnerabilities arise when applications process user-supplied XML documents without disabling references to external resources. XML parsers typically support external references by default, even though they are rarely required by applications during normal usage.</p>\n<p>External entities can reference files on the parser's filesystem; exploiting this feature may allow retrieval of arbitrary files, or denial of service by causing the server to read from a file such as /dev/random.</p>\n<p>External entities can often also reference network resources via the HTTP protocol handler. The ability to send requests to other systems can allow the vulnerable server to be used as an attack proxy. \n  By submitting suitable payloads, an attacker can cause the application server to attack other systems that it can interact with. \n  This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. \n  Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers.\n</p>",
        "remediation": "<p>Parsers that are used to process XML from untrusted sources should be configured to disable processing of all external resources. This is usually possible, and will prevent a number of related attacks.&nbsp;You should consult the documentation for your XML parsing library to determine how to achieve this.</p>\n\n<p>XML external entity injection makes use of the DOCTYPE tag to define the injected entity. It may also be possible to disable the DOCTYPE tag or use input validation to block input containing it.</p>",
        "references": "<ul><li><a href=\"https://portswigger.net/web-security/xxe\">XXE injection</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/611.html\">CWE-611: Improper Restriction of XML External Entity Reference ('XXE')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1049856",
        "name": "LDAP injection",
        "description": "<p>LDAP injection arises when user-controllable data is copied in an unsafe way into an LDAP query that is performed by the application. If an attacker can inject LDAP metacharacters into the query, then they can interfere with the query's logic. Depending on the function for which the query is used, the attacker may be able to retrieve sensitive data to which they are not authorized, or subvert the application's logic to perform some unauthorized action.</p>\n<p>Note that automated difference-based tests for LDAP injection flaws can often be unreliable and are prone to false positive results. Scanner results should be manually reviewed to confirm whether a vulnerability is actually present. </p>",
        "remediation": "<p>If possible, applications should avoid copying user-controllable data into LDAP queries. If this is unavoidable, then the data should be strictly validated to prevent LDAP injection attacks. In most situations, it will be appropriate to allow only short alphanumeric strings to be copied into queries, and any other input should be rejected. At a minimum, input containing any LDAP metacharacters should be rejected; characters that should be blocked include ( ) ; , * | & = and whitespace.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/90.html\">CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1050112",
        "name": "XPath injection",
        "description": "<p>XPath injection vulnerabilities arise when user-controllable data is incorporated into XPath queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.</p>\n<p>Depending on the purpose for which the vulnerable query is being used, an attacker may be able to exploit an XPath injection flaw to read sensitive application data or interfere with application logic. </p>",
        "remediation": "<p>User input should be strictly validated before being \n  incorporated into XPath queries. \n  In most cases, it will be appropriate to accept input containing only short \n  alphanumeric strings. At the very least, input containing any XPath metacharacters \n  such as \" ' / @ = * [ ] ( and ) should be rejected.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')\n</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/643.html\">CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath Injection')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1050368",
        "name": "XML injection",
        "description": "<p>XML or SOAP injection vulnerabilities arise when user input is inserted into a server-side XML document or SOAP message in an unsafe way. It may be possible to use XML metacharacters to modify the structure of the resulting XML. Depending on the function in which the XML is used, it may be possible to interfere with the application's logic, to perform unauthorized actions or access sensitive data.</p>\n<p>This kind of vulnerability can be difficult to detect and exploit remotely; you should review the application's response, and the purpose that the relevant input performs within the application's functionality, to determine whether it is indeed vulnerable. </p>",
        "remediation": "<p>The application should validate or sanitize user input before incorporating it into an XML document or SOAP message. It may be possible to block any input containing XML metacharacters such as &lt; and &gt;. Alternatively, these characters can be replaced with the corresponding entities: &amp;lt; and &amp;gt;.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/91.html\">CWE-91: XML Injection (aka Blind XPath Injection)</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/611.html\">CWE-611: Improper Restriction of XML External Entity Reference ('XXE')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/776.html\">CWE-776: Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1050624",
        "name": "ASP.NET debugging enabled",
        "description": "<p>ASP.NET allows remote debugging of web applications, if configured to do so. By default, debugging is subject to access control and requires platform-level authentication. </p>\n<p>If an attacker can successfully start a remote debugging session, this is likely to disclose sensitive information about the web application and supporting infrastructure that may be valuable in formulating targeted attacks against the system. </p>",
        "remediation": "<p>To disable debugging, open the Web.config file for the application, and find the &lt;compilation&gt; element within the &lt;system.web&gt; section. Set the debug attribute to \"false\". Note that it is also possible to enable debugging for all applications within the Machine.config file. You should confirm that the debug attribute in the &lt;compilation&gt; element has not been set to \"true\" within the Machine.config file.</p>\n<p>It is strongly recommended that you refer to your platform's documentation relating to this issue, and do not rely solely on the above remediation. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/11.html\">CWE-11: ASP.NET Misconfiguration: Creating Debug Binary</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1050880",
        "name": "HTTP PUT method is enabled",
        "description": "<p>The HTTP PUT method is normally used to upload data that is saved on the server at a user-supplied URL. If enabled, an attacker may be able to place arbitrary, and potentially malicious, content into the application. Depending on the server's configuration, this may lead to compromise of other users (by uploading client-executable scripts), compromise of the server (by uploading server-executable code), or other attacks.</p>",
        "remediation": "<p>Refer to your platform's documentation to determine how to disable the HTTP PUT method on the server.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/650.html\">CWE-650: Trusting HTTP Permission Methods on the Server Side\n</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1051136",
        "name": "Out-of-band resource load (HTTP)",
        "description": "<p>Out-of-band resource load arises when it is possible to induce an application to fetch content from an arbitrary external location, and incorporate that content into the application's own response(s). The ability to trigger arbitrary out-of-band resource load does not constitute a vulnerability in its own right, and in some cases might even be the intended behavior of the application. \nHowever, in many cases, it can indicate a vulnerability with serious consequences.</p>\n<p>The ability to request and retrieve web content from other systems can allow the application server to be used as a two-way attack proxy. \n  By submitting suitable payloads, an attacker can cause the application server to attack, or retrieve content from, other systems that it can interact with. \n  This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. \n  Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers.</p>\n<p>Additionally, the application's processing of web content that is retrieved from arbitrary URLs exposes some important and non-conventional attack surface. \n  An attacker can deploy a web server that returns malicious content, and then induce the application to retrieve and process that content. \n  This processing might give rise to the types of input-based vulnerabilities that are normally found when unexpected input is submitted directly in requests to the application. \n  The out-of-band attack surface that the application exposes should be thoroughly tested for these types of vulnerabilities. </p>",
        "remediation": "<p>You should review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary out-of-band resource load is intended behavior. \n  If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. \n  These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter. \nYou should also ensure that content retrieved from other systems is processed in a safe manner, with the usual precautions that are applicable when processing input from direct incoming web requests.</p>\n<p>If the ability to trigger arbitrary out-of-band resource load is not intended behavior, then you should implement a whitelist of permitted URLs, and block requests to URLs that do not appear on this whitelist.</p>",
        "references": "<ul>\n  <li><a href=\"http://blog.portswigger.net/2015/04/introducing-burp-collaborator.html\">Burp Collaborator</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/610.html\">CWE-610: Externally Controlled Reference to a Resource in Another Sphere</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/918.html\">CWE-918: Server-Side Request Forgery (SSRF)</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1051392",
        "name": "File path manipulation",
        "description": "<p>File path manipulation vulnerabilities arise when user-controllable data is placed into a file or URL path that is used on the server to access local resources, which may be within or outside the web root. If vulnerable, an attacker can modify the file path to access different resources, which may contain sensitive information. Even where an attack is constrained within the web root, it is often possible to retrieve items that are normally protected from direct access, such as application configuration files, the source code for server-executable scripts, or files with extensions that the web server is not configured to serve directly.</p>",
        "remediation": "<p>Ideally, application functionality should be designed in such a way that user-controllable data does not need to be placed into file or URL paths in order to access local resources on the server. This can normally be achieved by referencing known files via an index number rather than their name.</p>\n<p>If it is considered unavoidable to place user data into file or URL paths, the data should be strictly validated against a whitelist of accepted values. Note that when accessing resources within the web root, simply blocking input containing file path traversal sequences (such as dot-dot-slash) is not always sufficient to prevent retrieval of sensitive information, because some protected items may be accessible at the original path without using any traversal sequences. </p>",
        "references": "<ul>\n\t<li>\n\t\t<a href=\"https://portswigger.net/web-security/file-path-traversal\">Directory traversal</a>\n\t</li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/22.html\">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/23.html\">CWE-23: Relative Path Traversal</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/35.html\">CWE-35: Path Traversal: '.../...//'</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/36.html\">CWE-36: Absolute Path Traversal</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1051648",
        "name": "PHP code injection",
        "description": "<p>Server-side code injection vulnerabilities arise when an application \n  incorporates user-controllable data into a string that is dynamically evaluated by \n  a code interpreter. If the user data is not strictly validated, an attacker \n  can use crafted input to modify the code to be executed, and inject \n  arbitrary code that will be executed by the server.</p>\n<p>Server-side code injection vulnerabilities are usually very serious and lead to \n  complete compromise of the application's \n  data and functionality, and often of the server that is hosting the application.\n  It may also be possible to use the server as a platform for further attacks against other systems.</p>",
        "remediation": "<p>Whenever possible, applications should avoid incorporating user-controllable data into \n  dynamically evaluated code. In almost every situation, there are safer alternative \n  methods of implementing application functions, which cannot be \n  manipulated to inject arbitrary code into the server's processing.</p>\n<p>If it is considered unavoidable to incorporate user-supplied data into \n  dynamically evaluated code, then the data should be strictly validated. Ideally, a whitelist of specific accepted \n  values should be used. Otherwise, only short alphanumeric strings should be accepted. \n  Input containing any other data, including any conceivable code metacharacters, should be rejected. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')\n</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1051904",
        "name": "Server-side JavaScript code injection",
        "description": "<p>Server-side code injection vulnerabilities arise when an application \n  incorporates user-controllable data into a string that is dynamically evaluated by \n  a code interpreter. If the user data is not strictly validated, an attacker \n  can use crafted input to modify the code to be executed, and inject \n  arbitrary code that will be executed by the server.</p>\n<p>Server-side code injection vulnerabilities are usually very serious and lead to \n  complete compromise of the application's \n  data and functionality, and often of the server that is hosting the application.\n  It may also be possible to use the server as a platform for further attacks against other systems.</p>",
        "remediation": "<p>Whenever possible, applications should avoid incorporating user-controllable data into \n  dynamically evaluated code. In almost every situation, there are safer alternative \n  methods of implementing application functions, which cannot be \n  manipulated to inject arbitrary code into the server's processing.</p>\n<p>If it is considered unavoidable to incorporate user-supplied data into \n  dynamically evaluated code, then the data should be strictly validated. Ideally, a whitelist of specific accepted \n  values should be used. Otherwise, only short alphanumeric strings should be accepted. \n  Input containing any other data, including any conceivable code metacharacters, should be rejected. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/95.html\">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1052160",
        "name": "Perl code injection",
        "description": "<p>Server-side code injection vulnerabilities arise when an application \n  incorporates user-controllable data into a string that is dynamically evaluated by \n  a code interpreter. If the user data is not strictly validated, an attacker \n  can use crafted input to modify the code to be executed, and inject \n  arbitrary code that will be executed by the server.</p>\n<p>Server-side code injection vulnerabilities are usually very serious and lead to \n  complete compromise of the application's \n  data and functionality, and often of the server that is hosting the application.\n  It may also be possible to use the server as a platform for further attacks against other systems.</p>",
        "remediation": "<p>Whenever possible, applications should avoid incorporating user-controllable data into \n  dynamically evaluated code. In almost every situation, there are safer alternative \n  methods of implementing application functions, which cannot be \n  manipulated to inject arbitrary code into the server's processing.</p>\n<p>If it is considered unavoidable to incorporate user-supplied data into \n  dynamically evaluated code, then the data should be strictly validated. Ideally, a whitelist of specific accepted \n  values should be used. Otherwise, only short alphanumeric strings should be accepted. \n  Input containing any other data, including any conceivable code metacharacters, should be rejected. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/95.html\">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1052416",
        "name": "Ruby code injection",
        "description": "<p>Server-side code injection vulnerabilities arise when an application \n  incorporates user-controllable data into a string that is dynamically evaluated by \n  a code interpreter. If the user data is not strictly validated, an attacker \n  can use crafted input to modify the code to be executed, and inject \n  arbitrary code that will be executed by the server.</p>\n<p>Server-side code injection vulnerabilities are usually very serious and lead to \n  complete compromise of the application's \n  data and functionality, and often of the server that is hosting the application.\n  It may also be possible to use the server as a platform for further attacks against other systems.</p>",
        "remediation": "<p>Whenever possible, applications should avoid incorporating user-controllable data into \n  dynamically evaluated code. In almost every situation, there are safer alternative \n  methods of implementing application functions, which cannot be \n  manipulated to inject arbitrary code into the server's processing.</p>\n<p>If it is considered unavoidable to incorporate user-supplied data into \n  dynamically evaluated code, then the data should be strictly validated. Ideally, a whitelist of specific accepted \n  values should be used. Otherwise, only short alphanumeric strings should be accepted. \n  Input containing any other data, including any conceivable code metacharacters, should be rejected. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/95.html\">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1052432",
        "name": "Python code injection",
        "description": "<p>Server-side code injection vulnerabilities arise when an application \n  incorporates user-controllable data into a string that is dynamically evaluated by \n  a code interpreter. If the user data is not strictly validated, an attacker \n  can use crafted input to modify the code to be executed, and inject \n  arbitrary code that will be executed by the server.</p>\n<p>Server-side code injection vulnerabilities are usually very serious and lead to \n  complete compromise of the application's \n  data and functionality, and often of the server that is hosting the application.\n  It may also be possible to use the server as a platform for further attacks against other systems.</p>",
        "remediation": "<p>Whenever possible, applications should avoid incorporating user-controllable data into \n  dynamically evaluated code. In almost every situation, there are safer alternative \n  methods of implementing application functions, which cannot be \n  manipulated to inject arbitrary code into the server's processing.</p>\n<p>If it is considered unavoidable to incorporate user-supplied data into \n  dynamically evaluated code, then the data should be strictly validated. Ideally, a whitelist of specific accepted \n  values should be used. Otherwise, only short alphanumeric strings should be accepted. \n  Input containing any other data, including any conceivable code metacharacters, should be rejected. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/95.html\">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1052448",
        "name": "Expression Language injection",
        "description": "<p>Server-side code injection vulnerabilities arise when an application \n  incorporates user-controllable data into a string that is dynamically evaluated by \n  a code interpreter. If the user data is not strictly validated, an attacker \n  can use crafted input to modify the code to be executed, and inject \n  arbitrary code that will be executed by the server.</p>\n<p>Server-side code injection vulnerabilities are usually very serious and lead to \n  complete compromise of the application's \n  data and functionality, and often of the server that is hosting the application.\n  It may also be possible to use the server as a platform for further attacks against other systems.</p>",
        "remediation": "<p>Whenever possible, applications should avoid incorporating user-controllable data into \n  dynamically evaluated code. In almost every situation, there are safer alternative \n  methods of implementing application functions, which cannot be \n  manipulated to inject arbitrary code into the server's processing.</p>\n<p>If it is considered unavoidable to incorporate user-supplied data into \n  dynamically evaluated code, then the data should be strictly validated. Ideally, a whitelist of specific accepted \n  values should be used. Otherwise, only short alphanumeric strings should be accepted. \n  Input containing any other data, including any conceivable code metacharacters, should be rejected. </p>",
        "references": "<ul>\n<li><a href=\"https://www.mindedsecurity.com/fileshare/ExpressionLanguageInjection.pdf\">Spring Expression Language Injection</a></li>\n<li><a href=\"http://danamodio.com/appsec/research/spring-remote-code-with-expression-language-injection/\">Remote Code Execution with Spring Expression Language Injection</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/917.html\">CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1052672",
        "name": "Unidentified code injection",
        "description": "<p>Server-side code injection vulnerabilities arise when an application \n  incorporates user-controllable data into a string that is dynamically evaluated by \n  a code interpreter. If the user data is not strictly validated, an attacker \n  can use crafted input to modify the code to be executed, and inject \n  arbitrary code that will be executed by the server.</p>\n<p>Server-side code injection vulnerabilities are usually very serious and lead to \n  complete compromise of the application's \n  data and functionality, and often of the server that is hosting the application.\n  It may also be possible to use the server as a platform for further attacks against other systems.</p>",
        "remediation": "<p>Whenever possible, applications should avoid incorporating user-controllable data into \n  dynamically evaluated code. In almost every situation, there are safer alternative \n  methods of implementing application functions, which cannot be \n  manipulated to inject arbitrary code into the server's processing.</p>\n<p>If it is considered unavoidable to incorporate user-supplied data into \n  dynamically evaluated code, then the data should be strictly validated. Ideally, a whitelist of specific accepted \n  values should be used. Otherwise, only short alphanumeric strings should be accepted. \n  Input containing any other data, including any conceivable code metacharacters, should be rejected. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/95.html\">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1052800",
        "name": "Server-side template injection",
        "description": "<p> Server-side template injection occurs when user input is unsafely embedded into a server-side template, allowing users to inject template directives. Using malicious template directives, an attacker may be able to execute arbitrary code and take full control of the web server. </p>\n<p>The severity of this issue varies depending on the type of template engine being used. Template engines range from being trivial to almost impossible to exploit. The following  steps should be used when attempting to develop an exploit: </p><ul>\n  <li>Identify the type of template engine being used.</li>\n  <li>Review its documentation for basic syntax, security considerations, and built-in methods and variables.</li>\n  <li>Explore the template environment and map the attack surface.</li>\n<li>Audit every exposed object and method.</li>\n</ul>\n<p>\nTemplate injection vulnerabilities can be very serious and can lead to complete compromise of the application's data and functionality, and often of the server that is hosting the application. It may also be possible to use the server as a platform for further attacks against other systems. On the other hand, some template injection vulnerabilities may pose no significant security risk.\n</p>",
        "remediation": "<p>Wherever possible, avoid creating templates from user input. Passing user input into templates as parameters is normally a safe alternative.</p>\n<p>If supporting user-submitted templates is a business requirement, consider using a simple logic-less template engine such as Mustache or one provided by the native language like Python's Template. If this is not an option, review the chosen template engine's documentation for hardening advice, and consider rendering the template within a sandboxed execution environment.</p>",
        "references": "<p>For further information on the exploitation process and generic exploits for some popular template engines, please refer to <a href=\"http://blog.portswigger.net/2015/08/server-side-template-injection.html\">the original PortSwigger blog post</a>.</p>\n<p>Other references:</p>\n<ul><li><a href=\"http://freemarker.org/docs/app_faq.html#faq_template_uploading_security\">FreeMarker hardening</a></li>\n<li><a href=\"https://velocity.apache.org/engine/devel/apidocs/org/apache/velocity/util/introspection/SecureUberspector.html\">Velocity Hardening</a></li>\n<li><a href=\"http://twig.sensiolabs.org/doc/api.html#sandbox-extension\">Twig hardening</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/95.html\">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "1052928",
        "name": "SSI injection",
        "description": "<p>Server-Side Include (SSI) injection vulnerabilities arise when an application incorporates user-controllable data into response that is then parsed for Server-Side Include directives. If the data is not strictly validated, an attacker can modify or inject directives to carry out malicious actions.</p>\n<p>SSI injection vulnerabilities can typically be exploited to inject arbitrary content, including JavaScript, into the application's response, with the same impact as cross-site scripting. Depending on the server configuration, it may also be possible to read protected files, or perform arbitrary code execution on the server, with the same impact as OS command injection. </p>",
        "remediation": "<p>If possible, applications should avoid incorporating user-controllable data into pages that are processed for SSI directives. In almost every situation, there are safer alternative methods of implementing the required functionality. If this is not considered feasible, then the data should be strictly validated. Ideally, a whitelist of specific accepted values should be used. Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable SSI metacharacter, should be rejected.</p>",
        "references": "<ul><li><a href=\"http://httpd.apache.org/docs/current/howto/ssi.html\">Introduction to Server-Side Includes</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/96.html\">CWE-96: Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097408",
        "name": "Cross-site scripting (stored)",
        "description": "<p>Stored cross-site scripting vulnerabilities arise when user input is stored and later embedded into the application's responses in an unsafe way. An attacker can use the vulnerability to inject malicious JavaScript code into the application, which will execute within the browser of any user who views the relevant application content.</p>\n<p>The attacker-supplied code can perform a wide variety of actions, such as stealing victims' session tokens or login credentials, performing arbitrary actions on their behalf, and logging their keystrokes.</p>\n<p>Methods for introducing malicious content include any function where request parameters or headers are processed and stored by the application, and any out-of-band channel whereby data can be introduced into the application's processing space (for example, email messages sent over SMTP that are ultimately rendered within a web mail application).</p>\n<p>Stored cross-site scripting flaws are typically more serious than reflected vulnerabilities because they do not require a separate delivery mechanism in order to reach target users, and are not hindered by web browsers' XSS filters. Depending on the affected page, ordinary users may be exploited during normal use of the application. In some situations this can be used to create web application worms that spread exponentially and ultimately exploit all active users.</p>\n<p>Note that automated detection of stored cross-site scripting vulnerabilities cannot reliably determine whether attacks that are persisted within the application can be accessed by any other user, only by authenticated users, or only by the attacker themselves. You should review the functionality in which the vulnerability appears to determine whether the application's behavior can feasibly be used to compromise other application users. </p>",
        "remediation": "<p>In most situations where user-controllable data is copied into application responses, cross-site scripting \n  attacks can be prevented using two layers of defenses:</p>\n<ul>\n  <li>Input should be validated as strictly as possible on arrival, given the kind of content that \nit is expected to contain. For example, personal names should consist of alphabetical \nand a small range of typographical characters, and be relatively short; a year of birth \nshould consist of exactly four numerals; email addresses should match a well-defined \nregular expression. Input which fails the validation should be rejected, not sanitized.</li>\n<li>User input should be HTML-encoded at any point where it is copied into \napplication responses. All HTML metacharacters, including &lt; &gt; \" ' and =, should be \nreplaced with the corresponding HTML entities (&amp;lt; &amp;gt; etc).</li></ul>\n<p>In cases where the application's functionality allows users to author content using \n  a restricted subset of HTML tags and attributes (for example, blog comments which \n  allow limited formatting and linking), it is necessary to parse the supplied HTML to \n  validate that it does not use any dangerous syntax; this is a non-trivial task.</p>",
        "references": "<ul><li><a href=\"https://portswigger.net/web-security/cross-site-scripting\">Cross-site scripting</a></li>\n\t\t<li><a href=\"https://portswigger.net/web-security/cross-site-scripting/stored\">Stored cross-site scripting</a>\n\t</li>\n\n<li><a href=\"https://support.portswigger.net/customer/portal/articles/1965737-Methodology_XSS.html\">Using Burp to Find XSS issues</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/79.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/80.html\">CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097472",
        "name": "HTTP request smuggling",
        "description": "<p>\n    HTTP request smuggling vulnerabilities arise when websites route HTTP requests through webservers with inconsistent HTTP parsing.\n</p>\n<p>\n    By supplying a request that gets interpreted as being different lengths by different servers, an attacker can poison the back-end TCP/TLS socket and prepend arbitrary data to the next request. Depending on the website's functionality, this can be used to bypass front-end security rules, access internal systems, poison web caches, and launch assorted attacks on users who are actively browsing the site.\n</p>",
        "remediation": "<p>\n    You can resolve all variants of this vulnerability by configuring the front-end server to exclusively use HTTP/2 to communicate to back-end systems, or by disabling back-end connection reuse entirely. Alternatively, you could ensure all servers in the chain run the same webserver software with the same configuration.\n</p><p>\n    Specific instances of this vulnerability can be resolved by reconfiguring the front-end server to normalize ambiguous requests before routing them onward, or by configuring the back-end server to reject the message and close the connection when it encounters an ambiguous request.\n</p>",
        "references": "<ul>\n    <li><a href=\"https://portswigger.net/web-security/request-smuggling\">HTTP Request Smuggling</a></li>\n    <li><a href=\"https://portswigger.net/blog/http-desync-attacks\">HTTP Desync Attacks</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n    <li><a href=\"https://cwe.mitre.org/data/definitions/444.html\">\n        CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097536",
        "name": "Web cache poisoning",
        "description": "<p>\n    Web caches identify resources using a few specific components of each HTTP request, together known as the cache key. Two requests with the same cache key are regarded by the cache as equivalent. The cache key typically includes the request line and Host header, but not any other headers.\n</p>\n<p>\n    Web cache poisoning vulnerabilities arise when an application behind a cache processes input that is not included in the cache key. Attackers may be able to exploit this by sending crafted input to trigger a harmful response that the cache will then save and serve to other users.\n</p>\n<p>\n    The impact is potentially serious as the malicious cached page may be served to a large number of users without other interaction. The threat posed by this vulnerability depends largely on what can be achieved with the input. Often the input can be used to trigger XSS or open redirection. In other cases, it can simply be used to swap pages around.\n</p>",
        "remediation": "<p>\n    To resolve this issue, either disable support for the affected headers, or disable caching on all affected pages.\n</p>\n<p>\n    If both the affected header and caching behavior are required, configure the cache to ensure that the header is included in the cache key. Depending on which caching solution you use, it might be possible to achieve this using the Vary response header.\n</p>",
        "references": "<ul>\n    <li><a href=\"https://portswigger.net/blog/practical-web-cache-poisoning\">Practical Web Cache Poisoning</a></li>\n    <li><a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary\">HTTP Vary header</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n    <li><a href=\"https://cwe.mitre.org/data/definitions/436.html\">CWE-436: Interpretation Conflict</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097664",
        "name": "HTTP response header injection",
        "description": "<p>HTTP response header injection vulnerabilities arise when user-supplied data is copied into a response header in an unsafe way. If an attacker can inject newline characters into the header, then they can inject new HTTP headers and also, by injecting an empty line, break out of the headers into the message body and write arbitrary content into the application's response.</p>\n<p>Various kinds of attack can be delivered via HTTP response header injection vulnerabilities. Any attack that can be delivered via cross-site scripting can usually be delivered via response header injection, because the attacker can construct a request that causes arbitrary JavaScript to appear within the response body. Further, it is sometimes possible to leverage response header injection vulnerabilities to poison the cache of any proxy server via which users access the application. Here, an attacker sends a crafted request that results in a \"split\" response containing arbitrary content. If the proxy server can be manipulated to associate the injected response with another URL used within the application, then the attacker can perform a \"stored\" attack against this URL, which will compromise other users who request that URL in future.\n</p>",
        "remediation": "<p>If possible, applications should avoid copying user-controllable data into HTTP response headers. If this is unavoidable, then the data should be strictly validated to prevent response header injection attacks. In most situations, it will be appropriate to allow only short alphanumeric strings to be copied into headers, and any other input should be rejected. At a minimum, input containing any characters with ASCII codes less than 0x20 should be rejected.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/113.html\">CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097920",
        "name": "Cross-site scripting (reflected)",
        "description": "<p>Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request that, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.</p>\n<p>The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.</p>\n<p>Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site that causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).</p>\n<p>The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality that it contains, and the other applications that belong to the same domain and organization. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain that can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organization that owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application and exploiting users' trust in the organization in order to capture credentials for other applications that it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk. </p>",
        "remediation": "<p>In most situations where user-controllable data is copied into application responses, cross-site scripting \n  attacks can be prevented using two layers of defenses:</p>\n<ul>\n  <li>Input should be validated as strictly as possible on arrival, given the kind of content that \nit is expected to contain. For example, personal names should consist of alphabetical \nand a small range of typographical characters, and be relatively short; a year of birth \nshould consist of exactly four numerals; email addresses should match a well-defined \nregular expression. Input which fails the validation should be rejected, not sanitized.</li>\n<li>User input should be HTML-encoded at any point where it is copied into \napplication responses. All HTML metacharacters, including &lt; &gt; \" ' and =, should be \nreplaced with the corresponding HTML entities (&amp;lt; &amp;gt; etc).</li></ul>\n<p>In cases where the application's functionality allows users to author content using \n  a restricted subset of HTML tags and attributes (for example, blog comments which \n  allow limited formatting and linking), it is necessary to parse the supplied HTML to \n  validate that it does not use any dangerous syntax; this is a non-trivial task.</p>",
        "references": "<ul>\n\t<li><a href=\"https://portswigger.net/web-security/cross-site-scripting\">Cross-site scripting</a></li>\n\t<li><a href=\"https://portswigger.net/web-security/cross-site-scripting/reflected\">Reflected cross-site scripting</a></li>\n\t<li><a href=\"https://support.portswigger.net/customer/portal/articles/1965737-Methodology_XSS.html\">Using Burp to Find XSS issues</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/79.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/80.html\">CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097928",
        "name": "Client-side template injection",
        "description": "<p>Client-side template injection vulnerabilities arise when applications using a client-side template framework dynamically embed user input in web pages. When a web page is rendered, the framework will scan the page for template expressions, and execute any that it encounters. An attacker can exploit this by supplying a malicious template expression that launches a cross-site scripting (XSS) attack. As with normal cross-site scripting, the attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.</p>\n<p>Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site that causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).</p>\n<p>The security impact of client-side template injection vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality that it contains, and the other applications that belong to the same domain and organization. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a client-side template injection flaw may be considered low risk. However, if the same application resides on a domain that can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organization that owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application and exploiting users' trust in the organization in order to capture credentials for other applications that it owns. In many kinds of application, such as those providing online banking functionality, client-side template injection should always be considered high risk. </p>\n<p>Client-side template frameworks often implement a sandbox aimed at hindering direct execution of arbitrary JavaScript from within a template expression. However, these sandboxes are not intended to be a security control and can normally be bypassed.</p>\n<p>Browser cross-site scripting filters are typically unable to detect or prevent client-side template injection attacks.</p>",
        "remediation": "<p>If possible, avoid using server-side code to dynamically embed user input into client-side templates. If this is not practical, consider filtering out template expression syntax from user input prior to embedding it within client-side templates. </p>\n<p>Note that HTML-encoding is not sufficient to prevent client-side template injection attacks, because frameworks perform an HTML-decode of relevant content prior to locating and executing template expressions.</p>",
        "references": "<ul>\n<li><a href=\"http://blog.portswigger.net/2016/01/xss-without-html-client-side-template.html\">XSS without HTML: Client-Side Template Injection with AngularJS</a>. This includes a list of known AngularJS sandbox escapes.</li>\n<li><a href=\"https://docs.angularjs.org/guide/security\">AngularJS Security Considerations</a></li>\n<li><a href=\"https://code.google.com/p/mustache-security/\">JavaScript MVC Security Pitfalls</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097936",
        "name": "Cross-site scripting (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n<p>DOM-based cross-site scripting arises when a script  writes controllable data into the HTML document in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.</p>\n<p>The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.</p>\n<p>Users can be induced to visit the attacker's crafted URL in various ways, similar to the usual attack delivery vectors for reflected cross-site scripting vulnerabilities.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based cross-site scripting vulnerabilities is not to dynamically write data from any untrusted source into the HTML document. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing script code into the document. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. In other cases, it will be necessary to sanitize or encode the data. This can be a complex task, and depending on the context that the data is to be inserted may need to involve a combination of JavaScript escaping, HTML encoding, and URL encoding, in the appropriate sequence. </p>",
        "references": "<ul>\n<li><a href=\"https://portswigger.net/web-security/cross-site-scripting\">Cross-site scripting</a></li>\n\t\t<li><a href=\"https://portswigger.net/web-security/cross-site-scripting/dom-based\">DOM-based cross-site scripting</a>\n\t</li>\n\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/79.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/80.html\">CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097937",
        "name": "Cross-site scripting (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>DOM-based cross-site scripting arises when a script  writes controllable data into the HTML document in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.</p>\n<p>The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.</p>\n<p>Users can be induced to visit the attacker's crafted URL in various ways, similar to the usual attack delivery vectors for reflected cross-site scripting vulnerabilities.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based cross-site scripting vulnerabilities is not to dynamically write data from any untrusted source into the HTML document. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing script code into the document. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. In other cases, it will be necessary to sanitize or encode the data. This can be a complex task, and depending on the context that the data is to be inserted may need to involve a combination of JavaScript escaping, HTML encoding, and URL encoding, in the appropriate sequence. </p>",
        "references": "<ul>\n\t<li><a href=\"https://portswigger.net/web-security/cross-site-scripting\">Cross-site scripting</a></li>\n\t<li><a href=\"https://portswigger.net/web-security/cross-site-scripting/reflected\">Reflected cross-site scripting</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/79.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/80.html\">CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097938",
        "name": "Cross-site scripting (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>DOM-based cross-site scripting arises when a script  writes controllable data into the HTML document in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.</p>\n<p>The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.</p>\n<p>Users can be induced to visit the attacker's crafted URL in various ways, similar to the usual attack delivery vectors for reflected cross-site scripting vulnerabilities.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based cross-site scripting vulnerabilities is not to dynamically write data from any untrusted source into the HTML document. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing script code into the document. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. In other cases, it will be necessary to sanitize or encode the data. This can be a complex task, and depending on the context that the data is to be inserted may need to involve a combination of JavaScript escaping, HTML encoding, and URL encoding, in the appropriate sequence. </p>",
        "references": "<ul>\n<li><a href=\"https://portswigger.net/kb/issues/00200300_cross-site-scripting-reflected\">Cross-site scripting</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/79.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/80.html\">CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097952",
        "name": "JavaScript injection (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n\n<p>DOM-based JavaScript injection arises when a script executes controllable data as JavaScript. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.</p>\n<p>The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.</p>\n<p>Users can be induced to visit the attacker's crafted URL in various ways, similar to the usual attack delivery vectors for reflected cross-site scripting vulnerabilities.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based JavaScript injection vulnerabilities is not to execute as JavaScript any data that originated from an untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from executing as script. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. In other cases, it will be necessary to sanitize or encode the data. This can be a complex task, and may need to involve a combination of JavaScript escaping and HTML encoding, in the appropriate sequence. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/95.html\">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097953",
        "name": "JavaScript injection (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>DOM-based JavaScript injection arises when a script executes controllable data as JavaScript. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.</p>\n<p>The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.</p>\n<p>Users can be induced to visit the attacker's crafted URL in various ways, similar to the usual attack delivery vectors for reflected cross-site scripting vulnerabilities.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based JavaScript injection vulnerabilities is not to execute as JavaScript any data that originated from an untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from executing as script. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. In other cases, it will be necessary to sanitize or encode the data. This can be a complex task, and may need to involve a combination of JavaScript escaping and HTML encoding, in the appropriate sequence. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/95.html\">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097954",
        "name": "JavaScript injection (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>DOM-based JavaScript injection arises when a script executes controllable data as JavaScript. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.</p>\n<p>The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.</p>\n<p>Users can be induced to visit the attacker's crafted URL in various ways, similar to the usual attack delivery vectors for reflected cross-site scripting vulnerabilities.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based JavaScript injection vulnerabilities is not to execute as JavaScript any data that originated from an untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from executing as script. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. In other cases, it will be necessary to sanitize or encode the data. This can be a complex task, and may need to involve a combination of JavaScript escaping and HTML encoding, in the appropriate sequence. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/94.html\">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/95.html\">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097960",
        "name": "Path-relative style sheet import",
        "description": "<p>Path-relative style sheet import vulnerabilities arise when the following conditions hold:</p>\n<ol>\n<li>A response contains a style sheet import that uses a path-relative URL (for example, the page at \"/original-path/file.php\" might import \"styles/main.css\").</li><li>When handling requests, the application or platform tolerates superfluous path-like data following the original filename in the URL (for example, \"/original-path/file.php/extra-junk/\"). When superfluous data is added to the original URL, the application's response still contains a path-relative stylesheet import.</li><li>The response in condition 2 can be made to render in a browser's quirks mode, either because it has a missing or old doctype directive, or because it allows itself to be framed by a page under an attacker's control.</li>\n<li>When a browser requests the style sheet that is imported in the response from the modified URL (using the URL \"/original-path/file.php/extra-junk/styles/main.css\"), the application returns something other than the CSS response that was supposed to be imported. Given the behavior described in condition 2, this will typically be the same response that was originally returned in condition 1.</li><li>An attacker has a means of manipulating some text within the response in condition 4, for example because the application stores and displays some past input, or echoes some text within the current URL.</li></ol>\n<p>Given the above conditions, an attacker can execute CSS injection within the browser of the target user. The attacker can construct a URL that causes the victim's browser to import as CSS a different URL than normal, containing text that the attacker can manipulate.</p>\n<p>Being able to inject arbitrary CSS into the victim's browser may enable various attacks, including:</p>\n<ul>\n  <li>Executing arbitrary JavaScript using IE's expression() function.</li><li>Using CSS selectors to read parts of the HTML source, which may include sensitive data such as anti-CSRF tokens.</li>\n<li>Capturing any sensitive data within the URL query string by making a further style sheet import to a URL on the attacker's domain, and monitoring the incoming Referer header.</li></ul>",
        "remediation": "<p>The root cause of the vulnerability can be resolved by not using path-relative URLs in style sheet imports. Aside from this, attacks can also be prevented by implementing all of the following defensive measures: </p>\n<ul><li>Setting the HTTP response header \"X-Frame-Options: deny\" in all responses. One method that an attacker can use to make a page render in quirks mode is to frame it within their own page that is rendered in quirks mode. Setting this header prevents the page from being framed.</li><li>Setting a modern doctype (e.g. \"&lt;!doctype html&gt;\") in all HTML responses. This prevents the page from being rendered in quirks mode (unless it is being framed, as described above).</li>\n<li>Setting the HTTP response header \"X-Content-Type-Options: nosniff\" in all responses. This prevents the browser from processing a non-CSS response as CSS, even if another page loads the response via a style sheet import.</li></ul>",
        "references": "<ul><li><a href=\"http://blog.portswigger.net/2015/02/prssi.html\">Detecting and exploiting path-relative stylesheet import (PRSSI) vulnerabilities</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097968",
        "name": "Client-side SQL injection (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n\n<p>Client-side SQL injection arises when a script incorporates controllable  data into a client-side SQL query in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will execute an arbitrary SQL query within the local SQL database of the user's browser.</p>\n<p>The potential impact of the vulnerability depends on the application's usage of the SQL database. If the database is used to store sensitive data (such as messages in a social networking application), then the attacker may be able to retrieve this data. If the database is used to store pending user actions (such as outgoing messages in an email application), then the attacker may be able to modify this data and carry out actions on the user's behalf.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based client-side SQL injection vulnerabilities is to use parameterized queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already been defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. In the JavaScript executeSql() API, parameterized items can be designated within the query string using the query character (?), and for each parameterized item, an additional parameter is passed to the API containing the item's value. It is strongly recommended that you parameterize <i>every</i> variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.</p>",
        "references": "<ul>\n<li><a href=\"https://portswigger.net/web-security/sql-injection\">SQL injection</a></li>\n\t</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/89.html\">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097969",
        "name": "Client-side SQL injection (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>Client-side SQL injection arises when a script incorporates controllable  data into a client-side SQL query in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will execute an arbitrary SQL query within the local SQL database of the user's browser.</p>\n<p>The potential impact of the vulnerability depends on the application's usage of the SQL database. If the database is used to store sensitive data (such as messages in a social networking application), then the attacker may be able to retrieve this data. If the database is used to store pending user actions (such as outgoing messages in an email application), then the attacker may be able to modify this data and carry out actions on the user's behalf.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based client-side SQL injection vulnerabilities is to use parameterized queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already been defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. In the JavaScript executeSql() API, parameterized items can be designated within the query string using the query character (?), and for each parameterized item, an additional parameter is passed to the API containing the item's value. It is strongly recommended that you parameterize <i>every</i> variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.</p>",
        "references": "<ul>\n<li><a href=\"https://portswigger.net/web-security/sql-injection\">SQL injection</a></li>\n\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/89.html\">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097970",
        "name": "Client-side SQL injection (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>Client-side SQL injection arises when a script incorporates controllable  data into a client-side SQL query in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will execute an arbitrary SQL query within the local SQL database of the user's browser.</p>\n<p>The potential impact of the vulnerability depends on the application's usage of the SQL database. If the database is used to store sensitive data (such as messages in a social networking application), then the attacker may be able to retrieve this data. If the database is used to store pending user actions (such as outgoing messages in an email application), then the attacker may be able to modify this data and carry out actions on the user's behalf.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based client-side SQL injection vulnerabilities is to use parameterized queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already been defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. In the JavaScript executeSql() API, parameterized items can be designated within the query string using the query character (?), and for each parameterized item, an additional parameter is passed to the API containing the item's value. It is strongly recommended that you parameterize <i>every</i> variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.</p>",
        "references": "<ul>\n<li><a href=\"https://portswigger.net/web-security/sql-injection\">SQL injection</a></li>\n\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/89.html\">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097984",
        "name": "WebSocket hijacking (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n<p>WebSocket hijacking occurs when a  script uses controllable  data as the target URL of a WebSocket connection. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the user's browser to open a WebSocket connection to a URL that is under the attacker's control.</p>\n<p>The potential impact of the vulnerability depends on the application's usage of WebSockets. If the application transmits sensitive data from the user's browser to the WebSocket server, then the attacker may be able to capture this data. If the application reads data from the WebSocket server and performs processing on this data, then the attacker may be able to subvert the application's logic or deliver additional client-side attacks against the user.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based WebSocket hijacking vulnerabilities is not to dynamically set the target URL of a WebSocket connection using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a target of a WebSocket. In general, this is best achieved by using a whitelist of URLs that are permitted WebSocket targets, and strictly validating the target against this list before creating the WebSocket. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/345.html\">CWE-345: Insufficient Verification of Data Authenticity</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/346.html\">CWE-346: Origin Validation Error</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/441.html\">CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097985",
        "name": "WebSocket hijacking (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>WebSocket hijacking occurs when a  script uses controllable  data as the target URL of a WebSocket connection. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the user's browser to open a WebSocket connection to a URL that is under the attacker's control.</p>\n<p>The potential impact of the vulnerability depends on the application's usage of WebSockets. If the application transmits sensitive data from the user's browser to the WebSocket server, then the attacker may be able to capture this data. If the application reads data from the WebSocket server and performs processing on this data, then the attacker may be able to subvert the application's logic or deliver additional client-side attacks against the user.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based WebSocket hijacking vulnerabilities is not to dynamically set the target URL of a WebSocket connection using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a target of a WebSocket. In general, this is best achieved by using a whitelist of URLs that are permitted WebSocket targets, and strictly validating the target against this list before creating the WebSocket. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/345.html\">CWE-345: Insufficient Verification of Data Authenticity</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/346.html\">CWE-346: Origin Validation Error</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/441.html\">CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2097986",
        "name": "WebSocket hijacking (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>WebSocket hijacking occurs when a  script uses controllable  data as the target URL of a WebSocket connection. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the user's browser to open a WebSocket connection to a URL that is under the attacker's control.</p>\n<p>The potential impact of the vulnerability depends on the application's usage of WebSockets. If the application transmits sensitive data from the user's browser to the WebSocket server, then the attacker may be able to capture this data. If the application reads data from the WebSocket server and performs processing on this data, then the attacker may be able to subvert the application's logic or deliver additional client-side attacks against the user.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based WebSocket hijacking vulnerabilities is not to dynamically set the target URL of a WebSocket connection using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a target of a WebSocket. In general, this is best achieved by using a whitelist of URLs that are permitted WebSocket targets, and strictly validating the target against this list before creating the WebSocket. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/345.html\">CWE-345: Insufficient Verification of Data Authenticity</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/346.html\">CWE-346: Origin Validation Error</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/441.html\">CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098000",
        "name": "Local file path manipulation (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n\n<p>Local file path manipulation  arises when a script uses controllable data as the filename parameter to a file handling API. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the user's browser to open an arbitrary local file.</p>\n<p>The potential impact of the vulnerability depends on the application's usage of the opened file. If the application reads data from the file, then the attacker may be able to retrieve this data. If the application writes data to the file, then the attacker may be able to write specific data to a sensitive file, such as an operating system configuration file. In both these cases, the actual exploitability of the potential vulnerability may depend on other suitable functionality being present in the application.</p>\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based local file path manipulation vulnerabilities is not to dynamically pass a filename to a file handling API using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from accessing arbitrary files. In general, this is best achieved by using a whitelist of permitted filenames, and strictly validating the filename against this list before invoking the file handling API. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/22.html\">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/73.html\">CWE-73: External Control of File Name or Path\n</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098001",
        "name": "Local file path manipulation (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>Local file path manipulation  arises when a script uses controllable data as the filename parameter to a file handling API. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the user's browser to open an arbitrary local file.</p>\n<p>The potential impact of the vulnerability depends on the application's usage of the opened file. If the application reads data from the file, then the attacker may be able to retrieve this data. If the application writes data to the file, then the attacker may be able to write specific data to a sensitive file, such as an operating system configuration file. In both these cases, the actual exploitability of the potential vulnerability may depend on other suitable functionality being present in the application.</p>\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based local file path manipulation vulnerabilities is not to dynamically pass a filename to a file handling API using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from accessing arbitrary files. In general, this is best achieved by using a whitelist of permitted filenames, and strictly validating the filename against this list before invoking the file handling API. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/22.html\">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/73.html\">CWE-73: External Control of File Name or Path\n</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098002",
        "name": "Local file path manipulation (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>Local file path manipulation  arises when a script uses controllable data as the filename parameter to a file handling API. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the user's browser to open an arbitrary local file.</p>\n<p>The potential impact of the vulnerability depends on the application's usage of the opened file. If the application reads data from the file, then the attacker may be able to retrieve this data. If the application writes data to the file, then the attacker may be able to write specific data to a sensitive file, such as an operating system configuration file. In both these cases, the actual exploitability of the potential vulnerability may depend on other suitable functionality being present in the application.</p>\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based local file path manipulation vulnerabilities is not to dynamically pass a filename to a file handling API using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from accessing arbitrary files. In general, this is best achieved by using a whitelist of permitted filenames, and strictly validating the filename against this list before invoking the file handling API. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/22.html\">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/73.html\">CWE-73: External Control of File Name or Path\n</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098016",
        "name": "Client-side XPath injection (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n\n<p>DOM-based XPath injection  arises when a script incorporates controllable data into an XPath query. An attacker may be able to use this behavior to construct a URL that, if visited by another application user, will cause an arbitrary XPath query to execute, causing different data to be retrieved and processed by the application. Depending on the purpose for which the query results are used, it may be possible to subvert the application's logic, or cause unintended actions on behalf of the user.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based XPath injection vulnerabilities is not to incorporate into an XPath query any data that originated from an untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from modifying the XPath query in inappropriate ways. This may involve strict validation of specific items to ensure they do not contain any characters that may interfere with the structure of the query when it is parsed. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098017",
        "name": "Client-side XPath injection (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>DOM-based XPath injection  arises when a script incorporates controllable data into an XPath query. An attacker may be able to use this behavior to construct a URL that, if visited by another application user, will cause an arbitrary XPath query to execute, causing different data to be retrieved and processed by the application. Depending on the purpose for which the query results are used, it may be possible to subvert the application's logic, or cause unintended actions on behalf of the user.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based XPath injection vulnerabilities is not to incorporate into an XPath query any data that originated from an untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from modifying the XPath query in inappropriate ways. This may involve strict validation of specific items to ensure they do not contain any characters that may interfere with the structure of the query when it is parsed. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/79.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098018",
        "name": "Client-side XPath injection (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>DOM-based XPath injection  arises when a script incorporates controllable data into an XPath query. An attacker may be able to use this behavior to construct a URL that, if visited by another application user, will cause an arbitrary XPath query to execute, causing different data to be retrieved and processed by the application. Depending on the purpose for which the query results are used, it may be possible to subvert the application's logic, or cause unintended actions on behalf of the user.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based XPath injection vulnerabilities is not to incorporate into an XPath query any data that originated from an untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from modifying the XPath query in inappropriate ways. This may involve strict validation of specific items to ensure they do not contain any characters that may interfere with the structure of the query when it is parsed. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/79.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098032",
        "name": "Client-side JSON injection (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n<p>DOM-based JSON injection  arises when a script  incorporates controllable data into a string that is parsed as a JSON data structure and then processed by the application. An attacker may be able to use this behavior to construct a URL that, if visited by another application user, will cause arbitrary JSON data to be processed. Depending on the purpose for which this data is used, it may be possible to subvert the application's logic, or cause unintended actions on behalf of the user.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based JSON injection vulnerabilities is not to parse as JSON any string containing data that originated from an untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from modifying the JSON structure in inappropriate ways. This may involve strict validation of specific items to ensure they do not contain any characters that may interfere with the structure of the JSON when it is parsed.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/79.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098033",
        "name": "Client-side JSON injection (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>DOM-based JSON injection  arises when a script  incorporates controllable data into a string that is parsed as a JSON data structure and then processed by the application. An attacker may be able to use this behavior to construct a URL that, if visited by another application user, will cause arbitrary JSON data to be processed. Depending on the purpose for which this data is used, it may be possible to subvert the application's logic, or cause unintended actions on behalf of the user.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based JSON injection vulnerabilities is not to parse as JSON any string containing data that originated from an untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from modifying the JSON structure in inappropriate ways. This may involve strict validation of specific items to ensure they do not contain any characters that may interfere with the structure of the JSON when it is parsed.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/79.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098034",
        "name": "Client-side JSON injection (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>DOM-based JSON injection  arises when a script  incorporates controllable data into a string that is parsed as a JSON data structure and then processed by the application. An attacker may be able to use this behavior to construct a URL that, if visited by another application user, will cause arbitrary JSON data to be processed. Depending on the purpose for which this data is used, it may be possible to subvert the application's logic, or cause unintended actions on behalf of the user.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based JSON injection vulnerabilities is not to parse as JSON any string containing data that originated from an untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from modifying the JSON structure in inappropriate ways. This may involve strict validation of specific items to ensure they do not contain any characters that may interfere with the structure of the JSON when it is parsed.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/79.html\">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098176",
        "name": "Flash cross-domain policy",
        "description": "<p>The Flash cross-domain policy controls whether Flash client components running on other domains can perform two-way interaction with the domain that publishes the policy. If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially gain full access to the application within the security context of the logged in user.</p>\n<p>Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by a third-party attacker to exploit the trust relationship and attack the application that allows access. Any domains that are allowed by the Flash cross-domain policy should be reviewed to determine whether it is appropriate for the application to fully trust both their intentions and security posture. </p>",
        "remediation": "<p>Any inappropriate entries in the Flash cross-domain policy file should be removed.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/942.html\">CWE-942: Overly Permissive Cross-domain Whitelist</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098432",
        "name": "Silverlight cross-domain policy",
        "description": "<p>The Silverlight cross-domain policy controls whether Silverlight client components running on other domains can perform two-way interaction with the domain that publishes the policy. If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially gain full access to the application within the security context of the logged in user.</p>\n<p>Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by a third-party attacker to exploit the trust relationship and attack the application that allows access. Any domains that are allowed by the Silverlight cross-domain policy should be reviewed to determine whether it is appropriate for the application to fully trust both their intentions and security posture. </p>",
        "remediation": "<p>Any inappropriate entries in the Silverlight cross-domain policy file should be removed.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/942.html\">CWE-942: Overly Permissive Cross-domain Whitelist</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098688",
        "name": "Cross-origin resource sharing",
        "description": "<p>An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.</p><p>If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged in user.</p>\n<p>Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by an attacker to exploit the trust relationship and attack the application that allows access. CORS policies on pages containing sensitive information should be reviewed to determine whether it is appropriate for the application to trust both the intentions and security posture of any domains granted access.</p>",
        "remediation": "<p>Any inappropriate domains should be removed from the CORS policy.</p>",
        "references": "<ul>\n  <li> <a href=\"http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html\">Exploiting CORS Misconfigurations</a> </li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/942.html\">CWE-942: Overly Permissive Cross-domain Whitelist</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098689",
        "name": "Cross-origin resource sharing: arbitrary origin trusted",
        "description": "<p>An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.</p><p>\nTrusting arbitrary origins effectively disables the same-origin policy, allowing two-way interaction by third-party web sites. Unless the response consists only of unprotected public content, this policy is likely to present a security risk.</p>\n<p>If the site  specifies the header Access-Control-Allow-Credentials: true, third-party sites may be able to carry out privileged actions and retrieve sensitive information. Even if it does not, attackers may be able to  bypass any IP-based access controls by proxying through users'  browsers.</p>",
        "remediation": "<p>Rather than using a wildcard or programmatically verifying supplied origins, use a whitelist of trusted domains.</p>",
        "references": "<ul>\n  <li> <a href=\"http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html\">Exploiting CORS Misconfigurations</a> </li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/942.html\">CWE-942: Overly Permissive Cross-domain Whitelist</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098690",
        "name": "Cross-origin resource sharing: unencrypted origin trusted",
        "description": "<p>An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.</p>\n<p>If a site allows interaction from an origin that uses unencrypted HTTP communications, then it is vulnerable to an attacker who is in a position to view and modify a user's unencrypted network traffic. The attacker can control the responses from unencrypted origins, thereby injecting content that is able to interact with the application that publishes the policy. This means that the application is effectively extending trust to all such attackers, thereby undoing much of the benefit of using HTTPS communications. </p>",
        "remediation": "<p>Only trust origins that use encrypted HTTPS communications.</p>",
        "references": "<ul>\n  <li> <a href=\"http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html\">Exploiting CORS Misconfigurations</a> </li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/942.html\">CWE-942: Overly Permissive Cross-domain Whitelist</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098691",
        "name": "Cross-origin resource sharing: all subdomains trusted",
        "description": "<p>An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.</p>\n<p>If an application allows interaction from all subdomains, then this significantly increases its attack surface. For example, a cross-site scripting (XSS) vulnerability in any subdomain could potentially compromise the application that publishes the policy. Some consumer ISPs return custom content when requests are made to unregistered subdomains, which can introduce XSS vulnerabilities even if all of an organization's own applications are secure.</p>",
        "remediation": "<p>Rather than trusting all subdomains,  use a whitelisted of trusted subdomains.</p>",
        "references": "<ul><li>\n<a href=\"http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html\">Exploiting CORS Misconfigurations</a>\n</li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/942.html\">CWE-942: Overly Permissive Cross-domain Whitelist</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2098944",
        "name": "Cross-site request forgery",
        "description": "<p>Cross-site request forgery (CSRF) vulnerabilities may arise when applications rely solely on HTTP cookies to identify the user that has issued a particular request. Because browsers automatically add cookies to requests regardless of their origin, it may be possible for an attacker to create a malicious web site that forges a cross-domain request to the vulnerable application. For a request to be vulnerable to CSRF, the following conditions must hold:</p>\n<ul>\n<li>The request can be issued cross-domain, for example using an HTML form. If the request contains non-standard headers or body content, then it may only be issuable from a page that originated on the same domain.</li>\n<li>The application relies solely on HTTP cookies or Basic Authentication to identify the user that issued the request. If the application places session-related tokens elsewhere within the request, then it may not be vulnerable.</li>\n<li>The request performs some privileged action within the application, which modifies the application's state based on the identity of the issuing user.</li><li>The attacker can determine all the parameters required to construct a request that performs the action. If the request contains any values that the attacker cannot determine or predict, then it is not vulnerable.</li></ul>",
        "remediation": "<p>The most effective way to protect against CSRF vulnerabilities is to include within relevant requests an additional token that is not transmitted in a cookie: for example, a parameter in a hidden form field. This additional token should contain sufficient entropy, and be generated using a cryptographic random number generator, such that it is not feasible for an attacker to determine or predict the value of any token that was issued to another user. The token should be associated with the user's session, and the application should validate that the correct token is received before performing any action resulting from the request.</p>\n<p>An alternative approach, which may be easier to implement, is to validate that Host and Referer headers in relevant requests are both present and contain the same domain name. However, this approach is somewhat less robust: historically, quirks in browsers and plugins have often enabled attackers to forge cross-domain requests that manipulate these headers to bypass such defenses. </p>",
        "references": "<ul>\n<li><a href=\"https://support.portswigger.net/customer/portal/articles/1965674-using-burp-to-test-for-cross-site-request-forgery-csrf-\">Using Burp to Test for Cross-Site Request Forgery</a></li>\n<li><a href=\"https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf\">The Deputies Are Still Confused</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/352.html\">CWE-352: Cross-Site Request Forgery (CSRF)</a></li>\n</ul>"
    },
    {
        "issue_type_id": "2099200",
        "name": "SMTP header injection",
        "description": "<p>SMTP header injection vulnerabilities arise when user input is placed into email headers without adequate sanitization, allowing an attacker to inject additional headers with arbitrary values. This behavior can be exploited to send copies of emails to third parties, attach viruses, deliver phishing attacks, and often alter the content of emails. It is typically exploited by spammers looking to leverage the vulnerable company's reputation to add legitimacy to their emails.\n</p>\n<p>\nThis issue is particularly serious if the email contains sensitive information not intended for the attacker, such as a password reset token.\n</p>",
        "remediation": "<p>Validate that user input conforms to a whitelist of safe characters before placing it into email headers. In particular, input containing newlines and carriage returns should be rejected.\nAlternatively, consider switching to an email library that automatically prevents such attacks.\n</p>",
        "references": "<ul>\n  <li><a href=\"http://blog.portswigger.net/2015/04/introducing-burp-collaborator.html\">Burp Collaborator</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/93.html\">CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/159.html\">CWE-159: Failure to Sanitize Special Element</a></li>\n</ul>"
    },
    {
        "issue_type_id": "3145984",
        "name": "Cleartext submission of password",
        "description": "<p>Some applications transmit passwords over unencrypted connections, making them vulnerable to interception. To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.</p>\n<p>Vulnerabilities that result in the disclosure of users' passwords can result in compromises that are extremely difficult to investigate due to obscured audit trails. Even if the application itself only handles non-sensitive information, exposing passwords puts users who have re-used their password elsewhere at risk.</p>",
        "remediation": "<p>Applications should use transport-level encryption (SSL or TLS) to protect all sensitive communications passing between the client and the server. Communications that should be protected include the login mechanism and related functionality, and any functions where sensitive data can be accessed or privileged actions can be performed. These areas should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications. If HTTP cookies are used for transmitting session tokens, then the secure flag should be set to prevent transmission over clear-text HTTP.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/319.html\">CWE-319: Cleartext Transmission of Sensitive Information</a></li>\n</ul>"
    },
    {
        "issue_type_id": "3146240",
        "name": "External service interaction (DNS)",
        "description": "<p>External service interaction arises when it is possible to induce an application to interact with an arbitrary external service, such as a web or mail server. The ability to trigger arbitrary external service interactions does not constitute a vulnerability in its own right, and in some cases might even be the intended behavior of the application. \nHowever, in many cases, it can indicate a vulnerability with serious consequences.</p>\n<p>In cases where DNS-based interactions can be triggered, it is normally possible to trigger interactions using other service types, and these are reported as separate issues. \n  If a payload that specifies a particular service type (e.g. a URL) triggers only a DNS-based interaction, \n  then this strongly indicates that the application attempted to connect using that other service, \n  but was prevented from doing so by egress filters in place at the network layer. The ability to send requests to other systems can allow the vulnerable server to be used as an attack proxy. \n  By submitting suitable payloads, an attacker can cause the application server to attack other systems that it can interact with. \n  This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. \n  Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers. </p>",
        "remediation": "<p>You should review the purpose and intended use of the relevant application functionality, \n  and determine whether the ability to trigger arbitrary external service interactions is intended behavior. \n  If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. \n  These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter.</p>\n<p>If the ability to trigger arbitrary external service interactions is not intended behavior, then you should implement a whitelist of permitted services and hosts, and block any interactions that do not appear on this whitelist.</p>",
        "references": "<ul>\n  <li><a href=\"http://blog.portswigger.net/2015/04/introducing-burp-collaborator.html\">Burp Collaborator</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/918.html\">CWE-918: Server-Side Request Forgery (SSRF)</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/406.html\">CWE-406: Insufficient Control of Network Message Volume (Network Amplification)</a></li>\n</ul>"
    },
    {
        "issue_type_id": "3146256",
        "name": "External service interaction (HTTP)",
        "description": "<p>External service interaction arises when it is possible to induce an application to interact with an arbitrary external service, such as a web or mail server. The ability to trigger arbitrary external service interactions does not constitute a vulnerability in its own right, and in some cases might even be the intended behavior of the application. \nHowever, in many cases, it can indicate a vulnerability with serious consequences.</p>\n<p>The ability to send requests to other systems can allow the vulnerable server to be used as an attack proxy. \n  By submitting suitable payloads, an attacker can cause the application server to attack other systems that it can interact with. \n  This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. \n  Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers. </p>",
        "remediation": "<p>You should review the purpose and intended use of the relevant application functionality, \n  and determine whether the ability to trigger arbitrary external service interactions is intended behavior. \n  If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. \n  These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter.</p>\n<p>If the ability to trigger arbitrary external service interactions is not intended behavior, then you should implement a whitelist of permitted services and hosts, and block any interactions that do not appear on this whitelist.</p>",
        "references": "<ul>\n  <li><a href=\"http://blog.portswigger.net/2015/04/introducing-burp-collaborator.html\">Burp Collaborator</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/918.html\">CWE-918: Server-Side Request Forgery (SSRF)</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/406.html\">CWE-406: Insufficient Control of Network Message Volume (Network Amplification)</a></li>\n</ul>"
    },
    {
        "issue_type_id": "3146272",
        "name": "External service interaction (SMTP)",
        "description": "<p>External service interaction arises when it is possible to induce an application to interact with an arbitrary external service, such as a web or mail server. The ability to trigger arbitrary external service interactions does not constitute a vulnerability in its own right, and in some cases might even be the intended behavior of the application. \nHowever, in many cases, it can indicate a vulnerability with serious consequences.</p>\n<p>The ability to send requests to other systems can allow the vulnerable server to be used as an attack proxy. \n  By submitting suitable payloads, an attacker can cause the application server to attack other systems that it can interact with. \n  This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. \n  Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers. </p>\n<p>The facility to generate an email to an arbitrary address is often intended application behavior. But this is not necessarily the case, particulary in cases where the destination address is not explicitly entered on-screen by the user.</p>",
        "remediation": "<p>You should review the purpose and intended use of the relevant application functionality, \n  and determine whether the ability to trigger arbitrary external service interactions is intended behavior. \n  If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. \n  These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter.</p>\n<p>If the ability to trigger arbitrary external service interactions is not intended behavior, then you should implement a whitelist of permitted services and hosts, and block any interactions that do not appear on this whitelist.</p>",
        "references": "<ul>\n  <li><a href=\"http://blog.portswigger.net/2015/04/introducing-burp-collaborator.html\">Burp Collaborator</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/406.html\">CWE-406: Insufficient Control of Network Message Volume (Network Amplification)</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4194560",
        "name": "Referer-dependent response",
        "description": "<p>Application responses may depend systematically on the presence or absence of the Referer header in requests. This behavior does not necessarily constitute a security vulnerability, and you should investigate the nature of and reason for the differential responses to determine whether a vulnerability is present.</p>\n<p>Common explanations for Referer-dependent responses include: </p>\n<ul><li>Referer-based access controls, where the application assumes that if you have arrived from one privileged location then you are authorized to access another privileged location. These controls can be trivially defeated by supplying an accepted Referer header in requests for the vulnerable function.</li><li>Attempts to prevent cross-site request forgery attacks by verifying that requests to perform privileged actions originated from within the application itself and not from some external location. Such defenses are often not robust, and can be bypassed by removing the Referer header entirely.</li>\n<li>Delivery of Referer-tailored content, such as welcome messages to visitors from specific domains, search-engine optimization (SEO) techniques, and other ways of tailoring the user's experience. Such behaviors often have no security impact; however, unsafe processing of the Referer header may introduce vulnerabilities such as SQL injection and cross-site scripting. If parts of the document (such as META keywords) are updated based on search engine queries contained in the Referer header, then the application may be vulnerable to persistent code injection attacks, in which search terms are manipulated to cause malicious content to appear in responses served to other application users.</li></ul>",
        "remediation": "<p>The Referer header is not a robust foundation on which to build access controls. Any such measures should be replaced with more secure alternatives that are not vulnerable to Referer spoofing.</p>\n<p>If the contents of responses is updated based on Referer data, then the same defenses against malicious input should be employed here as for any other kinds of user-supplied data. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/213.html\">CWE-213: Intentional Information Exposure</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4194576",
        "name": "Spoofable client IP address",
        "description": "<p>\nIf an application trusts an HTTP request header like X-Forwarded-For to accurately specify the remote IP address of the connecting client, then malicious clients can spoof their IP address. This behavior does not necessarily constitute a security vulnerability, however some applications use client IP addresses to enforce access controls and rate limits. For example, an application might expose administrative functionality only to clients connecting from the local IP address of the server, or allow a certain number of failed login attempts from each unique IP address.\nConsider reviewing relevant functionality to determine whether this might be the case. </p>",
        "remediation": "<p>HTTP request headers such as X-Forwarded-For, True-Client-IP, and X-Real-IP are not a robust foundation on which to build any security measures, such as access controls. Any such measures should be replaced with more secure alternatives that are not vulnerable to spoofing.</p>\n<p>If the platform application server returns incorrect information about the client's IP address due to the presence of any particular HTTP request header, then the server may need to be reconfigured, or an alternative method of identifying clients should be used. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4194592",
        "name": "User agent-dependent response",
        "description": "<p>Application responses may depend systematically on the value of the User-Agent header in requests. This behavior does not itself constitute a security vulnerability, but may point towards additional attack surface within the application, which may contain vulnerabilities.</p>\n<p>This behavior often arises because applications provide different user interfaces for desktop and mobile users. Mobile interfaces have often been less thoroughly tested for vulnerabilities such as cross-site scripting, and often have simpler authentication and session handling mechanisms that may contain problems that are not present in the full interface.</p>\n<p>To review the interface provided by the alternate User-Agent header, you can configure a match/replace rule in Burp Proxy to modify the User-Agent header in all requests, and then browse the application in the normal way using your normal browser. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4194816",
        "name": "Password returned in later response",
        "description": "<p>Some applications return passwords submitted to the application in clear form in later responses. This behavior increases the risk that users' passwords will be captured by an attacker. Many types of vulnerability, such as weaknesses in session handling, broken access controls, and cross-site scripting, could enable an attacker to leverage this behavior to retrieve the passwords of other application users. This possibility typically exacerbates the impact of those other vulnerabilities, and in some situations can enable an attacker to quickly compromise the entire application.</p>\n<p>Vulnerabilities that result in the disclosure of users' passwords can result in compromises that are extremely difficult to investigate due to obscured audit trails. Even if the application itself only handles non-sensitive information, exposing passwords puts users who have re-used their password elsewhere at risk.</p>",
        "remediation": "<p>There is usually no good reason for an application to return users' passwords in its responses. If user impersonation is a business requirement this would be better implemented as a custom function with associated logging.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/204.html\">CWE-204: Response Discrepancy Information Exposure</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4195072",
        "name": "Password submitted using GET method",
        "description": "<p>Some applications use the GET method to submit passwords, which are transmitted within the query string of the requested URL. Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing passwords into the URL increases the risk that they will be captured by an attacker.</p>\n<p>Vulnerabilities that result in the disclosure of users' passwords can result in compromises that are extremely difficult to investigate due to obscured audit trails. Even if the application itself only handles non-sensitive information, exposing passwords puts users who have re-used their password elsewhere at risk.</p>",
        "remediation": "<p>All forms submitting passwords should use the POST method. To achieve this, applications should specify the method attribute of the FORM tag as <b>method=\"POST\"</b>. It may also be necessary to modify the corresponding server-side form handler to ensure that submitted passwords are properly retrieved from the message body, rather than the URL.\n</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/598.html\">CWE-598: Information Exposure Through Query Strings in GET Request</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4195328",
        "name": "Password returned in URL query string",
        "description": "<p>The application responds to login submissions with a link containing the user's password within the URL query string. Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing passwords into the URL increases the risk that they will be captured by an attacker.</p>\n<p>Vulnerabilities that result in the disclosure of users' passwords can result in compromises that are extremely difficult to investigate due to obscured audit trails. Even if the application itself only handles non-sensitive information, exposing passwords puts users who have re-used their password elsewhere at risk.</p>",
        "remediation": "<p>The application should never transmit any sensitive information within the URL query string. There is no good reason for a login mechanism to echo passwords back to the user, and the mechanism should be modified to remove this behavior.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/598.html\">CWE-598: Information Exposure Through Query Strings in GET Request</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4195456",
        "name": "SQL statement in request parameter",
        "description": "<p>HTTP requests sometimes contain SQL syntax. If this is incorporated into a SQL query and executed by the server, then the application is almost certainly vulnerable to SQL injection.</p>\n<p>When SQL-like syntax is observed, you should verify whether the request contains a genuine SQL query and whether this is being executed by the server. </p>",
        "remediation": "<p>Applications should not incorporate any user-controllable data directly into SQL queries. Parameterized queries (also known as prepared statements) should be used to safely insert data into predefined queries. In no circumstances should users be able to control or modify the structure of the SQL query itself.</p>",
        "references": "<ul>\n<li><a href=\"https://portswigger.net/web-security/sql-injection\">SQL injection</a></li>\n\t\n<li><a href=\"https://support.portswigger.net/customer/portal/articles/1965677-using-burp-to-test-for-injection-flaws\">Using Burp to Test for Injection Flaws</a></li>\n<li><a href=\"https://portswigger.net/web-security/sql-injection/cheat-sheet\">SQL Injection Cheat Sheet</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/598.html\">CWE-598: Information Exposure Through Query Strings in GET Request</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4195584",
        "name": "Cross-domain POST",
        "description": "<p>Applications sometimes use POST requests to transfer sensitive information from one domain to another. This does not necessarily constitute a security vulnerability, but it creates a trust relationship between the two domains. Data transmitted between domains should be reviewed to determine whether the originating application should be trusting the receiving domain with this information.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4195840",
        "name": "ASP.NET ViewState without MAC enabled",
        "description": "<p>The ViewState is a mechanism built in to the ASP.NET platform for persisting elements of the user interface and other data across successive requests. The data to be persisted is serialized by the server and transmitted via a hidden form field. When it is posted back to the server, the ViewState parameter is deserialized and the data is retrieved.</p>\n<p>By default, the serialized value is signed by the server to prevent tampering by the user; however, this behavior can be disabled by setting the Page.EnableViewStateMac property to false. If this is done, then an attacker can modify the contents of the ViewState and cause arbitrary data to be deserialized and processed by the server. If the ViewState contains any items that are critical to the server's processing of the request, then this may result in a security exposure.</p>\n<p>The contents of the deserialized ViewState should be reviewed to determine whether it contains any critical items that can be manipulated to attack the application. </p>",
        "remediation": "<p>There is no good reason to disable the default ASP.NET behavior in which the ViewState is signed to prevent tampering. To ensure that this occurs, you should set the Page.EnableViewStateMac property to true on any pages where the ViewState is not currently signed.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/642.html\">CWE-642: External Control of Critical State Data</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4196096",
        "name": "XML entity expansion",
        "description": "<p>XML entity expansion vulnerabilities arise because the XML specification allows XML documents to define entities that reference other entities defined within the document. If this is done recursively to a significant depth, then the XML parser will consume exponentially increasing amounts of memory and processor resources as each level of recursion is processed. This might result in a denial-of-service condition, causing the entire application to stop functioning.</p>\n<p><b>Note:</b> To avoid causing an actual denial-of-service, Burp Suite merely verifies that entities are being recursively expanded to a modest depth. It is possible that reported applications are not actually vulnerable because they are designed to prevent entity expansion beyond a given depth.\n</p>",
        "remediation": "<p>XML entity expansion makes use of the DOCTYPE tag to define the injected entities. XML parsers can usually be configured to disable support for this tag. You should consult the documentation for your XML parsing library to determine how to disable this feature.</p>\n<p>It may also be possible to use input validation to block input containing a DOCTYPE tag. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/776.html\">CWE-776: Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4196352",
        "name": "Long redirection response",
        "description": "<p>The application returned a redirection response containing a \"long\" message body. Ordinarily, this content is not displayed to the user, because the browser automatically follows the redirection.</p>\n<p>Occasionally, redirection responses contain sensitive data. For example, if the user requests a page that they are not authorized to view, then an application might issue a redirection to a different page, but also include the contents of the prohibited page.</p>\n<p>You should review the contents of the response to determine whether it contains anything sensitive. </p>",
        "remediation": "<p>In cases where the application handles requests for unauthorized content by redirecting to a different URL, the application should ensure that no sensitive content is included within the redirection response. Depending on the application and the platform, this might involve checking for proper authorization earlier in the request handling logic, or using a different API to perform the redirection.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/698.html\">CWE-698: Execution After Redirect (EAR)</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4196608",
        "name": "Serialized object in HTTP message",
        "description": "<p>Applications may submit a serialized object in a request parameter. This behavior can expose the application in various ways, including:</p>\n<ul>\n<li>Any sensitive data contained within the object can be viewed by the user.</li><li>An attacker may be able to interfere with server-side logic by tampering with the contents of the object and re-serializing it.</li><li>An attacker may be able to cause unauthorized code execution on the server, by controlling the server-side function that is invoked when the object is processed.</li></ul>\n<p>Actual exploitation of any code execution vulnerabilities arising from the application's use of serialized objects will typically require the attacker to have access to the source code of the server-side application. This may mitigate the practical impact of this issue in many situations. However, it is still highly recommended to fix the underlying vulnerability. Vulnerabilities in native deserialization functions often allow practical exploitation without source code access.</p>",
        "remediation": "<p>The best way to avoid vulnerabilities that arise from the use of serialized objects is not to pass these in request parameters, or expose them in any other way to the client. Generally, it is possible to transmit application data in plain non-serialized form, and handle it with the same precautions that apply to all client-submitted data. If it is considered unavoidable to place serialized objects into request parameters, then it may be possible to prevent attacks by also placing a server-generated cryptographic signature of the object into the same request, and validating the signature before performing deserialization or other processing on the object.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/502.html\">CWE-502: Deserialization of Untrusted Data</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4196864",
        "name": "Duplicate cookies set",
        "description": "<p>The response contains two or more Set-Cookie headers that attempt to set the same cookie to different values. Browsers will only accept one of these values, typically the value in the last header. The presence of the duplicate headers may indicate a programming error.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4197120",
        "name": "Input returned in response (stored)",
        "description": "<p>Retrieval of stored input arises when user input is stored and later embedded into the application's responses. </p><p>Input being returned in application responses is not a vulnerability in its own right. However, it is a prerequisite for many client-side vulnerabilities, including cross-site scripting, open redirection, content spoofing, and response header injection. Additionally, some server-side vulnerabilities such as SQL injection are often easier to identify and exploit when input is returned in responses. In applications where input retrieval is rare and the environment is resistant to automated testing (for example, due to a web application firewall), it might be worth subjecting instances of it to focused manual testing. </p>\n\n<p>Vulnerabilities resulting from retrieval of stored input  are typically more serious than the equivalent reflected vulnerabilities because they do not require a separate delivery mechanism in order to reach target users. Depending on the affected functionality, ordinary users may be exploited during normal use of the application. Note that automated detection of stored data retrieval cannot reliably determine whether input that is persisted within the application can be retrieved by any other user, only by authenticated users, or only by the attacker themselves. You should review the functionality in which the vulnerability appears to determine whether the application's behavior can feasibly be used to compromise other application users. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4197376",
        "name": "Input returned in response (reflected)",
        "description": "<p>Reflection of input arises when data is copied from a request and echoed into the application's immediate response.</p><p>Input being returned in application responses is not a vulnerability in its own right. However, it is a prerequisite for many client-side vulnerabilities, including cross-site scripting, open redirection, content spoofing, and response header injection. Additionally, some server-side vulnerabilities such as SQL injection are often easier to identify and exploit when input is returned in responses. In applications where input retrieval is rare and the environment is resistant to automated testing (for example, due to a web application firewall), it might be worth subjecting instances of it to focused manual testing. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4197632",
        "name": "Suspicious input transformation (reflected)",
        "description": "<p>Suspicious input transformation arises when an application receives user input, transforms it in some way, and then performs further processing on the result. The types of transformations that can lead to problems include decoding common formats, such as UTF-8 and URL-encoding, or processing of escape sequences, such as backslash escaping. </p>\n<p>Performing these input transformations does not constitute a vulnerability in its own right, but might lead to problems in conjunction with other application behaviors. An attacker might be able to bypass input filters by suitably encoding their payloads, if the input is decoded after the input filters have been applied. Or an attacker might be able to interfere with other data that is concatenated onto their input, by finishing their input with the start of a multi-character encoding or escape sequence, the transformation of which will consume the start of the following data.</p>",
        "remediation": "<p>Review the transformation that is being applied, to understand whether this is intended and desirable behavior given the nature of the application functionality, and whether it gives rise to any vulnerabilities in relation to  bypassing of input filters or character consumption.</p>",
        "references": "<ul>\n<li><a href=\"http://blog.portswigger.net/2016/11/backslash-powered-scanning-hunting.html\">Backslash Powered Scanning: Hunting Unknown Vulnerability Classes</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4197888",
        "name": "Suspicious input transformation (stored)",
        "description": "<p>Suspicious input transformation arises when an application receives user input, transforms it in some way, and then performs further processing on the result. The types of transformations that can lead to problems include decoding common formats, such as UTF-8 and URL-encoding, or processing of escape sequences, such as backslash escaping. </p>\n<p>Performing these input transformations does not constitute a vulnerability in its own right, but might lead to problems in conjunction with other application behaviors. An attacker might be able to bypass input filters by suitably encoding their payloads, if the input is decoded after the input filters have been applied. Or an attacker might be able to interfere with other data that is concatenated onto their input, by finishing their input with the start of a multi-character encoding or escape sequence, the transformation of which will consume the start of the following data.</p>\n\n<p>Stored suspicious input transformation arises when the transformed input is stored and later embedded into the application's responses.</p>",
        "remediation": "<p>Review the transformation that is being applied, to understand whether this is intended and desirable behavior given the nature of the application functionality, and whether it gives rise to any vulnerabilities in relation to  bypassing of input filters or character consumption.</p>",
        "references": "<ul>\n<li><a href=\"http://blog.portswigger.net/2016/11/backslash-powered-scanning-hunting.html\">Backslash Powered Scanning: Hunting Unknown Vulnerability Classes</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "4198144",
        "name": "Request URL override",
        "description": "<p>Some applications and frameworks support HTTP headers that can be used to override parts of the request URL, potentially affecting the routing and processing of the request.</p>\n<p>Intermediate systems are often oblivious to these headers. In the case of reverse proxies and web application firewalls, this can lead to security rulesets being bypassed. If a caching system is in place, this may enable cache poisoning attacks. These headers may also enable forging of log entries. </p>\n<p>Even if the application is intended to be accessed directly, some visitors may be using a corporate proxy enabling localised cache poisoning. </p>",
        "remediation": "<p>\n    To fully resolve this issue, locate the component that processes the affected headers, and disable it entirely. If you are using a framework, applying any pending security updates may do this for you.\n</p>\n<p>\n    If this isn't practical, an alternative workaround is to configure an intermediate system to automatically strip the affected headers before they are processed.\n</p>",
        "references": "<ul>\n    <li><a href=\"https://portswigger.net/blog/practical-web-cache-poisoning\">Practical Web Cache Poisoning</a></li></ul>",
        "vulnerability_classifications": "<ul>\n    <li><a href=\"https://cwe.mitre.org/data/definitions/436.html\">CWE-436: Interpretation Conflict</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5243136",
        "name": "Open redirection (reflected)",
        "description": "<p>Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application that causes a redirection to an arbitrary external domain. This behavior can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain and with a valid SSL certificate (if SSL is used), lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.</p>",
        "remediation": "<p>If possible, applications should avoid incorporating user-controllable data into redirection targets. In many cases, this behavior can be avoided in two ways:</p>\n<ul>\n  <li>Remove the redirection function from the application, and replace links to it with direct links to the relevant target URLs.</li>\n  <li>Maintain a server-side list of all URLs that are permitted for redirection. Instead of passing the target URL as a parameter to the redirector, pass an index into this list.</li>\n</ul>\n<p>If it is considered unavoidable for the redirection function to receive user-controllable input and incorporate this into the redirection target, one of the following measures should be used to minimize the risk of redirection attacks:</p>\n<ul>\n  <li>The application should use relative URLs in all of its redirects, and the redirection function should strictly validate that the URL received is a relative URL.</li>\n  <li>The application should use URLs relative to the web root for all of its redirects, and the redirection function should validate that the URL received starts with a slash character. It should then prepend http://yourdomainname.com to the URL before issuing the redirect.</li>\n  <li>The application should use absolute URLs for all of its redirects, and the redirection function should verify that the user-supplied URL begins with http://yourdomainname.com/ before issuing the redirect.</li>\n</ul>",
        "references": "<ul>\n  <li><a href=\"https://support.portswigger.net/customer/portal/articles/1965733-Methodology_Testing%20for%20Open%20Redirections.html\">Using Burp to Test for Open Redirections</a></li>\n  <li><a href=\"https://www.owasp.org/images/b/b9/OWASP_Appsec_Research_2010_Redirects_XSLJ_by_Sirdarckcat_and_Thornmaker.pdf\">Fun With Redirects</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/601.html\">CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5243137",
        "name": "Open redirection (stored)",
        "description": "<p>Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application that causes a redirection to an arbitrary external domain. This behavior can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain and with a valid SSL certificate (if SSL is used), lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.</p>",
        "remediation": "<p>If possible, applications should avoid incorporating user-controllable data into redirection targets. In many cases, this behavior can be avoided in two ways:</p>\n<ul>\n  <li>Remove the redirection function from the application, and replace links to it with direct links to the relevant target URLs.</li>\n  <li>Maintain a server-side list of all URLs that are permitted for redirection. Instead of passing the target URL as a parameter to the redirector, pass an index into this list.</li>\n</ul>\n<p>If it is considered unavoidable for the redirection function to receive user-controllable input and incorporate this into the redirection target, one of the following measures should be used to minimize the risk of redirection attacks:</p>\n<ul>\n  <li>The application should use relative URLs in all of its redirects, and the redirection function should strictly validate that the URL received is a relative URL.</li>\n  <li>The application should use URLs relative to the web root for all of its redirects, and the redirection function should validate that the URL received starts with a slash character. It should then prepend http://yourdomainname.com to the URL before issuing the redirect.</li>\n  <li>The application should use absolute URLs for all of its redirects, and the redirection function should verify that the user-supplied URL begins with http://yourdomainname.com/ before issuing the redirect.</li>\n</ul>\n\n<p>Stored open redirection vulnerabilities arise when the applicable input was submitted in an previous request and stored by the application. This is often more serious than reflected open redirection because an attacker might be able to place persistent input into the application which, when viewed by other users, causes their browser to invisibly redirect to a domain of the attacker's choice.</p>",
        "references": "<ul>\n  <li><a href=\"https://support.portswigger.net/customer/portal/articles/1965733-Methodology_Testing%20for%20Open%20Redirections.html\">Using Burp to Test for Open Redirections</a></li>\n  <li><a href=\"https://www.owasp.org/images/b/b9/OWASP_Appsec_Research_2010_Redirects_XSLJ_by_Sirdarckcat_and_Thornmaker.pdf\">Fun With Redirects</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/601.html\">CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5243152",
        "name": "Open redirection (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n\n<p>DOM-based open redirection arises when a script  writes controllable data into the target of a redirection in an unsafe way. An attacker may be able to use the vulnerability to  construct a URL that, if visited by another application user, will cause a redirection to an arbitrary external domain. This behavior can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain and with a valid SSL certificate (if SSL is used), lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.</p>\n<p><b>Note:</b> If an attacker is able to control the start of the string that is passed to the redirection API, then it may be possible to escalate this vulnerability into a JavaScript injection attack, by using a URL with the javascript: pseudo-protocol to execute arbitrary script code when the URL is processed by the browser.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based open redirection vulnerabilities is not to dynamically set redirection targets using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a redirection target. In general, this is best achieved by using a whitelist of URLs that are permitted redirection targets, and strictly validating the target against this list before performing the redirection.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/601.html\">CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5243153",
        "name": "Open redirection (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>DOM-based open redirection arises when a script  writes controllable data into the target of a redirection in an unsafe way. An attacker may be able to use the vulnerability to  construct a URL that, if visited by another application user, will cause a redirection to an arbitrary external domain. This behavior can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain and with a valid SSL certificate (if SSL is used), lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.</p>\n<p><b>Note:</b> If an attacker is able to control the start of the string that is passed to the redirection API, then it may be possible to escalate this vulnerability into a JavaScript injection attack, by using a URL with the javascript: pseudo-protocol to execute arbitrary script code when the URL is processed by the browser.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based open redirection vulnerabilities is not to dynamically set redirection targets using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a redirection target. In general, this is best achieved by using a whitelist of URLs that are permitted redirection targets, and strictly validating the target against this list before performing the redirection.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/601.html\">CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5243154",
        "name": "Open redirection (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>DOM-based open redirection arises when a script  writes controllable data into the target of a redirection in an unsafe way. An attacker may be able to use the vulnerability to  construct a URL that, if visited by another application user, will cause a redirection to an arbitrary external domain. This behavior can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain and with a valid SSL certificate (if SSL is used), lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.</p>\n<p><b>Note:</b> If an attacker is able to control the start of the string that is passed to the redirection API, then it may be possible to escalate this vulnerability into a JavaScript injection attack, by using a URL with the javascript: pseudo-protocol to execute arbitrary script code when the URL is processed by the browser.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based open redirection vulnerabilities is not to dynamically set redirection targets using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a redirection target. In general, this is best achieved by using a whitelist of URLs that are permitted redirection targets, and strictly validating the target against this list before performing the redirection.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/601.html\">CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5243392",
        "name": "SSL cookie without secure flag set",
        "description": "<p>If the secure flag is set on a cookie, then browsers will not submit the cookie in any requests that use an unencrypted HTTP connection, thereby preventing the cookie from being trivially intercepted by an attacker monitoring network traffic. If the secure flag is not set, then the cookie will be transmitted in clear-text if the user visits any HTTP URLs within the cookie's scope. An attacker may be able to induce this event by feeding a user suitable links, either directly or via another web site. Even if the domain that issued the cookie does not host any content that is accessed over HTTP, an attacker may be able to use links of the form http://example.com:443/ to perform the same attack.</p>\n<p>To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.</p>",
        "remediation": "<p>The secure flag should be set on all cookies that are used for transmitting sensitive data when accessing content over HTTPS. If cookies are used to transmit session tokens, then areas of the application that are accessed over HTTPS should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/614.html\">CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5243648",
        "name": "Cookie scoped to parent domain",
        "description": "<p>A cookie's domain attribute determines which domains can access the cookie. Browsers will automatically submit the cookie in requests to in-scope domains, and those domains will also be able to access the cookie via JavaScript. If a cookie is scoped to a parent domain, then that cookie will be accessible by the parent domain and also by any other subdomains of the parent domain. If the cookie contains sensitive data (such as a session token) then this data may be accessible by less trusted or less secure applications residing at those domains, leading to a security compromise.</p>",
        "remediation": "<p>By default, cookies are scoped to the issuing domain, and on IE/Edge to subdomains. If you remove the explicit domain attribute from your Set-cookie directive, then the cookie will have this default scope, which is safe and appropriate in most situations. If you particularly need a cookie to be accessible by a parent domain, then you should thoroughly review the security of the applications residing on that domain and its subdomains, and confirm that you are willing to trust the people and systems that support those applications.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5243904",
        "name": "Cross-domain Referer leakage",
        "description": "<p>When a web browser makes a request for a resource, it typically adds an HTTP header, called the \"Referer\" header, indicating the URL of the resource from which the request originated. This occurs in numerous situations, for example when a web page loads an image or script, or when a user clicks on a link or submits a form.</p>\n<p>If the resource being requested resides on a different domain, then the Referer header is still generally included in the cross-domain request. If the originating URL contains any sensitive information within its query string, such as a session token, then this information will be transmitted to the other domain. If the other domain is not fully trusted by the application, then this may lead to a security compromise.</p>\n<p>You should review the contents of the information being transmitted to other domains, and also determine whether those domains are fully trusted by the originating application.</p>\n<p>Today's browsers may withhold the Referer header in some situations (for example, when loading a non-HTTPS resource from a page that was loaded over HTTPS, or when a Refresh directive is issued), but this behavior should not be relied upon to protect the originating URL from disclosure.</p>\n<p>Note also that if users can author content within the application then an attacker may be able to inject links referring to a domain they control in order to capture data from URLs used within the application. </p>",
        "remediation": "<p>Applications should never transmit any sensitive information within the URL query string. In addition to being leaked in the Referer header, such information may be logged in various locations and may be visible on-screen to untrusted parties. If placing sensitive information in the URL is unavoidable, consider using the Referer-Policy HTTP header to reduce the chance of it being disclosed to third parties.\n</p>",
        "references": "<ul>\n<li><a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy\">Referer Policy</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/200.html\">CWE-200: Information Exposure</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5244160",
        "name": "Cross-domain script include",
        "description": "<p>When an application includes a script from an external domain, this script is executed by the browser within the security context of the invoking application. The script can therefore do anything that the application's own scripts can do, such as accessing application data and performing actions within the context of the current user.</p>\n<p>If you include a script from an external domain, then you are trusting that domain with the data and functionality of your application, and you are trusting the domain's own security to prevent an attacker from modifying the script to perform malicious actions within your application. </p>",
        "remediation": "<p>Scripts should ideally not be included from untrusted domains. Applications that rely on static third-party scripts should consider using Subresource Integrity to make browsers verify them, or copying the contents of these scripts onto their own domain and including them from there. If that is not possible (e.g. for licensing reasons) then consider reimplementing the script's functionality within application code.</p>",
        "references": "<ul>\n<li>\n<a href=\"https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity\">Subresource Integrity</a>\n</li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/829.html\">CWE-829: Inclusion of Functionality from Untrusted Control Sphere</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5244416",
        "name": "Cookie without HttpOnly flag set",
        "description": "<p>If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.</p>",
        "remediation": "<p>There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.</p>\n<p>You should be aware that the restrictions imposed by the HttpOnly flag can potentially be circumvented in some circumstances, and that numerous other serious attacks can be delivered by client-side script injection, aside from simple cookie stealing. </p>",
        "references": "<ul>\n<li><a href='https://www.owasp.org/index.php/HttpOnly'>Configuring HttpOnly</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5244672",
        "name": "Session token in URL",
        "description": "<p>Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.</p>",
        "remediation": "<p>Applications should use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/200.html\">CWE-200: Information Exposure</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/384.html\">CWE-384: Session Fixation</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/598.html\">CWE-598: Information Exposure Through Query Strings in GET Request</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5244928",
        "name": "Password field with autocomplete enabled",
        "description": "<p>Most browsers have a facility to remember user credentials that are entered into HTML forms. This function can be configured by the user and also by applications that employ user credentials. If the function is enabled, then credentials entered by the user are stored on their local computer and retrieved by the browser on future visits to the same application.</p>\n<p>The stored credentials can be captured by an attacker who gains control over the user's computer. Further, an attacker who finds a separate application vulnerability such as cross-site scripting may be able to exploit this to retrieve a user's browser-stored credentials. </p>",
        "remediation": "<p>To prevent browsers from storing credentials entered into HTML forms, include the attribute <b>autocomplete=\"off\"</b> within the FORM tag (to protect all form fields) or within the relevant INPUT tags (to protect specific individual fields).</p>\n<p>Please note that modern web browsers may ignore this directive. In spite of this there is a chance that not disabling autocomplete may cause problems obtaining PCI compliance.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/200.html\">CWE-200: Information Exposure</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245184",
        "name": "Password value set in cookie",
        "description": "<p>Some applications issue a cookie containing the clear-text value of the password supplied by the user. This behavior increases the risk that users' passwords will be captured by an attacker. Any cookie-stealing vulnerabilities within the application or browser would enable an attacker to steal the user's credentials to the application.</p>\n<p>Vulnerabilities that result in the disclosure of users' passwords can result in compromises that are extremely difficult to investigate due to obscured audit trails. Even if the application itself only handles non-sensitive information, exposing passwords puts users who have re-used their password elsewhere at risk.</p>",
        "remediation": "<p>Applications should not store user credentials within any client-side mechanism such as cookies.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/287.html\">CWE-287: Improper Authentication</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245312",
        "name": "File upload functionality",
        "description": "<p>File upload functionality is commonly associated with a number of vulnerabilities, including:</p>\n<ul>\n<li>File path traversal</li><li>Persistent cross-site scripting</li><li>Placing of other client-executable code into the domain</li><li>Transmission of viruses and other malware</li><li>Denial of service</li></ul>\n<p>You should review file upload functionality to understand its purpose, and establish whether uploaded content is ever returned to other application users, either through their normal usage of the application or by being fed a specific link by an attacker.</p>\n<p>Some factors to consider when evaluating the security impact of this functionality include:</p>\n<ul>\n<li>Whether uploaded content can subsequently be downloaded via a URL within the application.</li><li>What Content-type and Content-disposition headers the application returns when the file's content is downloaded.</li><li>Whether it is possible to place executable HTML/JavaScript into the file, which executes when the file's contents are viewed.</li><li>Whether the application performs any filtering on the file extension or MIME type of the uploaded file.</li><li>Whether it is possible to construct a hybrid file containing both executable and non-executable content, to bypass any content filters - for example, a file containing both a GIF image and a Java archive (known as a GIFAR file).</li><li>What location is used to store uploaded content, and whether it is possible to supply a crafted filename to escape from this location.</li><li>Whether archive formats such as ZIP are unpacked by the application.</li><li>How the application handles attempts to upload very large files, or decompression bomb files.</li></ul>",
        "remediation": "<p>File upload functionality is not straightforward to implement securely. Some recommendations to consider in the design of this functionality include:</p>\n<ul>\n<li>Use a server-generated filename if storing uploaded files on disk.</li><li>Inspect the content of uploaded files, and enforce a whitelist of accepted, non-executable content types. Additionally, enforce a blacklist of common executable formats, to hinder hybrid file attacks.</li><li>Enforce a whitelist of accepted, non-executable file extensions.</li>\n<li>If uploaded files are downloaded by users, supply an accurate non-generic Content-Type header, the X-Content-Type-Options: nosniff header, and also a Content-Disposition header that specifies that browsers should handle the file as an attachment.</li>\n<li>Enforce a size limit on uploaded files (for defense-in-depth, this can be implemented both within application code and in the web server's configuration).</li><li>Reject attempts to upload archive formats such as ZIP.</li></ul>",
        "references": "<ul><li><a href=\"https://github.com/cure53/H5SC/tree/master/attachments\">Various proof-of-concept files</a></li>\n<li><a href=\"http://labs.detectify.com/post/120088174539/building-an-xss-polyglot-through-swf-and-csp\">An XSS polyglot attack</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/434.html\">CWE-434: Unrestricted Upload of File with Dangerous Type</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245344",
        "name": "Frameable response (potential Clickjacking)",
        "description": "<p>If a page fails to set an appropriate X-Frame-Options or Content-Security-Policy HTTP header, it might be possible for a page controlled by an attacker to load it within an iframe. This may enable a clickjacking attack, in which the attacker's page overlays the target application's interface with a different interface provided by the attacker. By inducing victim users to perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within the application that is being targeted. This technique allows the attacker to circumvent defenses against cross-site request forgery, and may result in unauthorized actions.</p>\n<p>Note that some applications attempt to prevent these attacks from within the HTML page itself, using \"framebusting\" code. However, this type of defense is normally ineffective and can usually be circumvented by a skilled attacker.</p>\n<p>You should determine whether any functions accessible within frameable pages can be used by application users to perform any sensitive actions within the application. </p>",
        "remediation": "<p>To effectively prevent framing attacks, the application should return a response header with the name <b>X-Frame-Options</b> and the value <b>DENY</b> to prevent framing altogether, or the value <b>SAMEORIGIN</b> to allow framing only by pages on the same origin as the response itself. Note that the SAMEORIGIN header can be partially bypassed if the application itself can be made to frame untrusted websites.</p>",
        "references": "<ul><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options\">X-Frame-Options</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/693.html\">CWE-693: Protection Mechanism Failure</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245360",
        "name": "Browser cross-site scripting filter disabled",
        "description": "<p>Some browsers, including Internet Explorer, contain built-in filters designed to protect against cross-site scripting (XSS) attacks. Applications can instruct browsers to disable this filter by setting the following response header:</p>\n<p><b>X-XSS-Protection: 0</b></p>\n<p>This behavior does not in itself constitute a vulnerability; in some cases XSS filters may themselves be leveraged to perform attacks against application users. However, in typical situations XSS filters do provide basic protection for application users against some XSS vulnerabilities in applications. The presence of this header should be reviewed to establish whether it affects the application's security posture. </p>",
        "remediation": "<p>Review whether the application needs to disable XSS filters. In most cases you can gain the protection provided by XSS filters without the associated risks by using the following response header:</p>\n<p><b>X-XSS-Protection: 1; mode=block</b></p>\n<p>When this header is set, browsers that detect an XSS attack will simply render a blank page instead of attempting to sanitize the injected script. This behavior is considerably less likely to introduce new security issues. </p>",
        "references": "<ul>\n\t<li><a href=\"https://portswigger.net/web-security/cross-site-scripting\">Cross-site scripting</a></li>\n\t<li><a href=\"http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx\">Controlling the XSS Filter</a></li>\n\t</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245440",
        "name": "HTTP TRACE method is enabled",
        "description": "<p>The HTTP TRACE  method is designed for diagnostic purposes. If enabled, the web server will respond to requests that use the TRACE method by echoing in its response the exact request that was received.</p>\n<p>This behavior is often harmless, but occasionally leads to the disclosure of sensitive information such as internal authentication headers appended by reverse proxies. This functionality could historically be used to bypass the HttpOnly cookie flag on cookies, but this is no longer possible in modern web browsers. </p>",
        "remediation": "<p>The TRACE method should be disabled on production web servers.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245696",
        "name": "Cookie manipulation (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n\n<p>DOM-based cookie manipulation arises when a  script writes controllable data into the value of a cookie. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will set an arbitrary value in the user's cookie.</p>\n<p>The potential impact of the vulnerability depends on the role that the cookie plays within the application. If the cookie is used to control the behavior that results from certain user actions (for example, a 'production' versus 'demo' mode setting), then the attacker may be able to cause the user to perform unintended actions by manipulating the cookie's value. If the cookie is used to track the user's session, then the attacker may be able to perform a session fixation attack, in which they set the cookie's value to a valid token that they have obtained from the application, and then hijack the session during the victim user's subsequent interaction with the application.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based cookie manipulation vulnerabilities is not to dynamically write to cookies using data that originated from any untrusted source. This behavior should never be implemented for cookies that have any role in controlling privileged actions or user sessions within the application.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/565.html\">CWE-565: Reliance on Cookies without Validation and Integrity Checking</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/829.html\">CWE-829: Inclusion of Functionality from Untrusted Control Sphere</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245697",
        "name": "Cookie manipulation (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>DOM-based cookie manipulation arises when a  script writes controllable data into the value of a cookie. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will set an arbitrary value in the user's cookie.</p>\n<p>The potential impact of the vulnerability depends on the role that the cookie plays within the application. If the cookie is used to control the behavior that results from certain user actions (for example, a 'production' versus 'demo' mode setting), then the attacker may be able to cause the user to perform unintended actions by manipulating the cookie's value. If the cookie is used to track the user's session, then the attacker may be able to perform a session fixation attack, in which they set the cookie's value to a valid token that they have obtained from the application, and then hijack the session during the victim user's subsequent interaction with the application.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based cookie manipulation vulnerabilities is not to dynamically write to cookies using data that originated from any untrusted source. This behavior should never be implemented for cookies that have any role in controlling privileged actions or user sessions within the application.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/565.html\">CWE-565: Reliance on Cookies without Validation and Integrity Checking</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/829.html\">CWE-829: Inclusion of Functionality from Untrusted Control Sphere</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245698",
        "name": "Cookie manipulation (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>DOM-based cookie manipulation arises when a  script writes controllable data into the value of a cookie. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will set an arbitrary value in the user's cookie.</p>\n<p>The potential impact of the vulnerability depends on the role that the cookie plays within the application. If the cookie is used to control the behavior that results from certain user actions (for example, a 'production' versus 'demo' mode setting), then the attacker may be able to cause the user to perform unintended actions by manipulating the cookie's value. If the cookie is used to track the user's session, then the attacker may be able to perform a session fixation attack, in which they set the cookie's value to a valid token that they have obtained from the application, and then hijack the session during the victim user's subsequent interaction with the application.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based cookie manipulation vulnerabilities is not to dynamically write to cookies using data that originated from any untrusted source. This behavior should never be implemented for cookies that have any role in controlling privileged actions or user sessions within the application.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/565.html\">CWE-565: Reliance on Cookies without Validation and Integrity Checking</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/829.html\">CWE-829: Inclusion of Functionality from Untrusted Control Sphere</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245952",
        "name": "Ajax request header manipulation (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n<p>Ajax request header manipulation  arises when a script writes controllable data into a header of an Ajax request that is issued using XmlHttpRequest. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will set an arbitrary header in the subsequent Ajax request.</p>\n<p>The potential impact of the vulnerability depends on the role of specific HTTP headers in the server-side application's processing of the Ajax request. If the header is used to control the behavior that results from the Ajax request, then the attacker may be able to cause the user to perform unintended actions by manipulating the header.</p>\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based Ajax request header manipulation vulnerabilities is not to dynamically set Ajax request headers using data that originated from any untrusted source. This behavior should never be implemented for headers that have any role in controlling the effects of privileged actions within the application. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245953",
        "name": "Ajax request header manipulation (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>Ajax request header manipulation  arises when a script writes controllable data into a header of an Ajax request that is issued using XmlHttpRequest. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will set an arbitrary header in the subsequent Ajax request.</p>\n<p>The potential impact of the vulnerability depends on the role of specific HTTP headers in the server-side application's processing of the Ajax request. If the header is used to control the behavior that results from the Ajax request, then the attacker may be able to cause the user to perform unintended actions by manipulating the header.</p>\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based Ajax request header manipulation vulnerabilities is not to dynamically set Ajax request headers using data that originated from any untrusted source. This behavior should never be implemented for headers that have any role in controlling the effects of privileged actions within the application. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5245954",
        "name": "Ajax request header manipulation (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>Ajax request header manipulation  arises when a script writes controllable data into a header of an Ajax request that is issued using XmlHttpRequest. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will set an arbitrary header in the subsequent Ajax request.</p>\n<p>The potential impact of the vulnerability depends on the role of specific HTTP headers in the server-side application's processing of the Ajax request. If the header is used to control the behavior that results from the Ajax request, then the attacker may be able to cause the user to perform unintended actions by manipulating the header.</p>\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based Ajax request header manipulation vulnerabilities is not to dynamically set Ajax request headers using data that originated from any untrusted source. This behavior should never be implemented for headers that have any role in controlling the effects of privileged actions within the application. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/116.html\">CWE-116: Improper Encoding or Escaping of Output</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246208",
        "name": "Denial of service (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n\n<p>DOM-based denial of service  arises when a script passes controllable data to a problematic platform API in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause a denial of service condition on the user's computer when the relevant API is invoked. Depending on the nature of the API, the invocation may cause the user's computer to consume excessive amounts of CPU or disk space. This may result in side effects if the web browser restricts application functionality; for example, by rejecting attempts to store data in localStorage or killing busy scripts.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based denial of service vulnerabilities is not to dynamically pass data into problematic platform APIs that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from causing a denial of service condition. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/400.html\">CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246209",
        "name": "Denial of service (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>DOM-based denial of service  arises when a script passes controllable data to a problematic platform API in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause a denial of service condition on the user's computer when the relevant API is invoked. Depending on the nature of the API, the invocation may cause the user's computer to consume excessive amounts of CPU or disk space. This may result in side effects if the web browser restricts application functionality; for example, by rejecting attempts to store data in localStorage or killing busy scripts.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based denial of service vulnerabilities is not to dynamically pass data into problematic platform APIs that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from causing a denial of service condition. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/400.html\">CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246210",
        "name": "Denial of service (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>DOM-based denial of service  arises when a script passes controllable data to a problematic platform API in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause a denial of service condition on the user's computer when the relevant API is invoked. Depending on the nature of the API, the invocation may cause the user's computer to consume excessive amounts of CPU or disk space. This may result in side effects if the web browser restricts application functionality; for example, by rejecting attempts to store data in localStorage or killing busy scripts.</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based denial of service vulnerabilities is not to dynamically pass data into problematic platform APIs that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from causing a denial of service condition. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/400.html\">CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246464",
        "name": "HTML5 web message manipulation (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n<p>HTML5 web message manipulation arises when a script sends controllable data as a web message to another document within the browser. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the user's browser to send a web message containing data that is under the attacker's control.</p>\n<p>The potential impact of the vulnerability depends on the destination document's handling of the incoming message. If the destination document trusts the sender not to transmit malicious data in the message, and handles the data in an unsafe manner, then the joint behavior of the two documents may allow an attacker to compromise the application user.\n</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based HTML5 web message manipulation vulnerabilities is not to send a web message containing data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from compromising the user. This validation can be carried out by the document that sends the message, or by the document that receives the message, or both, depending on the trust relationship between the two documents.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246465",
        "name": "HTML5 web message manipulation (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>HTML5 web message manipulation arises when a script sends controllable data as a web message to another document within the browser. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the user's browser to send a web message containing data that is under the attacker's control.</p>\n<p>The potential impact of the vulnerability depends on the destination document's handling of the incoming message. If the destination document trusts the sender not to transmit malicious data in the message, and handles the data in an unsafe manner, then the joint behavior of the two documents may allow an attacker to compromise the application user.\n</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based HTML5 web message manipulation vulnerabilities is not to send a web message containing data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from compromising the user. This validation can be carried out by the document that sends the message, or by the document that receives the message, or both, depending on the trust relationship between the two documents.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246466",
        "name": "HTML5 web message manipulation (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>HTML5 web message manipulation arises when a script sends controllable data as a web message to another document within the browser. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the user's browser to send a web message containing data that is under the attacker's control.</p>\n<p>The potential impact of the vulnerability depends on the destination document's handling of the incoming message. If the destination document trusts the sender not to transmit malicious data in the message, and handles the data in an unsafe manner, then the joint behavior of the two documents may allow an attacker to compromise the application user.\n</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based HTML5 web message manipulation vulnerabilities is not to send a web message containing data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from compromising the user. This validation can be carried out by the document that sends the message, or by the document that receives the message, or both, depending on the trust relationship between the two documents.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246720",
        "name": "HTML5 storage manipulation (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n<p>HTML5 storage manipulation arises when a script stores controllable data in the HTML5 storage of the web browser (either localStorage or sessionStorage). An attacker may be able to use this behavior to construct a URL that, if visited by another application user, will cause the user's browser to store attacker-controllable data.</p>\n<p>This behavior does not in itself constitute a security vulnerability. However, if the application later reads the data back from storage and processes it in an unsafe way, then an attacker may be able to leverage the storage mechanism to deliver other DOM-based attacks, such as cross-site scripting and JavaScript injection.\n</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based HTML5 storage manipulation is not to place in HTML5 storage any data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from being stored.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246721",
        "name": "HTML5 storage manipulation (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>HTML5 storage manipulation arises when a script stores controllable data in the HTML5 storage of the web browser (either localStorage or sessionStorage). An attacker may be able to use this behavior to construct a URL that, if visited by another application user, will cause the user's browser to store attacker-controllable data.</p>\n<p>This behavior does not in itself constitute a security vulnerability. However, if the application later reads the data back from storage and processes it in an unsafe way, then an attacker may be able to leverage the storage mechanism to deliver other DOM-based attacks, such as cross-site scripting and JavaScript injection.\n</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based HTML5 storage manipulation is not to place in HTML5 storage any data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from being stored.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246722",
        "name": "HTML5 storage manipulation (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>HTML5 storage manipulation arises when a script stores controllable data in the HTML5 storage of the web browser (either localStorage or sessionStorage). An attacker may be able to use this behavior to construct a URL that, if visited by another application user, will cause the user's browser to store attacker-controllable data.</p>\n<p>This behavior does not in itself constitute a security vulnerability. However, if the application later reads the data back from storage and processes it in an unsafe way, then an attacker may be able to leverage the storage mechanism to deliver other DOM-based attacks, such as cross-site scripting and JavaScript injection.\n</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based HTML5 storage manipulation is not to place in HTML5 storage any data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from being stored.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246976",
        "name": "Link manipulation (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n<p>DOM-based link manipulation  arises when a script writes controllable data to a navigation target within the current page, such as a clickable link or the submission URL of a form. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will modify the target of links within the response. An attacker may be able to leverage this to perform various attacks, including:</p>\n<ul>\n<li>Causing the user to redirect to an arbitrary external URL, to facilitate a phishing attack.</li><li>Causing the user to submit sensitive form data to a server controlled by the attacker.</li><li>Causing the user to perform an unintended action within the application, by changing the file or query string associated with a link.</li><li>Bypassing browser anti-XSS defenses by injecting on-site links containing XSS exploits, since browser anti-XSS defenses typically do not operate on on-site links.</li></ul>\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based link manipulation vulnerabilities is not to dynamically set the target URLs of links or forms using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a link target. In general, this is best achieved by using a whitelist of URLs that are permitted link targets, and strictly validating the target against this list before setting the link target.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246977",
        "name": "Link manipulation (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>DOM-based link manipulation  arises when a script writes controllable data to a navigation target within the current page, such as a clickable link or the submission URL of a form. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will modify the target of links within the response. An attacker may be able to leverage this to perform various attacks, including:</p>\n<ul>\n<li>Causing the user to redirect to an arbitrary external URL, to facilitate a phishing attack.</li><li>Causing the user to submit sensitive form data to a server controlled by the attacker.</li><li>Causing the user to perform an unintended action within the application, by changing the file or query string associated with a link.</li><li>Bypassing browser anti-XSS defenses by injecting on-site links containing XSS exploits, since browser anti-XSS defenses typically do not operate on on-site links.</li></ul>\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based link manipulation vulnerabilities is not to dynamically set the target URLs of links or forms using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a link target. In general, this is best achieved by using a whitelist of URLs that are permitted link targets, and strictly validating the target against this list before setting the link target.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246978",
        "name": "Link manipulation (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>DOM-based link manipulation  arises when a script writes controllable data to a navigation target within the current page, such as a clickable link or the submission URL of a form. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will modify the target of links within the response. An attacker may be able to leverage this to perform various attacks, including:</p>\n<ul>\n<li>Causing the user to redirect to an arbitrary external URL, to facilitate a phishing attack.</li><li>Causing the user to submit sensitive form data to a server controlled by the attacker.</li><li>Causing the user to perform an unintended action within the application, by changing the file or query string associated with a link.</li><li>Bypassing browser anti-XSS defenses by injecting on-site links containing XSS exploits, since browser anti-XSS defenses typically do not operate on on-site links.</li></ul>\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based link manipulation vulnerabilities is not to dynamically set the target URLs of links or forms using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a link target. In general, this is best achieved by using a whitelist of URLs that are permitted link targets, and strictly validating the target against this list before setting the link target.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246979",
        "name": "Link manipulation (reflected)",
        "description": "<p>Link manipulation occurs when an application embeds user input into the path or domain of URLs that appear within application responses.&nbsp;An attacker can use this vulnerability to construct a link that, if visited by another application user, will modify the target of URLs within the response. It may be possible to leverage this to perform various attacks, such as:</p>\n<ul>\n  <li>Manipulating the path of an on-site link that has sensitive parameters in the URL. If the response from the modified path contains references to off-site resources, then the sensitive data might be leaked to external domains via the Referer header.</li>\n  <li>Manipulating the URL targeted by a form action, making the form submission have unintended side effects.</li>\n  <li>Manipulating the URL used by a CSS import statement to point to an attacker-uploaded file, resulting in CSS injection.</li>\n  <li>Injecting on-site links containing XSS exploits, thereby bypassing browser anti-XSS defenses, since those defenses typically do not operate on on-site links.</li>\n</ul>\n<p>The security impact of this issue depends largely on the nature of the application functionality. Even if it has no direct impact on its own, an attacker may use it in conjunction with other vulnerabilities to escalate their overall severity.</p>",
        "remediation": "<p>Consider using a whitelist to restrict user input to safe values. Please note that in some situations this issue will have no security impact, meaning no remediation is necessary.</p>",
        "references": "<ul>\n  <li><a href=\"http://blog.mish.re/index.php/2017/04/29/yahoo-bug-bounty-chaining-3-minor-issues-to-takeover-flickr-accounts/\">Using path manipulation to hijack Flickr accounts</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/73.html\">CWE-73: External Control of File Name or Path</a></li>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5246980",
        "name": "Link manipulation (stored)",
        "description": "<p>Link manipulation occurs when an application embeds user input into the path or domain of URLs that appear within application responses.&nbsp;An attacker can use this vulnerability to construct a link that, if visited by another application user, will modify the target of URLs within the response. It may be possible to leverage this to perform various attacks, such as:</p>\n<ul>\n  <li>Manipulating the path of an on-site link that has sensitive parameters in the URL. If the response from the modified path contains references to off-site resources, then the sensitive data might be leaked to external domains via the Referer header.</li>\n  <li>Manipulating the URL targeted by a form action, making the form submission have unintended side effects.</li>\n  <li>Manipulating the URL used by a CSS import statement to point to an attacker-uploaded file, resulting in CSS injection.</li>\n  <li>Injecting on-site links containing XSS exploits, thereby bypassing browser anti-XSS defenses, since those defenses typically do not operate on on-site links.</li>\n</ul>\n<p>The security impact of this issue depends largely on the nature of the application functionality. Even if it has no direct impact on its own, an attacker may use it in conjunction with other vulnerabilities to escalate their overall severity.</p>\n\n<p>Stored link manipulation vulnerabilities arise when the applicable input was submitted in an previous request and stored by the application.</p>",
        "remediation": "<p>Consider using a whitelist to restrict user input to safe values. Please note that in some situations this issue will have no security impact, meaning no remediation is necessary.</p>",
        "references": "<ul>\n  <li><a href=\"http://blog.mish.re/index.php/2017/04/29/yahoo-bug-bounty-chaining-3-minor-issues-to-takeover-flickr-accounts/\">Using path manipulation to hijack Flickr accounts</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/73.html\">CWE-73: External Control of File Name or Path</a></li>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5247232",
        "name": "Document domain manipulation (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n\n<p>Document domain manipulation arises when a script uses controllable data to set the document.domain property. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the response page to set an arbitrary document.domain value.</p>\n<p>The document.domain property is used by browsers in their enforcement of the same origin policy. If two pages from different origins explicitly set the same document.domain value, then those two pages can interact in unrestricted ways. If an attacker can cause a page of a targeted application, and another page they control (either directly, or via an XSS-like vulnerability), to set the same document.domain value, then the attacker may be able to fully compromise the targeted application page via the page they already control, with the same possibilities for exploitation as regular cross-site scripting (XSS) vulnerabilities.</p>\n<p>Browsers generally enforce some restrictions on the values that can be assigned to document.domain, and may prevent the use of completely different values than the actual origin of the page. However, there are two important caveats to this. Firstly, browsers allow the use of child or parent domains, so an attacker may be able to switch the domain of the targeted application page to that of a related application with a weaker security posture. Secondly, some browser quirks enable switching to completely unrelated domains. These caveats mean that the ability to manipulate the document.domain property of a page generally represents a security vulnerability whose severity is not far behind regular XSS.\n</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based document domain manipulation vulnerabilities is not to dynamically set the document.domain property using data that originated from any untrusted source. If it is necessary to programmatically set the document.domain property from within client-side code, then the application should employ a set list of acceptable values, and assign only from values in that list. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5247233",
        "name": "Document domain manipulation (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>Document domain manipulation arises when a script uses controllable data to set the document.domain property. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the response page to set an arbitrary document.domain value.</p>\n<p>The document.domain property is used by browsers in their enforcement of the same origin policy. If two pages from different origins explicitly set the same document.domain value, then those two pages can interact in unrestricted ways. If an attacker can cause a page of a targeted application, and another page they control (either directly, or via an XSS-like vulnerability), to set the same document.domain value, then the attacker may be able to fully compromise the targeted application page via the page they already control, with the same possibilities for exploitation as regular cross-site scripting (XSS) vulnerabilities.</p>\n<p>Browsers generally enforce some restrictions on the values that can be assigned to document.domain, and may prevent the use of completely different values than the actual origin of the page. However, there are two important caveats to this. Firstly, browsers allow the use of child or parent domains, so an attacker may be able to switch the domain of the targeted application page to that of a related application with a weaker security posture. Secondly, some browser quirks enable switching to completely unrelated domains. These caveats mean that the ability to manipulate the document.domain property of a page generally represents a security vulnerability whose severity is not far behind regular XSS.\n</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based document domain manipulation vulnerabilities is not to dynamically set the document.domain property using data that originated from any untrusted source. If it is necessary to programmatically set the document.domain property from within client-side code, then the application should employ a set list of acceptable values, and assign only from values in that list. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5247234",
        "name": "Document domain manipulation (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n\n<p>Document domain manipulation arises when a script uses controllable data to set the document.domain property. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause the response page to set an arbitrary document.domain value.</p>\n<p>The document.domain property is used by browsers in their enforcement of the same origin policy. If two pages from different origins explicitly set the same document.domain value, then those two pages can interact in unrestricted ways. If an attacker can cause a page of a targeted application, and another page they control (either directly, or via an XSS-like vulnerability), to set the same document.domain value, then the attacker may be able to fully compromise the targeted application page via the page they already control, with the same possibilities for exploitation as regular cross-site scripting (XSS) vulnerabilities.</p>\n<p>Browsers generally enforce some restrictions on the values that can be assigned to document.domain, and may prevent the use of completely different values than the actual origin of the page. However, there are two important caveats to this. Firstly, browsers allow the use of child or parent domains, so an attacker may be able to switch the domain of the targeted application page to that of a related application with a weaker security posture. Secondly, some browser quirks enable switching to completely unrelated domains. These caveats mean that the ability to manipulate the document.domain property of a page generally represents a security vulnerability whose severity is not far behind regular XSS.\n</p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based document domain manipulation vulnerabilities is not to dynamically set the document.domain property using data that originated from any untrusted source. If it is necessary to programmatically set the document.domain property from within client-side code, then the application should employ a set list of acceptable values, and assign only from values in that list. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5247488",
        "name": "DOM data manipulation (DOM-based)",
        "description": "<p>DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.</p>\n<p>DOM data manipulation arises when a script writes controllable data to a field within the DOM that is used within the visible UI or client-side application logic. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will modify the appearance or behavior of the client-side UI. An attacker may be able to leverage this to perform virtual defacement of the application, or possibly to induce the user to perform unintended actions. </p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based DOM data manipulation vulnerabilities is not to dynamically write to DOM data fields any data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from being stored. In general, this is best achieved by using a whitelist of permitted values.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5247489",
        "name": "DOM data manipulation (reflected DOM-based)",
        "description": "<p>Reflected DOM-based vulnerabilities arise when data is copied from a request and echoed into the application's immediate response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the reflection to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>DOM data manipulation arises when a script writes controllable data to a field within the DOM that is used within the visible UI or client-side application logic. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will modify the appearance or behavior of the client-side UI. An attacker may be able to leverage this to perform virtual defacement of the application, or possibly to induce the user to perform unintended actions. </p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based DOM data manipulation vulnerabilities is not to dynamically write to DOM data fields any data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from being stored. In general, this is best achieved by using a whitelist of permitted values.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5247490",
        "name": "DOM data manipulation (stored DOM-based)",
        "description": "<p>Stored DOM-based vulnerabilities arise when user input is stored and later embedded into a response within a part of the DOM that is then processed in an unsafe way by a client-side script. An attacker can leverage the data storage to control a part of the response (for example, a JavaScript string) that can be used to trigger the DOM-based vulnerability.</p>\n<p>DOM data manipulation arises when a script writes controllable data to a field within the DOM that is used within the visible UI or client-side application logic. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will modify the appearance or behavior of the client-side UI. An attacker may be able to leverage this to perform virtual defacement of the application, or possibly to induce the user to perform unintended actions. </p>\n\n<p>Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.</p>",
        "remediation": "<p>The most effective way to avoid DOM-based DOM data manipulation vulnerabilities is not to dynamically write to DOM data fields any data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from being stored. In general, this is best achieved by using a whitelist of permitted values.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5247744",
        "name": "CSS injection (reflected)",
        "description": "<p>CSS injection vulnerabilities arise when an application imports a style sheet from a user-supplied URL, or embeds user input in CSS blocks without adequate escaping. They are closely related to cross-site scripting (XSS) vulnerabilities but often trickier to exploit. </p>\n<p>Being able to inject arbitrary CSS into the victim's browser may enable various attacks, including:</p>\n<ul>\n  <li>Executing arbitrary JavaScript using IE's expression() function.</li><li>Using CSS selectors to read parts of the HTML source, which may include sensitive data such as anti-CSRF tokens.</li>\n<li>Capturing any sensitive data within the URL query string by making a further style sheet import to a URL on the attacker's domain, and monitoring the incoming Referer header.</li></ul>",
        "remediation": "<p>Ensure that user input is adequately escaped before embedding it in CSS blocks, and consider using a whitelist to prevent loading of arbitrary style sheets.</p>",
        "references": "<ul>\n<li><a href=\"http://blog.portswigger.net/2015/02/prssi.html#badcss\">Malicious CSS</a></li>\n<li><a href=\"http://mksben.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html\">Abusing unicode-range of @font-face</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/73.html\">CWE-73: External Control of File Name or Path</a></li>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5247745",
        "name": "CSS injection (stored)",
        "description": "<p>CSS injection vulnerabilities arise when an application imports a style sheet from a user-supplied URL, or embeds user input in CSS blocks without adequate escaping. They are closely related to cross-site scripting (XSS) vulnerabilities but often trickier to exploit. </p>\n<p>Being able to inject arbitrary CSS into the victim's browser may enable various attacks, including:</p>\n<ul>\n  <li>Executing arbitrary JavaScript using IE's expression() function.</li><li>Using CSS selectors to read parts of the HTML source, which may include sensitive data such as anti-CSRF tokens.</li>\n<li>Capturing any sensitive data within the URL query string by making a further style sheet import to a URL on the attacker's domain, and monitoring the incoming Referer header.</li></ul><p>Stored CSS injection vulnerabilities arise when the applicable input was submitted in an previous request and stored by the application.</p>",
        "remediation": "<p>Ensure that user input is adequately escaped before embedding it in CSS blocks, and consider using a whitelist to prevent loading of arbitrary style sheets.</p>",
        "references": "<ul>\n<li><a href=\"http://blog.portswigger.net/2015/02/prssi.html#badcss\">Malicious CSS</a></li>\n<li><a href=\"http://mksben.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html\">Abusing unicode-range of @font-face</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/73.html\">CWE-73: External Control of File Name or Path</a></li>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5248000",
        "name": "Client-side HTTP parameter pollution (reflected)",
        "description": "<p>Client-side HTTP parameter pollution (HPP) vulnerabilities arise when an application embeds user input in URLs in an unsafe manner.  An attacker can use this vulnerability to construct a URL that, if visited by another application user, will modify URLs within the response by inserting additional query string parameters and sometimes overriding existing ones. This may result in links and forms having unexpected side effects. For example, it may be possible to modify an invitation form using HPP so that the invitation is delivered to an unexpected recipient. </p>\n<p>The security impact of this issue depends largely on the nature of the application functionality. Even if it has no direct impact on its own, an attacker may use it in conjunction with other vulnerabilities to escalate their overall severity.</p>",
        "remediation": "<p>Ensure that user input is URL-encoded before it is embedded in a URL.</p>",
        "references": "<ul>\n  <li><a href=\"https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf\">HTTP Parameter Pollution</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/233.html\">CWE-233: Improper Handling of Parameters</a></li>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5248001",
        "name": "Client-side HTTP parameter pollution (stored)",
        "description": "<p>Client-side HTTP parameter pollution (HPP) vulnerabilities arise when an application embeds user input in URLs in an unsafe manner.  An attacker can use this vulnerability to construct a URL that, if visited by another application user, will modify URLs within the response by inserting additional query string parameters and sometimes overriding existing ones. This may result in links and forms having unexpected side effects. For example, it may be possible to modify an invitation form using HPP so that the invitation is delivered to an unexpected recipient. </p>\n<p>The security impact of this issue depends largely on the nature of the application functionality. Even if it has no direct impact on its own, an attacker may use it in conjunction with other vulnerabilities to escalate their overall severity.</p>\n\n<p>Stored client-side HTTP parameter pollution vulnerabilities arise when the applicable input was submitted in an previous request and stored by the application.</p>",
        "remediation": "<p>Ensure that user input is URL-encoded before it is embedded in a URL.</p>",
        "references": "<ul>\n  <li><a href=\"https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf\">HTTP Parameter Pollution</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/233.html\">CWE-233: Improper Handling of Parameters</a></li>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5248256",
        "name": "Form action hijacking (reflected)",
        "description": "<p>Form action hijacking vulnerabilities arise when an application places user-supplied input into the action URL of an HTML form. An attacker can use this vulnerability to construct a URL that, if visited by another application user, will modify the action URL of a form to point to the attacker's server. If a user submits the form then its contents, including any input from the victim user, will be delivered directly to the attacker.</p>\n<p> Even if the user doesn't enter any sensitive information, the form may still deliver a valid CSRF token to the attacker, enabling them to perform CSRF attacks. In some cases web browsers may help exacerbate this issue by autocompleting forms with previously entered user input. </p>",
        "remediation": "<p>Consider hard-coding the form action URL, or implementing a whitelist of allowed values.</p>",
        "vulnerability_classifications": "<ul>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/73.html\">CWE-73: External Control of File Name or Path</a></li>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "5248257",
        "name": "Form action hijacking (stored)",
        "description": "<p>Form action hijacking vulnerabilities arise when an application places user-supplied input into the action URL of an HTML form. An attacker can use this vulnerability to construct a URL that, if visited by another application user, will modify the action URL of a form to point to the attacker's server. If a user submits the form then its contents, including any input from the victim user, will be delivered directly to the attacker.</p>\n<p> Even if the user doesn't enter any sensitive information, the form may still deliver a valid CSRF token to the attacker, enabling them to perform CSRF attacks. In some cases web browsers may help exacerbate this issue by autocompleting forms with previously entered user input. </p>\n\n<p>Stored form action hijacking vulnerabilities arise when the applicable input was submitted in an previous request and stored by the application.</p>",
        "remediation": "<p>Consider hard-coding the form action URL, or implementing a whitelist of allowed values.</p>",
        "vulnerability_classifications": "<ul>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/73.html\">CWE-73: External Control of File Name or Path</a></li>\n  <li><a href=\"https://cwe.mitre.org/data/definitions/20.html\">CWE-20: Improper Input Validation</a></li>\n</ul>"
    },
    {
        "issue_type_id": "6291584",
        "name": "Database connection string disclosed",
        "description": "<p>A database connection string specifies information about a data source and the means of connecting to it. In web applications, connection strings are generally used by the application tier to connect to the back database used for storing application data. They are usually read from server-side configuration files or hard-coded into application source code.</p>",
        "remediation": "<p>It is almost never necessary for applications to disclose database connection strings to clients. The reason for the disclosure should be reviewed and addressed.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/15.html\">CWE-15: External Control of System or Configuration Setting</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/497.html\">CWE-497: Exposure of System Data to an Unauthorized Control Sphere</a></li>\n</ul>"
    },
    {
        "issue_type_id": "6291632",
        "name": "Source code disclosure",
        "description": "<p>Source code intended to be kept server-side can sometimes end up being disclosed to users. Such code may contain sensitive information such as database passwords and secret keys, which may help malicious users formulate attacks against the application.</p>",
        "remediation": "<p>Server-side source code is normally disclosed to clients as a result of typographical errors in scripts or because of misconfiguration, such as failing to grant executable permissions to a script or directory. Review the cause of the code disclosure and prevent it from happening.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/18.html\">CWE-18: Source Code</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/200.html\">CWE-200: Information Exposure</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/388.html\">CWE-388: Error Handling</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/540.html\">CWE-540: Information Exposure Through Source Code</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/541.html\">CWE-541: Information Exposure Through Include Source Code</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/615.html\">CWE-615: Information Exposure Through Comments</a></li>\n</ul>"
    },
    {
        "issue_type_id": "6291672",
        "name": "Backup file",
        "description": "<p>Publicly accessible backups and outdated copies of files can provide attackers with extra attack surface. Depending on the server configuration and file type, they may also expose source code, configuration details, and other information intended to remain secret.</p>",
        "remediation": "<p>Review the file to identify whether it's intended to be publicly accessible, and remove it from the server's web root if it isn't. It may also be worth auditing the server contents to find other outdated files, and taking measures to prevent the problem from recurring.</p>",
        "references": "<ul>\n    <li><a href=\"https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004)\">Review Old, Backup and Unreferenced Files for Sensitive Information</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n    <li><a href=\"https://cwe.mitre.org/data/definitions/530.html\">CWE-530: Exposure of Backup File to an Unauthorized Control Sphere</a></li>\n</ul>"
    },
    {
        "issue_type_id": "6291712",
        "name": "Directory listing",
        "description": "<p>Web servers can be configured to automatically list the contents of directories that do not have an index page present. This can aid an attacker by enabling them to quickly identify the resources at a given path, and proceed directly to analyzing and attacking those resources. It particularly increases the exposure of sensitive files within the directory that are not intended to be accessible to users, such as temporary files and crash dumps.</p>\n<p>Directory listings themselves do not necessarily constitute a security vulnerability. Any sensitive resources within the web root should in any case be properly access-controlled, and should not be accessible by an unauthorized party who happens to know or guess the URL. Even when directory listings are disabled, an attacker may guess the location of sensitive files using automated tools.</p>",
        "remediation": "<p>There is not usually any good reason to provide directory listings, and disabling them may place additional hurdles in the path of an attacker. This can normally be achieved in two ways:</p>\n<ul>\n<li>Configure your web server to prevent directory listings for all paths beneath the web root; </li>\n<li>Place into each directory a default file (such as index.htm) that the web server will display instead of returning a directory listing.</li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/538.html\">CWE-538: File and Directory Information Exposure</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/548.html\">CWE-548: Information Exposure Through Directory Listing</a></li>\n</ul>"
    },
    {
        "issue_type_id": "6291968",
        "name": "Email addresses disclosed",
        "description": "<p>The presence of email addresses within application responses does not necessarily constitute a security vulnerability. Email addresses may appear intentionally within contact information, and many applications (such as web mail) include arbitrary third-party email addresses within their core content.</p>\n<p>However, email addresses of developers and other individuals (whether appearing on-screen or hidden within page source) may disclose information that is useful to an attacker; for example, they may represent usernames that can be used at the application's login, and they may be used in social engineering attacks against the organization's personnel. Unnecessary or excessive disclosure of email addresses may also lead to an increase in the volume of spam email received.</p>",
        "remediation": "<p>Consider removing any email addresses that are unnecessary, or replacing personal addresses with anonymous mailbox addresses (such as helpdesk@example.com).</p>\n<p>To reduce the quantity of spam sent to anonymous mailbox addresses, consider hiding the email address and instead providing a form that generates the email server-side, protected by a CAPTCHA if necessary. </p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/200.html\">CWE-200: Information Exposure</a></li>\n</ul>"
    },
    {
        "issue_type_id": "6292224",
        "name": "Private IP addresses disclosed",
        "description": "<p>RFC 1918 specifies ranges of IP addresses that are reserved for use in private networks and cannot be routed on the public Internet. Although various methods exist by which an attacker can determine the public IP addresses in use by an organization, the private addresses used internally cannot usually be determined in the same ways.</p>\n<p>Discovering the private addresses used within an organization can help an attacker in carrying out network-layer attacks aiming to penetrate the organization's internal infrastructure. </p>",
        "remediation": "<p>There is not usually any good reason to disclose the internal IP addresses used within an organization's infrastructure. If these are being returned in service banners or debug messages, then the relevant services should be configured to mask the private addresses. If they are being used to track back-end servers for load balancing purposes, then the addresses should be rewritten with innocuous identifiers from which an attacker cannot infer any useful information about the infrastructure.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/200.html\">CWE-200: Information Exposure</a></li>\n</ul>"
    },
    {
        "issue_type_id": "6292480",
        "name": "Social security numbers disclosed",
        "description": "<p>Applications sometimes disclose sensitive personal information such as social security numbers. Responses containing social security numbers may not represent any security vulnerability - for example, a number may belong to the logged-in user to whom it is displayed. If a social security number is identified during a security assessment it should be verified, then application logic reviewed to identify whether its disclosure within the application is necessary and appropriate.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/200.html\">CWE-200: Information Exposure</a></li>\n</ul>"
    },
    {
        "issue_type_id": "6292736",
        "name": "Credit card numbers disclosed",
        "description": "<p>Applications sometimes disclose sensitive financial information such as credit card numbers. Responses containing credit card numbers may not represent any security vulnerability - for example, a number may belong to the logged-in user to whom it is displayed. If a credit card number is identified during a security assessment it should be verified, then application logic reviewed to identify whether its disclosure within the application is necessary and appropriate.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/200.html\">CWE-200: Information Exposure</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/312.html\">CWE-388: Error Handling</a></li>\n</ul>"
    },
    {
        "issue_type_id": "6292816",
        "name": "Private key disclosed",
        "description": "<p>Disclosure of valid private keys may lead to unauthorized access to any systems that use them for authentication. Verify whether any keys disclosed are actually valid, and whether their disclosure within the application is appropriate.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/200.html\">CWE-200: Information Exposure</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/312.html\">CWE-388: Error Handling</a></li>\n</ul>"
    },
    {
        "issue_type_id": "6292992",
        "name": "Robots.txt file",
        "description": "<p>The file robots.txt is used to give instructions to web robots, such as search engine crawlers, about locations within the web site that robots are allowed, or not allowed, to crawl and index.</p>\n<p>The presence of the robots.txt does not in itself present any kind of security vulnerability. However, it is often used to identify restricted or private areas of a site's contents. The information in the file may therefore help an attacker to map out the site's contents, especially if some of the locations identified are not linked from elsewhere in the site. If the application relies on robots.txt to protect access to these areas, and does not enforce proper access control over them, then this presents a serious vulnerability.</p>",
        "remediation": "<p>The robots.txt file is not itself a security threat, and its correct use can represent good practice for non-security reasons. You should not assume that all web robots will honor the file's instructions. Rather, assume that attackers will pay close attention to any locations identified in the file. Do not rely on robots.txt to provide any kind of protection over unauthorized access.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/200.html\">CWE-200: Information Exposure</a></li>\n</ul>"
    },
    {
        "issue_type_id": "7340288",
        "name": "Cacheable HTTPS response",
        "description": "<p>Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time.</p>",
        "remediation": "<p>Applications should return caching directives instructing browsers not to store local copies of any sensitive data. Often, this can be achieved by configuring the web server to prevent caching for relevant paths within the web root. Alternatively, most web development platforms allow you to control the server's caching directives from within individual scripts. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content:</p>\n<ul>\n<li>Cache-control: no-store</li><li>Pragma: no-cache</li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/524.html\">CWE-524: Information Exposure Through Caching</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/525.html\">CWE-525: Information Exposure Through Browser Caching</a></li>\n</ul>"
    },
    {
        "issue_type_id": "7340544",
        "name": "Base64-encoded data in parameter",
        "description": "<p>Applications sometimes Base64-encode parameters in an attempt to obfuscate them from users or facilitate transport of binary data. The presence of Base64-encoded data may indicate security-sensitive information or functionality that is worthy of further investigation. The data should be reviewed to determine whether it contains any interesting information, or provides any additional entry points for malicious input.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/310.html\">CWE-310: Cryptographic Issues</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/311.html\">CWE-311: Missing Encryption of Sensitive Data</a></li>\n</ul>"
    },
    {
        "issue_type_id": "8388864",
        "name": "Multiple content types specified",
        "description": "<p>If a  response specifies multiple incompatible content types, then the browser will usually analyze the response and attempt to determine the actual MIME type of its content. This can have unexpected results, and if the content contains any user-controllable data may lead to cross-site scripting or other client-side vulnerabilities.</p>\n<p>In most cases, the presence of multiple incompatible content type statements does not constitute a security flaw, particularly if the response contains static content. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists. </p>",
        "remediation": "<p>For every response containing a message body, the application should include a single Content-type header that correctly and unambiguously states the MIME type of the content in the response body.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/436.html\">CWE-436: Interpretation Conflict</a></li>\n</ul>"
    },
    {
        "issue_type_id": "8389120",
        "name": "HTML does not specify charset",
        "description": "<p>If a  response states that it contains HTML content but does not specify a character set, then the browser may analyze the HTML and attempt to determine which character set it appears to be using. Even if the majority of the HTML actually employs a standard character set such as UTF-8, the presence of non-standard characters anywhere in the response may cause the browser to interpret the content using a different character set. This can have unexpected results, and can lead to cross-site scripting vulnerabilities in which non-standard encodings like UTF-7 can be used to bypass the application's defensive filters.</p>\n<p>In most cases, the absence of a charset directive does not constitute a security flaw, particularly if the response contains static content. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists. </p>",
        "remediation": "<p>For every response containing HTML content, the application should include within the Content-type header a directive specifying a standard recognized character set, for example <b>charset=ISO-8859-1</b>.\n</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/436.html\">CWE-436: Interpretation Conflict</a></li>\n</ul>"
    },
    {
        "issue_type_id": "8389376",
        "name": "HTML uses unrecognized charset",
        "description": "<p>Applications may specify a non-standard character set as a result of typographical errors within the code base, or because of intentional usage of an unusual character set that is not universally recognized by browsers. If the browser does not recognize the character set specified by the application, then the browser may analyze the HTML and attempt to determine which character set it appears to be using. Even if the majority of the HTML actually employs a standard character set such as UTF-8, the presence of non-standard characters anywhere in the response may cause the browser to interpret the content using a different character set. This can have unexpected results, and can lead to cross-site scripting vulnerabilities in which non-standard encodings like UTF-7 can be used to bypass the application's defensive filters.</p>\n<p>In most cases, the absence of a valid charset directive does not constitute a security flaw, particularly if the response contains static content. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists. </p>",
        "remediation": "<p>For every response containing HTML content, the application should include within the Content-type header a directive specifying a standard recognized character set, for example <b>charset=ISO-8859-1</b>.\n</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/436.html\">CWE-436: Interpretation Conflict</a></li>\n</ul>"
    },
    {
        "issue_type_id": "8389632",
        "name": "Content type incorrectly stated",
        "description": "<p>If a  response specifies an incorrect content type then browsers may process the response in unexpected ways. If the  content type is specified to be a renderable text-based format, then the browser will usually attempt to interpret the response as being in that format, regardless of the actual contents of the response. Additionally, some other specified content types might sometimes be interpreted as HTML due to quirks in particular browsers. This behavior might lead to otherwise &quot;safe&quot; content such as images  being rendered as HTML, enabling cross-site scripting attacks in certain conditions.</p>\n<p>The presence of an incorrect content type statement typically only constitutes a security flaw when the affected resource is dynamically generated, uploaded by a user, or otherwise contains user input. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists.</p>",
        "remediation": "<p>For every response containing a message body, the application should include a single Content-type header that correctly and unambiguously states the MIME type of the content in the response body.</p>\n<p>Additionally, the response header &quot;X-content-type-options: nosniff&quot; should be returned in all responses to reduce the likelihood that browsers will interpret content in a way that disregards the Content-type header.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/436.html\">CWE-436: Interpretation Conflict</a></li>\n</ul>"
    },
    {
        "issue_type_id": "8389888",
        "name": "Content type is not specified",
        "description": "<p>If a  response does not specify a content type, then the browser will usually analyze the response and attempt to determine the MIME type of its content. This can have unexpected results, and if the content contains any user-controllable data may lead to cross-site scripting or other client-side vulnerabilities.</p>\n<p>In most cases, the absence of a content type statement does not constitute a security flaw, particularly if the response contains static content. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists. </p>",
        "remediation": "<p>For every response containing a message body, the application should include a single Content-type header that correctly and unambiguously states the MIME type of the content in the response body.</p>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n</ul>"
    },
    {
        "issue_type_id": "16777472",
        "name": "SSL certificate",
        "description": "<p>SSL (or TLS) helps to protect the confidentiality and integrity of information in transit between the browser and server, and to provide authentication of the server's identity. To serve this purpose, the server must present an SSL certificate that is valid for the server's hostname, is issued by a trusted authority and is valid for the current date. If any one of these requirements is not met, SSL connections to the server will not provide the full protection for which SSL is designed.</p>\n<p>It should be noted that various attacks exist against SSL in general, and in the context of HTTPS web connections in particular. It may be possible for a determined and suitably-positioned attacker to compromise SSL connections without user detection even when a valid SSL certificate is used. </p>",
        "references": "<ul><li><a href=\"https://wiki.mozilla.org/Security/Server_Side_TLS\">SSL/TLS Configuration Guide</a></li></ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/295.html\">CWE-295: Improper Certificate Validation</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/326.html\">CWE-326: Inadequate Encryption Strength</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/327.html\">CWE-327: Use of a Broken or Risky Cryptographic Algorithm</a></li>\n</ul>"
    },
    {
        "issue_type_id": "16777728",
        "name": "Unencrypted communications",
        "description": "<p>The application allows users to connect to it over unencrypted connections.  An attacker suitably positioned to view a legitimate user's network traffic could record and monitor their interactions with the application and obtain any information the user supplies. Furthermore, an attacker able to modify traffic could use the application as a platform for attacks against its users and third-party websites. Unencrypted connections have been exploited by ISPs and governments to track users, and to inject adverts and malicious JavaScript. Due to these concerns, web browser vendors are planning to visually flag unencrypted connections as hazardous.</p>\n<p>\nTo exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.\n</p>\n<p>Please note that using a mixture of encrypted and unencrypted communications is an ineffective defense against active attackers, because they can easily remove references to encrypted resources when these references are transmitted over an unencrypted connection.</p>",
        "remediation": "<p>Applications should use transport-level encryption (SSL/TLS) to protect all communications passing between the client and the server. The Strict-Transport-Security HTTP header should be used to ensure that clients refuse to access the server over an insecure connection.</p>",
        "references": "<ul>\n<li><a href=\"https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure\">Marking HTTP as non-secure</a></li>\n<li><a href=\"https://wiki.mozilla.org/Security/Server_Side_TLS\">Configuring Server-Side SSL/TLS</a></li>\n<li><a href=\"https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security\">HTTP Strict Transport Security</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/326.html\">CWE-326: Inadequate Encryption Strength</a></li>\n</ul>"
    },
    {
        "issue_type_id": "16777984",
        "name": "Strict transport security not enforced",
        "description": "<p> The application fails to prevent users from connecting  to it over unencrypted connections.  An attacker able to modify a legitimate user's network traffic could bypass the application's use of SSL/TLS encryption, and use the application as a platform for attacks against its users. This attack is performed by rewriting HTTPS links as HTTP, so that if a targeted user follows a link to the site from an HTTP page, their browser never attempts to use an encrypted connection. The sslstrip tool  automates this process. </p>\n<p>\nTo exploit this vulnerability, an attacker must be suitably positioned to intercept and modify the victim's network traffic.This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure. </p>",
        "remediation": "<p>The application should instruct web browsers to only access the application using HTTPS. To do this, enable HTTP Strict Transport Security (HSTS) by adding a response header with the name 'Strict-Transport-Security' and the value 'max-age=expireTime', where expireTime is the time in seconds that browsers should remember that the site should only be accessed using HTTPS. Consider adding the 'includeSubDomains' flag if appropriate.</p>\n<p>Note that because HSTS is a &quot;trust on first use&quot; (TOFU) protocol, a user who has never accessed the application will never have seen the HSTS header, and will therefore still be vulnerable to SSL stripping attacks. To mitigate this risk, you can optionally add the 'preload' flag to the HSTS header, and submit the domain for review by browser vendors.</p>",
        "references": "<ul>\n<li><a href=\"https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security\">HTTP Strict Transport Security</a></li>\n<li><a href=\"http://www.thoughtcrime.org/software/sslstrip/\">sslstrip</a></li>\n<li><a href=\"https://hstspreload.appspot.com/\">HSTS Preload Form</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/523.html\">CWE-523: Unprotected Transport of Credentials</a></li>\n</ul>"
    },
    {
        "issue_type_id": "16778240",
        "name": "Mixed content",
        "description": "<p>The application loads pages over HTTPS that load other resources over unencrypted connections. An attacker suitably positioned to view a legitimate user's network traffic could record and monitor their interactions with these resources, which may indirectly disclose information about the user's activity on the application itself. Furthermore, an attacker able to modify traffic could alter these resources and potentially influence the application's appearance and behavior. Due to these concerns, users' web browsers may automatically display warnings and disable affected components of the page. As a result, this vulnerability currently has more of an impact on usability than security.</p><p>To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.</p>",
        "remediation": "<p>Ensure that all external resources the page references are loaded using HTTPS.</p>",
        "references": "<ul>\n<li><a href=\"https://developer.mozilla.org/en/docs/Security/MixedContent\">Mixed Content</a></li>\n</ul>",
        "vulnerability_classifications": "<ul>\n<li><a href=\"https://cwe.mitre.org/data/definitions/16.html\">CWE-16: Configuration</a></li>\n<li><a href=\"https://cwe.mitre.org/data/definitions/319.html\">CWE-319: Cleartext Transmission of Sensitive Information</a></li>\n</ul>"
    },
    {
        "issue_type_id": "134217728",
        "name": "Extension generated issue",
        "description": "<p>This type of issue is used for custom issues that are generated by Burp Suite extensions.</p>"
    }
]