OWASP_WSTG_ASVS_en.json

[
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/01-Information_Gathering/01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information indexed in web search engines or other public sources",
                "vulnType": "OWASP WSTG",
                "description": "<p>Search engines can be used to perform recognition of web sites and applications. There are direct and indirect elements to search engine discovery and recognition: direct methods are related with searching the indexes and associated content of caches, while indirect methods are related with learning sensitive information about the layout and configuration by searching in forums, newsgroups, and websites.</p><p>By using search engines such as Google, DuckDuckGo or Bing it is possible to find potentially sensitive information such as:</p><ul><li><p>Network diagrams and configurations.</p></li><li><p>Archived messages and emails from administrators or other key personnel.</p></li><li><p>Login procedures and username formats.</p></li><li><p>User names, passwords and private keys.</p></li><li><p>Configuration files from third parties or cloud services.</p></li><li><p>Content of revealing error messages.</p></li><li><p>Development versions, tests, user acceptance tests (UAT) and test versions of the applications.</p></li></ul>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>Before publishing an application, it is essential to consider the sensitivity of the data exposed in it in order to prevent accidental disclosures of sensitive information.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server",
                    "https://cwe.mitre.org/data/definitions/200.html",
                    "https://wiki.owasp.org/index.php/Testing_for_Web_Application_Fingerprint_(OWASP-IG-004)"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information in HTTP headers",
                "vulnType": "OWASP WSTG",
                "description": "<p>This situation occurs when the application reveals the type and/or version of an internal component being used by revealing information in the HTTP protocol headers. Through this information, the operating system, one of its services (web, mail, file transfer...), or one of its components (PHP, mod_proxy, WebDAV...) can be revealed.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>To prevent this kind of information disclosure, it is necessary to conceal the information displayed in the protocol headers.To prevent this kind of information disclosure, it is necessary to conceal the information displayed in the protocol headers.</p><p>A fix, which is typically an update to it or the application of a specific patch, is typically necessary to fix the published vulnerabilities of the detected components and requires adhering to the recommendations of the maker of the vulnerable software to resolve the vulnerabilities.</p><p>It would be necessary to decide whether to stop offering the service until a solution was found or take the chance of doing so even in the absence of a published solution.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/08-Fingerprint_Web_Application_Framework"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information in application cookies",
                "vulnType": "OWASP WSTG",
                "description": "<p>The configuration of the cookies exposes sensitive information in both the cookie's pre-established name and its content, which leads to this vulnerability. For instance, a cookie with the name of the software it was created with.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>To prevent this kind of information disclosure, it is necessary to either hide the data displayed in the cookies or alter their name or content.</p><p>In order to fix the publicly disclosed vulnerabilities of the detected components, it is typically necessary to follow the manufacturer's recommendations for resolving the vulnerabilities, a solution which typically entails an update of the software or the application of a particular patch.</p><p>It would be necessary to decide whether to stop offering the service until a solution was found or take the chance of doing so even in the absence of a published solution.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/03-Review_Webserver_Metafiles_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html",
                    "https://developers.google.com/search/docs/advanced/robots/intro"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information in the 'robots.txt' file",
                "vulnType": "OWASP WSTG",
                "description": "<p>Some programs use spider bots to automatically browse websites in an effort to index them. Any user can access the \"robots.txt\" file, which is used to specify directories and resources that the administrator wants to be indexed and those that he or she does not. The configuration of this file needs to be handled with extra caution because it may reveal which resources are sensitive.</p><p>The \"robots.txt\" file contains sensitive resources that could be used by an attacker to launch more sophisticated and precise attacks using the data gathered.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>The 'robots.txt' file shouldn't be used as a method of restricting access to the application's insecure areas. Beyond their protection from spider-type robots, access to these sections must be properly controlled against potential attacks.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/03-Review_Webserver_Metafiles_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information in the 'sitemap.xml' file",
                "vulnType": "OWASP WSTG",
                "description": "<p>A developer or organization can provide details about the resources available in the application and their connections in the \"sitemap.xml\" file.</p><p>The \"sitemap.xml\" file contains sensitive resources that can be used by an attacker to launch more advanced and precise attacks using the data they have gathered.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>It is advised to delete any sensitive data from the \"sitemap.xml\" file that is not required for the application's development.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/03-Review_Webserver_Metafiles_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information in the 'security.txt' file",
                "vulnType": "OWASP WSTG",
                "description": "<p>A proposed standard allows web pages to specify security policies and contact information in the \"security.txt\" file.</p><p>The \"security.txt\" file contains sensitive information that could be used by an attacker to launch more sophisticated and precise attacks using the data gathered.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>It is advised to delete all private data from the \"security.txt\" file that is not required for the application's development.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/03-Review_Webserver_Metafiles_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information in the 'humans.txt' file",
                "vulnType": "OWASP WSTG",
                "description": "<p>The \"humans.txt\" file is a project to learn more about the people who create a website.</p><p>The \"humans.txt\" file contains sensitive information that could be used by an attacker to launch more sophisticated and precise attacks using the data gathered.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>It is advised to delete all private data from the \"humans.txt\" file that isn't necessary for the application's development.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Webpage_Content_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/540.html"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information in the source code",
                "vulnType": "OWASP WSTG",
                "description": "<p>This situation arises when analyzing a file that has been uploaded to a web server reveals server-related information that can be used to plan new attacks, such as the type and version of applications being used, components or extensions that are in use, credentials...</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>To prevent sensitive information leaks, the HTML source code that the server sends must be modified.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/497.html"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information because debug mode is enabled",
                "vulnType": "OWASP WSTG",
                "description": "<p>It is occasionally possible to display technical data or trade secrets within the application by using a \"enabling debug parameter.\" As a result, the attacker increases the size of his attack surface by learning more about how the application works. Enabling the debug flag might occasionally even result in code execution attacks (older versions of werkzeug)</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>Production applications shouldn't ever generate internal information like stack traces and error messages unless they directly commit it to a log that the end user cannot see. Before being written to the log file, all error message text should be HTML entity encoded to prevent potential cross-site scripting attacks against the log viewer.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Webpage_Content_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information (generic)",
                "vulnType": "OWASP WSTG",
                "description": "<p>A password, for example, is a sensitive piece of information that can be valuable on its own or be used to launch other, more serious attacks (such as obtaining an uncontrolled error message). Error message content can be used by an attacker to support the launch of a different, more focused attack. An attempt to exploit a directory enumeration or path traversal flaw, for instance, might reveal the complete path to the installed application.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>Create \"safe\" areas within the system where trust boundaries can be clearly defined. Allow no sensitive information to cross the lines of trust, and exercise extreme caution whenever interacting with a compartment outside of a secure area.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/200.html",
                    "https://cwe.mitre.org/data/definitions/359.html"
                ],
                "locale": "en",
                "title": "Disclosure of credentials (credentials leak)",
                "vulnType": "OWASP WSTG",
                "description": "<p>It has been possible to verify and check the existence of files containing sensitive information, such as valid credentials for accessing other systems, at a variety of endpoints. There is no need for any kind of cookie or earlier authentication system to access these credentials.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>Regardless of the software these user credentials are used for, it is never advised to expose sensitive files that expose user credentials.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/798.html"
                ],
                "locale": "en",
                "title": "Use of Hard-coded Credentials",
                "vulnType": "OWASP WSTG",
                "description": "<p>For its own internal data encryption, outbound communication with external components, and inbound authentication, the software has hard-coded credentials, such as a password or cryptographic key. Hard-coded credentials frequently produce a sizable security gap that enables an attacker to get around the authentication settings that the software administrator has set up.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: If hard-coded passwords are used, it is almost certain that malicious users will gain access to the account in question.</p></li><li><p>Access Control: Execute Unauthorized Code or Commands: This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.</p></li></ul>",
                "remediation": "<p>Instead of static API secrets and keys, use session tokens.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Webpage_Content_for_Information_Leakage",
                    "https://cwe.mitre.org/data/definitions/200.html",
                    "https://capec.mitre.org/data/definitions/118.html"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information in the metadata of files available in the application",
                "vulnType": "OWASP WSTG",
                "description": "<p>The term \"metadata\" refers to information about a document that is primarily descriptive in nature. Information about administration and management may also be included.</p><p>The collection of data that characterizes or defines a particular piece of information that they are linked to is known as metadata. By enhancing the information they are linked to, metadata make a computer's interpretation of that information much more thorough and enhance document retrieval.</p><p>Through its metadata, they have been found to have been used to extract sensitive information.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>It is advised that all files available in the application should have their metadata removed before being made accessible to the network in order to address this vulnerability.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/04-Enumerate_Applications_on_Webserver",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/08-Fingerprint_Web_Application_Framework"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information in default content",
                "vulnType": "OWASP WSTG",
                "description": "<p>This occurs when default files are left open after the installation of a service or application. Due to the type of information they divulge, such as the type and version of the Web server being used, the existence of default files on a Web server poses a threat.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>In order to fix it, all default files that are not required for the server's operation must be removed, including the default pages that were installed after the server.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/04-Enumerate_Applications_on_Webserver",
                    "https://cwe.mitre.org/data/definitions/538.html",
                    "https://www.owasp.org/index.php/Full_Path_Disclosure"
                ],
                "locale": "en",
                "title": "Disclosure of internal server paths and directories",
                "vulnType": "OWASP WSTG",
                "description": "<p>This fact arises whenever the absolute path of a web server or an application hosted on it can be determined using any mechanism, such as by sending an error message, tracking the sending of parameters, etc.</p><p>The server's absolute directory, where the web content is stored, can be found.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>Depending on the kind of flaw that led to the disclosure, the best course of action will vary. If it was obtained following an error message, it is essential to swap out these server error messages with a generic message that merely reports an abnormal situation without going into further detail regarding its cause. It is necessary to alter the application logic so that only relative paths are displayed or not at all if that path has been made public by an application parameter.</p><p>It is advised to swap out the server error messages for a generic message that simply states that something is abnormal without going into further detail as to why.</p><p>The configuration file must be used in order to accomplish this.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Information Gathering",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/04-Enumerate_Applications_on_Webserver",
                    "https://cwe.mitre.org/data/definitions/548.html"
                ],
                "locale": "en",
                "title": "Directory listing",
                "vulnType": "OWASP WSTG",
                "description": "<p>Directory listing is a feature that, when enabled, causes web servers to list the contents of a directory when no index file (eg index.php or index.html) is present. Therefore, if a request is made to a directory where directory listing is enabled, and there is no index file, even if there are files from a web application, the web server sends a directory listing as a response.</p><p>When this happens there is a data leakage problem, and attackers can use this data to build other attacks, including direct hit vulnerabilities like XSS. This can be useful in development environments but is not a good practice for production servers.</p><p>The fact that a web server allows listing a directory has several security implications:</p><ul><li><p>Allows users to download certain files or access certain directories that would not otherwise be possible.</p></li><li><p>It can display information that helps an attacker find out technical details about the web server.</p></li><li><p>Shows all the contents of the directory, without discriminating between files that can be public, and those that should remain private.</p></li></ul><p>This is often accidental, as a default web server displays a directory listing in case the index file is invalid or does not exist.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Files or Directories: Exposing the contents of a directory can lead to an attacker gaining access to source code or providing useful information for the attacker to devise exploits, such as creation times of files or any information that may be encoded in file names. The directory listing may also compromise private or confidential data.</p></li></ul>",
                "remediation": "<p>Configure properly. The web servers, whether NGINX, Apache, or IIS, must be set up so that neither the directory listing nor user navigation through the paths is permitted.For instance, on an Apache web server, you need to create an.htaccess file in the appropriate application directory to disable directory listing. The following lines can be added to the httpd.conf file or swapped out for the ones already there:</p><p><Directory /{YOUR DIRECTORY}>Options FollowSymLinks</Directory></p><p>As you can see from the sample code above, in order to safely disable the directory listing feature on an Apache web server, you must remove the Indexes and MultiViews statements.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/04-Enumerate_Applications_on_Webserver",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/04-Testing_for_Weak_Encryption",
                    "https://cwe.mitre.org/data/definitions/311.html",
                    "https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html",
                    "https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html",
                    "https://wiki.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)"
                ],
                "locale": "en",
                "title": "Absence of SSL/TLS encryption",
                "vulnType": "OWASP WSTG",
                "description": "<p>Instead of the HTTPs protocol, HTTP is used to communicate with the web server. To stop an attacker from reading or altering the data sent between the client and server, it must be encrypted and protected. The most common method for doing this is through HTTPS, which substitutes the Secure Socket Layer (SSL) protocol for the Transport Layer Security (TLS) protocol. By displaying a trusted digital certificate, the server can use TLS to show the client that it is connected to the right server.</p><p>Over the years, a large number of cryptographic weaknesses have been identified in the SSL and TLS protocols, as well as in the ciphers they use. In addition, many of the implementations of these protocols have also had serious vulnerabilities. Therefore, it is important to check that sites are not only implementing TLS, but that they are doing so in a secure manner.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: An attacker may be able to decrypt the data using brute force attacks.</p></li></ul>",
                "remediation": "<p>The web server must be configured in order to support HTTPs. Additionally, it is practical to use the HSTS header and switch all HTTP requests to the HTTPs protocol.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/03-Testing_for_Sensitive_Information_Sent_via_Unencrypted_Channels",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/319.html",
                    "https://capec.mitre.org/data/definitions/117.html"
                ],
                "locale": "en",
                "title": "Mixed content",
                "vulnType": "OWASP WSTG",
                "description": "<p>Content uploaded using the HTTP protocol is used by the web application, which uses the HTTPs protocol. Since any data uploaded via HTTP can be intercepted and altered by an attacker, this practice is regarded as being insufficient.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>The web server must be configured in order to support HTTPs. Additionally, it is practical to use the HSTS header and switch all HTTP requests to the HTTPs protocol.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/04-Testing_for_Weak_Encryption",
                    "https://cwe.mitre.org/data/definitions/310.html",
                    "https://cwe.mitre.org/data/definitions/327.html"
                ],
                "locale": "en",
                "title": "Weak Encryption algorithms",
                "vulnType": "OWASP WSTG",
                "description": "<p>Numerous flaws in the web server's configuration of the SSL/TLS service could lead to insecure communication between the client and the server.</p><p>The encryption algorithms used by the SSL/TLS service running on the server are regarded as being weak or having known vulnerabilities.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li><li><p>Access Control: Modify Application Data: An attacker can trick a user into performing actions that are masked and hidden from the user's view. The impact varies widely, depending on the functionality of the underlying application. For example, in a social media application, clickjacking could be used to trik the user into changing privacy settings.</p></li></ul>",
                "remediation": "<p>Allow only TLS connections with encryption that is regarded as secure in versions 1.2 or 1.3.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security",
                    "https://cwe.mitre.org/data/definitions/326.html"
                ],
                "locale": "en",
                "title": "Use of Obsolete SSL/TLS Protocol Versions",
                "vulnType": "OWASP WSTG",
                "description": "<p>To stop an attacker from reading or altering the data sent between the client and server, it must be encrypted and protected. The most popular method for doing this is HTTPS, which substitutes the outdated Secure Socket Layer (SSL) protocol with the Transport Layer Security (TLS) protocol. By displaying a trusted digital certificate, the server can use TLS to show the client that it is connected to the right server.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>On the web server, insecure variants of the SSL/TLS protocol must be disabled.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security"
                ],
                "locale": "en",
                "title": "Secure Client-Initiated Renegotiation",
                "vulnType": "OWASP WSTG",
                "description": "<p>On the server side compared to the client side, more resources are used during SSL/TLS connection negotiation. In the event that the server permits the client to request a connection renegotiation, an attacker might take advantage of this feature to send out numerous negotiation requests, using up server resources and possibly resulting in a denial of service (DoS).</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>To address the vulnerability, it is advised to apply the most recent patch. It is essential to update to version 0.9.8l or later on systems running OpenSSL. On the other hand, it is also possible to disable the client's initiation of renegotiation as a mitigation without the need for an update.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/04-Testing_for_Weak_Encryption",
                    "https://cwe.mitre.org/data/definitions/16.html"
                ],
                "locale": "en",
                "title": "Untrusted Digital Certificate",
                "vulnType": "OWASP WSTG",
                "description": "<p>The server's digital certificate is insecure and unreliable due to some incorrect parameters, which increases the risk of confidentiality or dependability to the system.</p>",
                "observation": "<ul><li><p>Other: Technical Impact: Varies by Context</p></li></ul>",
                "remediation": "<p>It is advised to create a digital certificate that browsers recognize as reliable (issued by a recognized authority, within the validity period and with the common name of the certificate equal to the name of the Web site offering the services).</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/299.html"
                ],
                "locale": "en",
                "title": "Improper check for certificate revocation (OCSP Stapling)",
                "vulnType": "OWASP WSTG",
                "description": "<p>To stop man-in-the-middle attacks on users of your applications, you should always be able to quickly recall these certificates whenever your certificate authority loses trust.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: Trust may be assigned to an entity who is not who it claims to be.</p></li><li><p>Other: Other: Data from an untrusted (and possibly malicious) source may be integrated.</p></li><li><p>Confidentiality: Read Application Data: Data may be disclosed to an entity impersonating a trusted entity, resulting in information disclosure.</p></li></ul>",
                "remediation": "<p>The keyset file on the secure signing computer, which is also where the signed and unsigned copies of the zone are stored, contains the trust anchor for the given zone. The signing procedure includes an automatic creation of this file.</p><p>A certificate revocation list (CRL) is a list, created and signed by a certificate authority (CA), which contains serial numbers of certificates that have been issued by that CA and are currently revoked. In addition to the serial number of the revoked certifications, the CRL also contains the reason for revocation for each certificate and the time the certificate was revoked. The serial number for each revoked certificate is kept in the CAs database and published in the CRL until the certificate expires.</p><p>The CRL entry for the revoked certificate is deleted once it has expired, and the CA is then free to delete the certificate from its database. The revoked certificate typically remains in the CRL for one publication period following the expiration of the certificate. You should always have access to this knowledge so that you can act quickly.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "SSL/TLS encryption",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/299.html"
                ],
                "locale": "en",
                "title": "CA certificates",
                "vulnType": "OWASP WSTG",
                "description": "<p>An organization that issues digital certificates is known as a certificate authority (CA) in the field of cryptography. A digital certificate attests to the named subject of the certificate's ownership of a public key. A CA can occasionally fail and be removed from the browser. If your application uses a certificate issued by this CA, this will result in untrusted TLS connections.</p><p>An identity certificate that is signed by the same entity whose identity it certifies is known as a self-signed certificate. This phrase has nothing to do with who or what was responsible for carrying out the signing process. A self-signed certificate is one that was signed using a private key that belongs to the issuer.</p><p>In typical public key infrastructure (PKI) arrangements, a digital signature from a certificate authority (CA) attests that a particular public key certificate is valid. Each CA has one or more root keys; and the certificates associated with those public keys are \"\"trust anchors\"\" that use a special type of self-signed certificates. Establishing trust of the CA root certificate is dependent upon procedures beyond checking its digital signature.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: Trust may be assigned to an entity who is not who it claims to be.</p></li><li><p>Other: Other: Data from an untrusted (and possibly malicious) source may be integrated.</p></li><li><p>Confidentiality: Read Application Data: Data may be disclosed to an entity impersonating a trusted entity, resulting in information disclosure.</p></li></ul>",
                "remediation": "<p>Install a trusted certificate from a reputable root CA on the server.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/306.html"
                ],
                "locale": "en",
                "title": "Ensure overall security",
                "vulnType": "OWASP WSTG",
                "description": "<p>Due to the fact that it receives a lot of attention during development, the primary authentication mechanism is frequently a good hardened functionality. This is typically not the case, though, for secondary authentication mechanisms like password-forget features or other alternate routes that could result in successful application authentication.</p>",
                "observation": "<ul><li><p>Other: Other: Exposing critical functionality essentially provides an attacker with the privilege level of that functionality. The consequences will depend on the associated functionality, but they can range from reading or modifying sensitive data, access to administrative or other privileged functionality, or possibly even execution of arbitrary code.</p></li></ul>",
                "remediation": "<p>Make sure that all account identity authentication features (like update profile, forgotten password, disabled/lost token, help desk, or IVR) that could allow you to regain access to your account are at least as secure against hacking as the main authentication method.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/01-Test_Network_Infrastructure_Configuration",
                    "https://cwe.mitre.org/data/definitions/477.html"
                ],
                "locale": "en",
                "title": "Outdated OS version (Known associated vulnerabilities)",
                "vulnType": "OWASP WSTG",
                "description": "<p>When the operating system version of the server running the application can be determined, this problem occurs.</p><p>Any type of information pertaining to the technology that underpins the web application should always be kept secret in order to hinder or outright prevent that once this information is known, targeted attacks against this software can be planned.</p>",
                "observation": "<ul><li><p>Other: Quality Degradation: The attacker is using a function that is no updated</p></li></ul>",
                "remediation": "<p>Updating the operating system to the most recent version is advised.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/01-Test_Network_Infrastructure_Configuration",
                    "https://cwe.mitre.org/data/definitions/477.html"
                ],
                "locale": "en",
                "title": "Outdated dependencies and libraries",
                "vulnType": "OWASP WSTG",
                "description": "<p>Security researchers report and store vulnerabilities they find in libraries, modules, frameworks, platforms, or operating systems in the CVE list. Given that the list is available to everyone, it provides access for any attacker aiming to compromise an outdated web application.</p>",
                "observation": "<ul><li><p>Other: Reduce Maintainability: The attacker could find vulnerabilities of outdated components and use those to exploit new attack vectors.</p></li></ul>",
                "remediation": "<p>The main piece of advice is to always use the most recent dependencies and libraries that the manufacturer offers. Additionally, it is strongly advised to use tools like OWASP dependency check when running the application's libraries and modules through the SDLC. This program scans imported libraries and modules for known CVEs.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces",
                    "https://cwe.mitre.org/data/definitions/16.html"
                ],
                "locale": "en",
                "title": "Identification of management panels",
                "vulnType": "OWASP WSTG",
                "description": "<p>It is not advised for the administration panels or authentication panels for various applications to be publicly accessible on the internet. Therefore, it would be convenient to restrict access to the administration or authentication panels to VPN (Virtual Private Network) connections whenever possible.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>It is advised to use VPNs to connect to the organization's resources instead of opening administration or authentication panels to the Internet.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces",
                    "https://cwe.mitre.org/data/definitions/16.html"
                ],
                "locale": "en",
                "title": "Server configuration not hardened",
                "vulnType": "OWASP WSTG",
                "description": "<p>Any part of the application stack, including the network services, platform, web server, application server, database, frameworks, custom code, pre-installed virtual machines, containers, or storage, is susceptible to security misconfiguration.</p><p>Attackers frequently gain unauthorized access to certain system data or functionality thanks to such flaws. Such flaws can occasionally compromise the entire system. The application and data protection requirements determine the business impact.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>Implementing secure installation procedures, such as:</p><ul><li><p>A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to setup a new secure environment.</p></li><li><p>A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.</p></li><li><p>A task to review and update the configurations appropriate to all security notes, updates and patches as part of the patch management process. In particular, review cloud storage permissions.</p></li><li><p>A segmented application architecture that provides effective, secure separation between components or tenants, with segmentation, containerization, or cloud security groups (ACLs).</p></li><li><p>Sending security directives to clients, e.g. Security Headers.</p></li><li><p>An automated process to verify the effectiveness of the configurations and settings in all environments.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/02-Test_Application_Platform_Configuration",
                    "https://cwe.mitre.org/data/definitions/532.html"
                ],
                "locale": "en",
                "title": "Sensitive information in accessible logs",
                "vulnType": "OWASP WSTG",
                "description": "<p>A log is a record of the activities taking place within the networks and systems of an organization. Logs are made up of log entries, and each entry in a log contains details about a specific event that has taken place in a system or network.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>It is recommended to keep logs in a separate location and not on the web server itself. This also facilitates the aggregation of logs from different sources that refer to the same application (such as those from a web server farm) and also facilitates log analysis (which can be CPU intensive) without affecting the server itself. </p><p>It is also recommended to implement a log rotation ensuring that:</p><ul><li><p>Logs are kept for the time defined in the security policy, no more and no less.</p></li><li><p>Logs are compressed once rotated (this is a convenience, as it will mean that more logs will be stored for the same available disk space).</p></li><li><p>The file system permissions of rotated log files are the same (or stricter) than those of the log files themselves. For example, web servers will need to write to the logs they use, but they do not actually need to write to the rotated logs, which means that the file permissions can be changed at rotation time to prevent the web server process from modifying them.</p></li><li><p>Some servers may rotate logs when they reach a certain size. If this happens, make sure that an attacker cannot force log rotation to hide his or her trail.</p></li></ul><p>Finally, implement access control so that the event log information is never visible to end users and analyze the logs periodically, for example based on error messages:</p><ul><li><p>Error messages 40x (not found). A large number of them coming from the same source could indicate that a CGI scanning tool is being used against the web server.</p></li><li><p>50x (server error) messages. These can be an indication that an attacker is abusing parts of the application that fail unexpectedly. For example, the early stages of a SQL injection attack will produce these error messages when the SQL query is not well constructed and its execution fails in the back end database.</p></li></ul><p>Statistics or log analysis should not be generated, or stored, on the same server that produces the logs. Otherwise, an attacker could, through a web server vulnerability or improper configuration, access them and retrieve information similar to that which would be revealed by the log files themselves.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information",
                    "https://cwe.mitre.org/data/definitions/200.html",
                    "https://cwe.mitre.org/data/definitions/530.html"
                ],
                "locale": "en",
                "title": "Backup file identification",
                "vulnType": "OWASP WSTG",
                "description": "<p>Files that are unrelated to the application but are created as a result of editing application files, after making backups while in use, or by leaving outdated or unreferenced files in the web tree are a significant source of vulnerability. On-the-fly editing and other administrative tasks on production web servers may unintentionally leave backup copies that were created automatically by the editor as they were being edited or by the administrator as they were compressing a group of files to create a backup.</p><p>Editing files may leave automatic backup copies of type .bak, .sav, .old, or ~. The web server does not have by default defined an interpretation for this type of files, so the result is usually either to display their contents or to proceed to download them.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>To remove the risk, it is necessary to delete the discovered backup file. It is necessary to routinely search the server for files with the extensions.bak,.bac,.sav,.old,.BAK,.BAC,.SAV,.OLD,.tar,.gz, and.tgz and remove them from the server in order to fix this type of defect generally.In order to avoid having the file downloaded or the contents of the file displayed by the browser, it is also advised to configure the web server to be able to understand these extensions.If the document root is on a file system that makes use of this technology, file system snapshots shouldn't be accessible via the web. Configure your web server to deny access to such directories, for example, in Apache a location directive like this should be used:</p><p><Location ~ \".snapshot\">Order deny,allowDeny from all</Location></p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods",
                    "https://cwe.mitre.org/data/definitions/16.html"
                ],
                "locale": "en",
                "title": "Insecure HTTP methods enabled",
                "vulnType": "OWASP WSTG",
                "description": "<p>A variety of techniques are available through HTTP to carry out operations on the web server (the HTTP 1.1 standard refers to them as methods, but they are also commonly described as verbs). Although GET and POST are by far the most popular ways to access data from a web server, HTTP also supports a number of additional, less well-known ways. If the web server is configured incorrectly, some of these could be used maliciously.</p>",
                "observation": "<ul><li><p>Other: Technical Impact: Varies by Context</p></li></ul>",
                "remediation": "<p>The methods that were determined to be superfluous in the server configuration must be deactivated.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "en",
                "title": "Lack of security HTTP headers",
                "vulnType": "OWASP WSTG",
                "description": "<p>Security headers are implemented as HTTP response headers that limit the potential for client-side vulnerability exploitation by instructing the browser how to behave in specific circumstances. The full security configuration needed to establish a secure connection with the client is not present in server responses.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li></ul>",
                "remediation": "<p>Implementation of all security HTTP headers in server responses is recommended. The recommended values are:</p><ul><li><p>Strict-Transport-Security (HSTS): max-age=31536000; includeSubDomains.</p></li><li><p>Content-Security-Policy: default-src https: 'self'.</p></li><li><p>X-XSS-Protection:1</p></li><li><p>X-Frame-Options: 'DENY' (if not possible, 'SAMEORIGIN').</p></li><li><p>X-Content-Type-Options: nosniff.</p></li><li><p>Cache-Control: no-store.</p></li><li><p>Referrer-Policy: 'no-referrer' (or 'same-origin').</p></li><li><p>Permissions-Policy: Define the minimum allowed functions and deny the others.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "en",
                "title": "Absence of HSTS (HTTP Strict Transport Security) header",
                "vulnType": "OWASP WSTG",
                "description": "<p>The \"strict transport security\" (HSTS) HTTP header is used to thwart attempts to intercept communications, cookies, etc. This mechanism allows a web server to declare that only secure HTTP connections—HTTP over TLS/SSL—are permitted for browser communication.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: An attacker could gain unauthorized access to the system by retrieving legitimate user's authentication credentials</p></li></ul>",
                "remediation": "<p>Define the HTTP Strict-Transport-Security header, which instructs the client browser to automatically redirect requests received via the HTTP protocol to the HTTPS secure protocol rather than using or forcing an insecure protocol.</p><p><Strict-Transport-Security: max-age=60000; includeSubDomains></p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "en",
                "title": "Absence of X-Frame-Options header",
                "vulnType": "OWASP WSTG",
                "description": "<p>A user is tricked into using functionality on a hidden website by clicking on some other content on a bogus website using the Clickjacking vulnerability. The method is based on embedding a hidden button or link, for instance, within an iframe, on an actionable, visible web page (or pages). The user's anticipated decoy web page's content is overlaid by the iframe.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: An attacker could gain privileges by modifying or reading critical data directly, or by accessing insufficiently-protected, privileged functionality.</p></li></ul>",
                "remediation": "<p>The X-Frame-Options header is supported by most contemporary web browsers. It is advised to set the web server up so that this header is enabled for all web pages. The SAMEORIGIN option should be used if the page is anticipated to contain only code from the server.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "en",
                "title": "Absence of Content Security Policy (CSP) header",
                "vulnType": "OWASP WSTG",
                "description": "<p>An HTTP response header that increases security is called Content-Security-Policy. With the help of this header, you can limit the resources that the browser can load, including JavaScript, CSS, and more.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: An attacker could gain privileges by modifying or reading critical data directly, or by accessing insufficiently-protected, privileged functionality.</p></li><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li><li><p>Confidentiality: Read Application Data: Data may be disclosed to an entity impersonating a trusted entity, resulting in information disclosure.</p></li><li><p>Access Control: Modify Application Data: An attacker can trick a user into performing actions that are masked and hidden from the user's view. The impact varies widely, depending on the functionality of the underlying application. For example, in a social media application, clickjacking could be used to trik the user into changing privacy settings.</p></li></ul>",
                "remediation": "<p>By including the Content-Security-Policy header in the HTTP response headers, which tells the browser to apply the desired policies, you can enable CSP on a website. </p><p>Content-Security-Policy: script-src https://example.com:*;&gt;</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "en",
                "title": "Absence of Cache Control header",
                "vulnType": "OWASP WSTG",
                "description": "<p>Directives for caching mechanisms are specified in the HTTP Cache-Control header.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li></ul>",
                "remediation": "<p>Create a Cache-Control header on your web server with the necessary instructions. The Pragma header value should be no-cache and the Cache-Control value should be no-cache, no-store if the page contains sensitive information.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "en",
                "title": "Absence of Pragma header",
                "vulnType": "OWASP WSTG",
                "description": "<p>The Pragma header is an implementation-specific header that can impact the request-response chain in a number of ways. When the HTTP/1.1 Cache-Control header is not yet present, it is used for backward compatibility with earlier HTTP/1.0 cache versions.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li></ul>",
                "remediation": "<p>The Cache-Control header is the ideal way to specify a caching policy when at least HTTP/1.1 is used in server responses. The header for Pragma can be removed.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy",
                    "https://cwe.mitre.org/data/definitions/16.html",
                    "https://cwe.mitre.org/data/definitions/693.html",
                    "https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project",
                    "https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration"
                ],
                "locale": "en",
                "title": "Absence of Feature Policy header",
                "vulnType": "OWASP WSTG",
                "description": "<p>Web developers can selectively enable, disable, and alter the behavior of specific APIs and web features in the browser by using the header Feature-Policy. Note that this header has been divided into a Permissions-Policy and a Document-Policy, and that it will be regarded as deprecated once all impacted features have been eliminated from the Feature-Policy.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li></ul>",
                "remediation": "<p>Below is an example of how to add the Feature-Policy header to web server responses: </p><p><Feature-Policy: vibrate 'self'; usermedia *; sync-xhr 'self' https://example.com></p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/116.html"
                ],
                "locale": "en",
                "title": "Absence of Referrer Policy header",
                "vulnType": "OWASP WSTG",
                "description": "<p>Requests made from a document, and for navigations away from that document are associated with a Referer header. While the header can be suppressed for links with the noreferrer link type, authors might wish to control the Referer header more directly for a number of reasons:</p><ul><li><p>Privacy: a social networking site has a profile page for each of its users, and users add hyperlinks from their profile page to their favorite bands.The social networking site might not wish to leak the user’s profile URL to the band web sites when other users follow those hyperlinks (because the profile URLs might reveal the identity of the owner of the profile).Some social networking sites, however, might wish to inform the band web sites that the links originated from the social networking site but not reveal which specific user’s profile contained the links.</p></li><li><p>Security: a web application uses HTTPS and a URL based session identifier. The web application might wish to link to HTTPS resources on other web sites without leaking the user’s session identifier in the URL. Alternatively, a web application may use URLs which themselves grant some capability. Controlling the referrer can help prevent these capability URLs from leaking via referrer headers.</p></li></ul><p>Note that there are other ways for capability URLs to leak, and controlling the referrer is not enough to control all those potential leaks.</p><ul><li><p>Trackback: a blog hosted over HTTPS might wish to link to a blog hosted over HTTP and receive trackback links.</p></li></ul>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li></ul>",
                "remediation": "<p>Referrer Policy How much referrer data, which is transmitted via the Referer header, should be included with requests is controlled by the HTTP header. The Referer header has a lot of good intentions, but it also has unfavorable effects on user security and privacy. The following values ought to be configured in the policy:</p><p>Referrer-Policy: no-referrerReferrer-Policy: same-origin</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/116.html"
                ],
                "locale": "en",
                "title": "Absence of X-Content-Type-Options header",
                "vulnType": "OWASP WSTG",
                "description": "<p>In order to safeguard against Reflective File Download and other types of injections, certain API callbacks must have security headers that are properly configured.</p><p>Additionally, confirm whether user input is reflected in the API response and whether it is dynamic. If so, in order to stop XSS and same origin method execution attacks, you must validate and encode the input.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li></ul>",
                "remediation": "<p>Sanitize your API's input; escaping is insufficient in this case; they should only permit alphanumeric. Make sure that X-Content-Type-Options are present in every API response. to stop the browser from interpreting files as something other than what the content type has declared, use nosniff (this helps prevent XSS if the page is interpreted as html or js).</p><p>Add</p><p>Content-Disposition: attachment; filename=\"filename.extension\"</p><p>with extension corresponding the file extension and contenttype, on APIs that are not going to be rendered</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/524.html"
                ],
                "locale": "en",
                "title": "Anti-Caching header (Server-side)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Anti-caching headers prevents sensitive data from being stored on reverse proxies, load balancers and application cache modules. By not implementing this headers correctly, sensitive information may be stored within the cache of these modules and may be exposed.Let's see two examples of improperly configured headers:Cache-Control: max-age=315360000, public: the response may be stored by any cacheCache-Control: private: the response may be stored by a browser's cache</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>This vulnerability will be reduced if the anti-caching headers are properly implemented. An appropriately used anti-caching header will resemble:</p><p>Cache-Control: no-storePragma: no-cache (only for backwards compatibility with HTTP/1.0 clients)</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/173.html"
                ],
                "locale": "en",
                "title": "Unsafe Content-Type header within the response",
                "vulnType": "OWASP WSTG",
                "description": "<p>Setting the proper content headers is crucial for strengthening the security of your applications because it lowers your exposure to drive-by download attacks and websites hosting user-uploaded content that, due to clever naming, MS Internet Explorer may mistake for executable or dynamic HTML files, creating security flaws.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li></ul>",
                "remediation": "<p>An example of a safe Content-type header would be:</p><p>Content-Type: text/html; charset=UTF8Content-Type: application/json;</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/09-Test_File_Permission",
                    "https://cwe.mitre.org/data/definitions/732.html"
                ],
                "locale": "en",
                "title": "Excessive file and directory permissions",
                "vulnType": "OWASP WSTG",
                "description": "<p>Giving a resource a permission setting that allows access to a larger group of users than necessary runs the risk of exposing sensitive data or allowing unauthorized individuals to change the resource. When the resource is connected to program configuration, execution, or sensitive user data, this is especially risky.</p><p>A clear example is an execution file that may be executed by unauthorized users. Another example is that account information or the value of a token to access an API (increasingly common in today's web services or microservices) may be stored in a configuration file whose permissions are set by default to be readable by everyone from the installation. This sensitive data can be exposed by malicious internal users or by a remote attacker who has compromised the service with other vulnerabilities, but has low privileges.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The injected code could access restricted data / files.</p></li><li><p>Confidentiality: Read Files or Directories: An attacker could read sensitive data, either by reading the data directly from a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.</p></li></ul>",
                "remediation": "<p>Setting file and directory permissions correctly will help to address this vulnerability by preventing unauthorized users from needlessly accessing vital resources.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
        "category": "Configuration and Deploy Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/770.html"
                ],
                "locale": "en",
                "title": "Allocation of Resources Without Limits or Throttling",
                "vulnType": "OWASP WSTG",
                "description": "<p>In contravention of the intended security policy for that actor, the software allocates a reusable resource or set of resources on the actor's behalf without imposing any limitations on the size or quantity of resources that can be allocated.</p>",
                "observation": "<ul><li><p>Availability: DoS: Resource Consumption (Other): When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource.</p></li></ul>",
                "remediation": "<p>Requirements</p><ul><li><p>Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviours are acceptable when resource allocation reaches limits.</p></li></ul><p>Architecture and Design- Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid 410.- Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.- Ensure that protocols have specific limits of scale placed on them.- For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid 602: Client-Side Enforcement of Server-Side Security. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.</p><p>Implementation- Assume all input is malicious. Use an \"accept known good\" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colours such as \"red\" or \"blue.\"- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Identity Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account",
                    "https://cwe.mitre.org/data/definitions/203.html",
                    "https://cwe.mitre.org/data/definitions/204.html",
                    "https://cwe.mitre.org/data/definitions/200.html"
                ],
                "locale": "en",
                "title": "Account (users) enumeration",
                "vulnType": "OWASP WSTG",
                "description": "<p>Due to configuration errors or intentional design choices, web applications frequently make it clear whether a username already exists on the system. For instance, when incorrect credentials are sent, the resulting message can sometimes indicate whether the username already exists in the system or whether the password was entered incorrectly. An attacker can use the information they have collected to compile a user list for the system. By employing a brute force attack or a default username and password attack, for instance, this information can be used to attack the web application.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li></ul>",
                "remediation": "<p>There are several recommendations to avoid this type of vulnerabilities. The best solution is to apply some or all of them as appropriate:</p><ul><li><p>Avoid using any public data (alias, email, etc.) as username to authenticate in the application. This data should be private and only known by the user.</p></li><li><p>During the development phase, optimize the user authentication process to avoid \"high\" response times during authentication.</p></li><li><p>Do not use informative messages that aid in guessing the existence of user names.</p></li><li><p>Avoid different behaviors in the web application depending on the existence of usernames.</p></li><li><p>Delegate the generation of usernames to the web application. The generator used should be completely random and never sequential since it would be predictable.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Identity Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/02-Test_User_Registration_Process",
                    "https://cwe.mitre.org/data/definitions/287.html"
                ],
                "locale": "en",
                "title": "Insecure user registration process",
                "vulnType": "OWASP WSTG",
                "description": "<p>The provision of system access to users is automated (or partially automated) by some web applications' user registration process. Depending on the system's security requirements, the identity requirements for access can range from positive identification to none at all. Due to the size of their user bases, many public applications completely automate the registration and provisioning processes. A hacker could use this vulnerability to control other user accounts, for example, if best practices are not followed when automating the registration process.</p>",
                "observation": "<ul><li><p>Access Control: Execute Unauthorized Code or Commands: This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.</p></li></ul>",
                "remediation": "<p>It is advised to put in place identification and verification requirements that are in line with the security requirements of the data that the credentials are protecting.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
        "category": "Identity Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/384.html"
                ],
                "locale": "en",
                "title": "The login functionality should always generate a new session id",
                "vulnType": "OWASP WSTG",
                "description": "<p>A new session cookie should be created by the application each time a user is successfully authenticated.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: The application does not invalidate any existing session identifier and gives an attacker the opportunity to steal authenticated sessions.</p></li></ul>",
                "remediation": "<p>After a successful login, the login functionality should always create (and use) a new session ID. This is done to stop an attacker from attacking your users using a session fixation attack.Some frameworks, such as.net applications, do not let you change the session ID when you log in. You could add an extra random cookie with a strong token on login whenever this issue arises and store the value in a session variable.</p><p>Now that authentication depends on more than just the session ID and the random cookie cannot be predicted or fixed by an attacker, you can compare the cookie value with the session variable to prevent session fixation.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Password_Policy",
                    "https://cwe.mitre.org/data/definitions/521.html"
                ],
                "locale": "en",
                "title": "Weaknesses in password policy",
                "vulnType": "OWASP WSTG",
                "description": "<p>All of the security features incorporated into the technological infrastructure can be exposed by a lax password policy. Without utilizing any other vulnerabilities, guessing a password would grant access to legitimate systems. It frequently occurs in the domains of large organizations, where the administrator's users with higher privileges are completely forgotten in favor of the regular users with restricted access to which a strict password policy is applied. In other words, in contrast to a user with limited privileges, an administrator user can use a password that is deemed weak. To make it simple for new users to connect, many services come with default usernames and passwords at first. The crucial step of changing this information is frequently overlooked, leaving the system accessible using what are known as the default credentials.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: As passwords age, the probability that they are compromised grows.</p></li><li><p>Access Control: Gain Privileges or Assume Identity: An attacker could easily guess user passwords and gain access user accounts.</p></li></ul>",
                "remediation": "<p>Establish a strong password policy that requires the user to:</p><ul><li><p>A minimum password length of 8 charactersUse all character types, including capital and lowercase letters, numbers, and special characters.</p></li><li><p>Making use of an effective encryption algorithm like AES-128 or SHA-256</p></li><li><p>Check to see if the blank password is prohibited.</p></li><li><p>Steer clear of using the user identifier (or any subset of it) as a password.- Regularly force the change.</p></li><li><p>Prevent users from using previous passwords.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/263.html"
                ],
                "locale": "en",
                "title": "No password rotation policy",
                "vulnType": "OWASP WSTG",
                "description": "<p>Some policies require users to change passwords periodically, often every 90 or 180 days.</p><p>The benefit of password expiration, however, is debatable. Systems that implement such policies sometimes prevent users from picking a password too close to a previous selection.</p><p>This policy can often backfire. Some users find it hard to devise \"good\" passwords that are also easy to remember, so if people are required to choose many passwords because they have to change them often, they end up using much weaker passwords; the policy also encourages users to write passwords down. Also, if the policy prevents a user from repeating a recent password, this requires that there is a database in existence of everyone's recent passwords (or their hashes) instead of having the old ones erased from memory. Finally, users may change their password repeatedly within a few minutes, and then change back to the one they really want to use, circumventing the password change policy altogether.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: As passwords age, the probability that they are compromised grows.</p></li></ul>",
                "remediation": "<p>Only when the application's enforced password strength is no longer strong enough to withstand brute force attacks due to an increase in computing power can users be made to update their passwords.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/620.html"
                ],
                "locale": "en",
                "title": "Permit password change",
                "vulnType": "OWASP WSTG",
                "description": "<p>Users ought to have the option of changing their password whenever necessary. Consider, for instance, the situation where they frequently use the same password across different applications. Users must immediately update their login information in each application they have registered for if their password is compromised. Therefore, there is a chance that a user's account could be compromised if the application does not give him access to a password update feature.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li><li><p>Access Control: Gain Privileges or Assume Identity: As passwords age, the probability that they are compromised grows.</p></li></ul>",
                "remediation": "<p>Applications should offer a feature that enables the user to modify their own password.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/521.html"
                ],
                "locale": "en",
                "title": "Verify breached passwords",
                "vulnType": "OWASP WSTG",
                "description": "<p>Over the years, breaches have resulted in the release of numerous databases containing stolen credentials. Users are subject to dictionary attacks if they select compromised passwords.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: An attacker could easily guess user passwords and gain access user accounts.</p></li></ul>",
                "remediation": "<p>Check that passwords entered during account creation, login, and password changes are compared to a list of passwords that have been compromised. The application must require the user to re-enter a password that hasn't already been compromised if the password they chose has already been compromised.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/330.html"
                ],
                "locale": "en",
                "title": "Secrets should be secure random generated",
                "vulnType": "OWASP WSTG",
                "description": "<p>Passwords, API tokens, and secret keys must be generated dynamically. These tokens can become predictable and be used by attackers to compromise user accounts whenever they are not generated dynamically.</p>",
                "observation": "<ul><li><p>Other: Other: When a protection mechanism relies on random values to restrict access to a sensitive resource, such as a session ID or a seed for generating a cryptographic key, then the resource being protected could be accessed by guessing the ID or key</p></li><li><p>Other: Other: If software relies on unique, unguessable IDs to identify a resource, an attacker might be able to guess an ID for a resource that is owned by another user. The attacker could then read the resource, or pre-create a resource with the same ID to prevent the legitimate program from properly sending the resource to the intended user. For example, a product might maintain session information in a file whose name is based on a username. An attacker could pre-create this file for a victim user, then set the permissions so that the application cannot generate the session for the victim, preventing the victim from using the application.</p></li><li><p>Access Control: Gain Privileges or Assume Identity: When an authorization or authentication mechanism relies on random values to restrict access to restricted functionality, such as a session ID or a seed for generating a cryptographic key, then an attacker may access the restricted functionality by guessing the ID or key.</p></li></ul>",
                "remediation": "<p>These values must be dynamically generated and only valid once when it comes to API tokens and secret keys.The secret token should be cryptographically \"random secure,\" have at least 120 bits of effective entropy, be salted with a special and randomly generated 32-bit value, and hashed using a recognized hashing (one-way) function.</p><p>Instead of giving a user a password that is dynamically generated, passwords should be created by the user themselves. In order to activate his account and create a password of his own, the user should be given a one-time link with a cryptographically random token via email or SMS.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism",
                    "https://cwe.mitre.org/data/definitions/804.html",
                    "https://cwe.mitre.org/data/definitions/645.html",
                    "https://cwe.mitre.org/data/definitions/1216.html",
                    "https://cwe.mitre.org/data/definitions/307.html"
                ],
                "locale": "en",
                "title": "Weaknesses in protection against brute force attacks",
                "vulnType": "OWASP WSTG",
                "description": "<p>A common threat web developers face is a password-guessing attack known as a brute force attack. A brute-force attack is an attempt to discover a password by systematically trying every possible combination of letters, numbers, and symbols until you discover the one correct combination that works. If your web site requires user authentication, you are a good target for a brute-force attack. </p><p>An attacker can always discover a password through a brute-force attack, but the downside is that it could take years to find it. Depending on the password's length and complexity, there could be trillions of possible combinations. To speed things up a bit, a brute-force attack could start with dictionary words or slightly modified dictionary words because most people will use those rather than a completely random password. These attacks are called dictionary attacks or hybrid brute-force attacks. Brute-force attacks put user accounts at risk and flood your site with unnecessary traffic.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: When authorization, authentication, or another protection mechanism relies on CAPTCHA entities to ensure that only human actors can access certain functionality, then an automated attacker such as a bot may access the restricted functionality by guessing the CAPTCHA.</p></li><li><p>Availability: DoS: Resource Consumption (Other): Users could be locked out of accounts.</p></li><li><p>Access Control: Bypass Protection Mechanism: An attacker could perform an arbitrary number of authentication attempts using different passwords, and eventually gain access to the targeted account.</p></li></ul>",
                "remediation": "<p>Create a sufficient defense system to stop attacks. Verify that the combination of numbers and letters in a captcha system is difficult to predict, and do not provide the answer in any of the responses that are sent to the user's browser.</p><p>Utilize account unlocking procedures in accordance with the level of risk. From the riskiest to the safest:</p><ul><li><p>Blocking and unblocking based on time.</p></li><li><p>Unblocking using self-service (sending unblocking email to registered email address).</p></li><li><p>Administrator unlocking by hand.</p></li><li><p>Positive user identification for manual administrator unlocking.</p></li><li><p>Making use of a self-service mechanism: As previously mentioned, this self-service mechanism needs to be sufficiently secure to prevent the attacker from being able to unlock the accounts on his own.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism",
                    "https://cwe.mitre.org/data/definitions/693.html"
                ],
                "locale": "en",
                "title": "Weakness in the second factor authentication mechanism (2FA).",
                "vulnType": "OWASP WSTG",
                "description": "<p>A zero trust security model's two-factor authentication mechanism (2FA) is a key component. You must confirm that users attempting to access sensitive data are who they claim to be in order to protect it. Security threats like phishing, brute force attacks, credential exploitation, etc. that target user passwords and accounts can be successfully defended against with 2FA.</p><p>Let's say you complete primary authentication in an application with a username and password. The Internet is used to transmit that information (primary network). It would be preferable to finish two-factor authentication using a different (out-of-band) channel. Out-of-band authentication includes things like approving a push notification sent over your mobile network.</p><p>Despite being highly recommended, this approach can be harmful if not used properly.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: The application does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.</p></li></ul>",
                "remediation": "<p>While it is best to omit SMS as 2FA only option, this does not address the reason for adding 2FA in the first place. To avoid brute force and other attacks targeting password authentication, some form of 2FA is needed. Some of the alternatives to 2FA SMS:</p><ul><li><p>Hardware authentication. Hardware authentication relies on a dedicated physical device to grant access. In addition to the password, users have to enter a random code generated by the device. Logins will fail without the code. Hardware authentication vendors include RSA SecurID and Thales SafeNet.</p></li><li><p>Software authentication. Software authentication essentially follows the same principle as hardware authentication. But instead of requiring a physical device, token codes are generated with a mobile application. The most popular authentication application is Google Authenticator, but there are many options. For example, RSA now offers its SecurID authenticator as an app.</p></li><li><p>IP-based authentication. This method checks the user's IP address when logging in. You can block access to specific IP addresses suspected of being malicious, or simply allow only logins from known IP addresses and ranges. IP-based authentication can be used in conjunction with other ways to add another layer of protection.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/01-Test_Network_Infrastructure_Configuration",
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials",
                    "https://cwe.mitre.org/data/definitions/521.html"
                ],
                "locale": "en",
                "title": "Default usernames and passwords",
                "vulnType": "OWASP WSTG",
                "description": "<p>The built-in administrative account has default passwords on a lot of hardware and web applications. Although they may occasionally be generated at random, they are frequently static, making it simple for an attacker to guess or obtain them.</p><p>Additionally, predefined passwords might be assigned to new users when they are created in applications. These may be generated automatically by the application or manually by staff. The passwords in both situations are susceptible to guessing attacks if they are not generated securely.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: An attacker could easily guess user passwords and gain access user accounts.</p></li></ul>",
                "remediation": "<p>The design of a product should require compliance with an appropriate password policy. The specific requirements for passwords highly depend on contextual factors, but it is recommended that they contain the following attributes:</p><ol><li><p>Enforcement of a minimum and maximum length</p></li><li><p>Restrictions against password reuse.</p></li><li><p>Restrictions against the use of common passwords.</p></li><li><p>Restrictions against the use of contextual strings in the password (e.g., user ID, application name).</p></li></ol><p>Depending on the threat model, the password policy may include several additional attributes.</p><p>Complex passwords requiring mixed character sets (alphabetic, numeric, special, upper and lower case):</p><ul><li><p>Increasing the range of characters makes the password more difficult to crack and may be appropriate for systems that rely on single-factor authentication.</p></li><li><p>Unfortunately, a complex password can be difficult to memorize, which encourages the user to select a short password or to mismanage the password (write it down).</p></li><li><p>Another disadvantage of this approach is that it often does not result in a significant increase in overall password complexity due to people's predictable use of various symbols.</p></li></ul><p>Extensive minimum length:</p><ol><li><p>Increasing the number of characters makes the password more difficult to crack and may be appropriate for systems that rely on single-factor authentication.</p></li><li><p>A disadvantage of this approach is that selecting a good passphrase is not easy and poor passwords can still be generated. Some prompting may be needed to encourage long and unpredictable passwords.</p></li></ol><p>Randomly generated passwords:</p><ol><li><p>Generating a password for the user can help ensure that length and complexity requirements are met, and may result in strong passwords being used.</p></li><li><p>A disadvantage of this approach is that the resulting password or key may be too difficult to memorize, which encourages writing them down.</p></li></ol><p>Password expiration:</p><ol><li><p>Requiring a periodic password change can reduce the window of time an attacker has to crack a password, while limiting the damage caused by exposing the password elsewhere.</p></li><li><p>Password expiration can be a good mitigation technique when long and complex passwords are not desired.</p></li></ol>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Bypassing_Authentication_Schema",
                    "https://cwe.mitre.org/data/definitions/288.html"
                ],
                "locale": "en",
                "title": "Login functionality bypass",
                "vulnType": "OWASP WSTG",
                "description": "<p>In computer security, authentication is the process of attempting to verify the digital identity of the sender of a communication. A common example of this is the login process. Testing the authentication scheme means understanding how the authentication process works and using that information to circumvent the authentication mechanism.</p><p>Although most applications require authentication to access private information or to execute tasks, not all authentication methods are capable of providing adequate security. Negligence, ignorance or simple underestimation of security threats often result in authentication schemes that can be circumvented by simply bypassing the login page and calling directly to an internal page that is supposed to be accessible only once authentication is performed.</p><p>In addition, it is often possible to bypass authentication measures by manipulating requests and tricking the application into thinking that the user is already authenticated. This can be achieved by modifying the given URL parameter, manipulating the form or spoofing sessions.</p><p>Problems related to the authentication scheme can be encountered at different stages of the software development life cycle (SDLC), such as the design, development and deployment phases:</p><ul><li><p>In the design phase errors can include a wrong definition of the sections of the application to be protected, choosing not to apply strong encryption protocols to secure the transmission of credentials, and many more.</p></li><li><p>In the development phase errors may include incorrect implementation of the input validation functionality or not following security best practices for the specific language.</p></li><li><p>In the application deployment phase, there may be problems during application configuration (installation and configuration activities) due to lack of required technical knowledge or lack of good documentation.</p></li></ul>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: The attacker may use an alternate path or channel that does not require authentication.</p></li></ul>",
                "remediation": "<p>Only authenticated users may view the application's private pages.</p><p>Explain in detail the modifications required to address the vulnerability in the case of bypassing the authentication functionality.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/04-Authentication_Testing/06-Testing_for_Browser_Cache_Weaknesses",
                    "https://cwe.mitre.org/data/definitions/525.html"
                ],
                "locale": "en",
                "title": "Sensitive information stored in browser",
                "vulnType": "OWASP WSTG",
                "description": "<p>The web application lacks a proper caching policy that establishes the level of caching that should be done for each web page and the associated form fields.</p><p>Information may be stored by browsers for history and caching purposes. To enhance performance, caching is used so that previously downloaded data doesn't have to be downloaded again. For the user's convenience, history mechanisms are used so that they can see exactly what was viewed when the resource was retrieved. When sensitive data (like your address, credit card number, Social Security number, or user name) is displayed to the user, this data may be cached or saved for history purposes and can thus be retrieved by looking through the browser cache or by simply pressing the browser's back button.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. Do not store unnecessary sensitive information in the cache. Consider using encryption in the cache. Depending on whether this information is stored in history or cached the following actions can be taken to mitigate the vulnerability:</p><p>The back button can be prevented from displaying sensitive data. This can be done by:</p><p>Sending the page over HTTPS.</p><p>Setting Cache-Control: must-revalidate</p><p>To prevent pages containing sensitive information from being cached it is necessary to do one of the following two things:</p><p>Set the directive \"Cache-Control: no-cache, no-store\" or \"Pragma: no-cache\" in the response headers for such pages. Ex:</p><p>HTTP/1.1:</p><p>Cache-Control: no-cache, no-store.</p><p>HTTP/1.0:</p><p>Pragma: no-cache (or Cache-Control: no-cache).</p><p>Expires: <past date or an illegal value (ex: 0)></p><p>Include in each HTML page that has sensitive information the following code:</p><p>HTTP/1.1:</p><p><META HTTP-EQUIV=\"Cache-Control\" CONTENT=\"no-cache, no-store\"></p><p>HTTP/1.0:</p><p><META HTTP-EQUIV=\"Pragma\" CONTENT=\"no-cache\"></p><p><META HTTP-EQUIV=\"Expires\" CONTENT=\"Sat, 01-Jan-2000 00:00:00GMT\"></p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities",
                    "https://cwe.mitre.org/data/definitions/640.html"
                ],
                "locale": "en",
                "title": "Weaknesses in password change/reset functionality",
                "vulnType": "OWASP WSTG",
                "description": "<p>A mechanism that enables a user to access their account in the event that they forget their password is typically present in applications. The password recovery mechanism is frequently unreliable, which increases the likelihood that someone besides the system's legitimate user will be able to access that user's account. A strong password authentication scheme is completely destroyed by weak password recovery procedures.</p><p>This weakness may exist due to the security question being too easy to guess (e.g., because the question is too common, or the answers can be found using social networks). There may also be an implementation weakness in the code of the password recovery mechanism that may, for instance, trick the system into emailing the new password to an email account other than the user's email account. The password reset rate may not be regulated, so a legitimate user may be denied of service if an attacker attempts to recover his or her password in quick succession. The system can send the original password to the user instead of generating a new temporary password. In summary, password recovery functionality, if not carefully designed and implemented, can often become the weakest link in the system that can be misused in a way that allows an attacker to gain unauthorized access to the system.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: An attacker could gain unauthorized access to the system by retrieving legitimate user's authentication credentials</p></li><li><p>Availability: DoS: Resource Consumption : An attacker could deny service to legitimate system users by launching a brute force attack on the password recovery mechanism using user ids of legitimate users.</p></li><li><p>Other: Other: The system's security functionality is turned against the system by the attacker.</p></li></ul>",
                "remediation": "<p>Make sure that the password recovery mechanism has thoroughly filtered and validated every piece of information the user provides.</p><ul><li><p>Use multiple security questions rather than the usual weak security questions.</p></li><li><p>Make sure there aren't too many incorrect responses to a security question. After a certain (small) number of wrong answers, turn off the password recovery feature.</p></li><li><p>Demand that users correctly respond to the security question before allowing them to reset their password and receive the new password at the email address they have on file.</p></li><li><p>In the password recovery mechanism, never let the user choose the email address to which the new password will be sent.</p></li><li><p>Give a new temporary password rather than sharing the old one.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities",
                    "https://cwe.mitre.org/data/definitions/319.html",
                    "https://cwe.mitre.org/data/definitions/311.html"
                ],
                "locale": "en",
                "title": "Credentials sent in clear text via email",
                "vulnType": "OWASP WSTG",
                "description": "<p>This flaw implies that after the user has verified their identity, the registration or password recovery functionality emails them the password. There are two main reasons why this is regarded as less secure:</p><p>The user receives the password in an unencrypted form.</p><p>The user is locked out of their account until they receive the email because the account password is changed at the time of the request. It is possible to prevent a user from accessing their account by sending numerous requests.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: An attacker may be able to decrypt the data using brute force attacks.</p></li></ul>",
                "remediation": "<p>When sending passwords via email, the following areas should be reviewed:</p><ul><li><p>Is the user forced to change the password upon first login? The new password is sent via unencrypted email, and may remain in the user's inbox indefinitely if the user does not delete the email. Therefore, the user should be required to change the password upon first login.</p></li><li><p>Is the password generated securely? The password should be generated using a cryptographically secure pseudorandom number generator (CSPRNG), and should be long enough to prevent password guessing or brute force attacks. For a secure user experience, it should be generated using a secure passphrase style approach (i.e., combining multiple words), rather than a random string of characters.</p></li><li><p>Is the user's current password sent? Instead of generating a new password for the user, some applications send the users their current password. This is a very insecure method, as it exposes your current password via unencrypted email. Furthermore, if the site is able to retrieve the existing password, this implies that passwords are stored using reversible encryption, or (more likely) in unencrypted plaintext, which represents a serious security weakness.</p></li><li><p>Are emails sent from a domain with anti-spoofing protection? The domain must implement SPF, DKIM and DMARC to prevent attackers from spoofing emails coming from it, which could be used as part of a social engineering attack.</p></li><li><p>Is email considered secure enough? Emails are often sent unencrypted and, in many cases, the user's email account will not be protected by MFA. In addition, it may be shared among multiple individuals, especially in a corporate environment.</p></li></ul><p>Consider whether email-based password reset functionality is appropriate based on the context of the application being tested.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/287.html"
                ],
                "locale": "en",
                "title": "Improper authentication",
                "vulnType": "OWASP WSTG",
                "description": "<p>The application does not prove or does not sufficiently prove that an actor's claim to possess a particular identity is true.</p>",
                "observation": "<ul><li><p>Access Control: Execute Unauthorized Code or Commands: This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.</p></li></ul>",
                "remediation": "<p>Utilize a framework or library for authentication, such as the OWASP ESAPI Authentication feature.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/285.html"
                ],
                "locale": "en",
                "title": "All authentication controls must fail securely",
                "vulnType": "OWASP WSTG",
                "description": "<p>Secure error handling is a crucial component of secure coding.Two errors in particular require special attention. The first category is exceptions that arise during a security control's processing. It's crucial that these exceptions do not permit actions that the countermeasure would typically forbid.You should keep in mind as a developer that a security mechanism typically has three possible outcomes:</p><ul><li><p>Permit the procedure.</p></li><li><p>Permit the operation not.</p></li><li><p>An exception In general, your security mechanism should be built so that a failure will have the same effect as turning off the operation.</p></li></ul>",
                "observation": "<ul><li><p>Confidentiality: Read Files or Directories: An attacker could read sensitive data, either by reading the data directly from a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.</p></li><li><p>Integrity: Modify Files or Directories: An attacker could modify sensitive data, either by writing the data directly to a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.</p></li><li><p>Access Control: Gain Privileges or Assume Identity: An attacker could gain privileges by modifying or reading critical data directly, or by accessing insufficiently-protected, privileged functionality.</p></li></ul>",
                "remediation": "<p>Before using any access control systems in your application, make sure they have all undergone extensive security testing. Complete unit tests are frequently made specifically for this purpose.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Authentication",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/310.html"
                ],
                "locale": "en",
                "title": "Cryptographic modules must fail securely - Padding Oracle Attack",
                "vulnType": "OWASP WSTG",
                "description": "<p>When a cryptographic module fails insecurely, the device must be put into error state so that it is no longer functional.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker may be able to read sensitive information</p></li></ul>",
                "remediation": "<p>We advise putting the cryptographic module through its own tests using the National Institute of Standards and Technology (NIST) standard to see if it fails securely.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/01-Testing_Directory_Traversal_File_Include",
                    "https://cwe.mitre.org/data/definitions/22.html"
                ],
                "locale": "en",
                "title": "Path Traversal",
                "vulnType": "OWASP WSTG",
                "description": "<p>The \"Path Traversal\" vulnerability enables users to access files or directories located elsewhere on the system by escaping the restricted area. It is possible to access any files and directories stored in the file system by adjusting variables that refer to files with \"dot-dot-slash (../)\" sequences and their variations.</p>",
                "observation": "<ul><li><p>Integrity: Execute Unauthorized Code or Commands: The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.</p></li><li><p>Confidentiality: Execute Unauthorized Code or Commands: The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.</p></li><li><p>Integrity: Modify Files or Directories: The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.</p></li><li><p>Confidentiality: Read Files or Directories: The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.</p></li><li><p>Availability: DoS: Crash, Exit, or Restart: The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the software from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the software.</p></li></ul>",
                "remediation": "<p>Use a data input validation strategy, or a list of inputs that are strictly compliant with the requirements, and reject any input that does not meet those requirements.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References",
                    "https://cwe.mitre.org/data/definitions/706.html",
                    "https://cwe.mitre.org/data/definitions/813.html"
                ],
                "locale": "en",
                "title": "IDOR (Insecure Direct Object References)",
                "vulnType": "OWASP WSTG",
                "description": "<p>When an application grants direct access to objects based on input from the user, this is known as a \"insecure direct object reference\" (IDOR). This vulnerability enables attackers to bypass authentication and gain direct access to system resources, such as files or database records. By changing the value of a parameter used to point directly to an object, an attacker can bypass authentication and gain unrestricted access to resources. These resources may include system files, other users' database entries, etc. This happens because the application uses user-provided input to retrieve an object without carrying out enough authorization checks.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: An attacker could perform an arbitrary number of authentication attempts using different passwords, and eventually gain access to the targeted account.</p></li><li><p>Access Control: Gain Privileges or Assume Identity: Horizontal escalation of privilege is possible (one user can view/modify information of another user).</p></li><li><p>Access Control: Gain Privileges or Assume Identity: Vertical escalation of privilege is possible if the user-controlled key is actually a flag that indicates administrator status, allowing the attacker to gain administrative access.</p></li></ul>",
                "remediation": "<p>Avert displaying references to secret items like file names or keys.</p><p>The server side must correctly implement parameter validation and object verification for all references.</p><p>Tokens must be created in a way that restricts their assignment to the user and prevents them from being shared with the public.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/306.html"
                ],
                "locale": "en",
                "title": "Principle of least privilege",
                "vulnType": "OWASP WSTG",
                "description": "<p>According to the principle of least privilege, accounts should have the fewest privileges necessary to carry out their business operations. This includes user rights as well as network, file system, and resource permissions like CPU and memory caps.</p>",
                "observation": "<ul><li><p>Other: Other: Exposing critical functionality essentially provides an attacker with the privilege level of that functionality. The consequences will depend on the associated functionality, but they can range from reading or modifying sensitive data, access to administrative or other privileged functionality, or possibly even execution of arbitrary code.</p></li></ul>",
                "remediation": "<ul><li><p>The principle means giving a user account only those privileges which are essential to that user’s work. For example, a backup user does not need to install software: hence, the backup user has rights only to run backup and backup related applications. Any other privileges, such as installing new software, are blocked.</p></li><li><p>The principle applies also to a personal computer user who usually does work in a normal user account, and opens a privileged, password protected account (that is, a superuser) only when the situation absolutely demands it.</p></li><li><p>This principle can also be applied to your web applications. Instead of solely depending on role based authentication methods using sessions, we rather want to assign privileges to users by means of a Database-Based Authentication system.</p></li></ul><p>We still use sessions in order to identify if the user was logged in correctly, only now instead of assigning that user with a specific role we assign him with privileges to verify which actions he is privileged to perform on the system.Also, a big pro of this method is, whenever a user has to be assigned fewer privileges your changes will be applied on the fly since the assigning does not depend on the session which otherwise had to expire first.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/285.html"
                ],
                "locale": "en",
                "title": "Improper Authorization",
                "vulnType": "OWASP WSTG",
                "description": "<p>When an actor tries to access a resource or carry out an action, the software either doesn't perform or incorrectly performs an authorization check.Based on the user's privileges and any permissions or other access-control requirements that apply to the resource, authorization is the process of determining whether a user with a given identity can access a specific resource.</p><p>Users are able to access data or carry out actions that they shouldn't be able to carry out when access control checks are not applied consistently, or at all. Numerous issues, such as information exposures, denial of service attacks, and arbitrary code execution, may result from this.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Files or Directories: An attacker could read sensitive data, either by reading the data directly from a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.</p></li><li><p>Integrity: Modify Files or Directories: An attacker could modify sensitive data, either by writing the data directly to a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.</p></li><li><p>Access Control: Gain Privileges or Assume Identity: An attacker could gain privileges by modifying or reading critical data directly, or by accessing insufficiently-protected, privileged functionality.</p></li></ul>",
                "remediation": "<p>Architecture and Design</p><ul><li><p>Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.</p></li></ul><p>Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.</p><ul><li><p>Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.</p></li><li><p>Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.</p></li><li><p>For example, consider using authorization frameworks such as the JAAS Authorization Framework REF-233 and the OWASP ESAPI Access Control feature REF-45.</p></li><li><p>For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.</p></li><li><p>One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.</p></li></ul><p>System Configuration: Installation</p><ul><li><p>Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a \"default deny\" policy when defining these ACLs.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/01-Testing_for_Session_Management_Schema",
                    "https://cwe.mitre.org/data/definitions/1018.html",
                    "https://owasp.org/www-community/attacks/Session_Prediction"
                ],
                "locale": "en",
                "title": "Predictable session ID",
                "vulnType": "OWASP WSTG",
                "description": "<p>The main objective of the session prediction attack is to foresee session ID values that enable an attacker to get around an application's authentication process. An attacker can predict a valid session ID value and gain access to the application by investigating and comprehending the session ID generation process.</p><p>First, the attacker needs to collect some valid session ID values that are used to identify authenticated users. Next, he or she needs to understand the structure of the session ID, the information used to create it, and the encryption or hashing algorithm used by the application to protect it. Some bad implementations use session IDs composed of the username or other predictable information, such as the client's timestamp or IP address. In the worst case, this information is used in clear text or is encoded using some weak algorithm such as base64 encoding.</p><p>Also, the attacker can implement a brute-force technique to generate and test different values of the session ID until he or she gains access to the application.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: An attacker could stay logged for long, which could reuse old or deleted IDs and direct references.</p></li></ul>",
                "remediation": "<p>By utilizing hashes and non-repeatable variables like timestamps, a non-predictable session should be generated.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/614.html https://cwe.mitre.org/data/definitions/1004.html",
                    "https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies",
                    "https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html"
                ],
                "locale": "en",
                "title": "Secure attribute missing in cookies",
                "vulnType": "OWASP WSTG",
                "description": "<p>The Secure attribute and the HttpOnly attribute are used to make sure that cookies are sent securely and cannot be accessed by scripts or unintended parties. A cookie with the Secure attribute is only ever sent to the server in conjunction with an encrypted HTTPS request. The JavaScript API cannot access a cookie with the HttpOnly attribute; instead, the server receives it instead.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: An attacker that performs a successful cross-site scripting or man-in-the-middle attack will be able to read the contents of the cookie and exfiltrate information obtained.</p></li></ul>",
                "remediation": "<p>Both HttpOnly and Secure attributes should be used by the server when setting cookies in order to mitigate this vulnerability. An illustration is provided below:</p><p>Set-Cookie: cookie1=info1; Secure; HttpOnly</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/614.html https://cwe.mitre.org/data/definitions/1004.html",
                    "https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies",
                    "https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html"
                ],
                "locale": "en",
                "title": "HTTP Only attribute missing in cookies",
                "vulnType": "OWASP WSTG",
                "description": "<p>The Secure attribute and the HttpOnly attribute are employed to guarantee that cookies are sent securely and cannot be accessed by unauthorized individuals or scripts. Only encrypted requests made using the HTTPS protocol and never unsecured HTTP are allowed to send cookies with the Secure attribute to the server. The JavaScript API cannot access a cookie with the HttpOnly attribute because it is only sent to the server.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: If the HttpOnly flag is not set, then sensitive information stored in the cookie may be exposed to unintended parties.</p></li><li><p>Integrity: Gain Privileges or Assume Identity: If the cookie in question is an authentication cookie, then not setting the HttpOnly flag may allow an adversary to steal authentication data (e.g., a session ID) and assume the identity of the user.</p></li></ul>",
                "remediation": "<p>Both HttpOnly and Secure attributes should be used by the server when setting cookies in order to mitigate this vulnerability. An illustration is provided below:</p><p>Set-Cookie: cookie1=info1; Secure; HttpOnly</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/02-Testing_for_Cookies_Attributes",
                    "https://cwe.mitre.org/data/definitions/1275.html",
                    "https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html",
                    "https://cwe.mitre.org/data/definitions/1275.html"
                ],
                "locale": "en",
                "title": "SameSite attribute missing in cookies",
                "vulnType": "OWASP WSTG",
                "description": "<p>It has been discovered that the cookies created by the application do not make use of the SameSite protection mechanism at the time of website access. This safeguard prevents potential Cross-Site Request Forgery (CSRF) attacks by regulating how cookies are sent in requests to other domains.</p>",
                "observation": "<ul><li><p>Confidentiality: Modify Application Data: If the website does not impose additional defense against CSRF attacks, failing to use the 'Lax' or 'Strict' values could increase the risk of exposure to CSRF attacks. The likelihood of the integrity breach is Low because a successful attack does not only depend on an insecure SameSite attribute. In order to perform a CSRF attack there are many conditions that must be met, such as the lack of CSRF tokens, no confirmations for sensitive actions on the website, a \"simple\" \"Content-Type\" header in the HTTP request and many more.</p></li></ul>",
                "remediation": "<p>When possible, it is advised to create cookies with the 'SameSite' attribute set to the 'Strict' value.</p><p>Set-Cookie: <Cookie>=<Value>; Path=/; Expires=<Date>; Domain=<Domain>; Secure; HttpOnly; SameSite=Strict</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/02-Testing_for_Cookies_Attributes",
                    "https://cwe.mitre.org/data/definitions/613.html"
                ],
                "locale": "en",
                "title": "Application cookies have an excessive or indefinite expiration time.",
                "vulnType": "OWASP WSTG",
                "description": "<p>The Expires attribute is used to:</p><ul><li><p>Set persistent cookies.</p></li><li><p>Limit the lifetime if a session lives too long.</p></li><li><p>Forcibly delete a cookie by setting it to a date in the past.</p></li></ul><p>Unlike session cookies, persistent cookies will be used by the browser until the cookie expires. Once the expiration date has passed the set time, the browser will delete the cookie.</p><p>Lack of proper session expiration can enhance the success likelihood of certain attacks. For example, an attacker can intercept a session ID, possibly through a network sniffer or Cross-site Scripting attack. While short session expiration times do not help if a stolen token is used immediately, they will protect against continuous replay of the session ID. In another scenario, a user might access a website from a shared computer (such as in a library, Internet cafe, or open work environment). Insufficient session expiration could allow an attacker to use the browser's back button to access web pages that the victim has previously accessed.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: An attacker could stay logged for long, which could reuse old or deleted IDs and direct references.</p></li></ul>",
                "remediation": "<p>Only persistent cookies are set using the attribute itself. However, it's crucial to check that no sensitive data is present in the persistent cookie. For instance, if a persistent cookie is used to store information necessary for user authentication, an attacker with access to the cookie could use it to prove their identity to the application.</p><p>Therefore, we must make sure that a cookie containing sensitive information does not have the 'Expires' attribute set.</p><p>On the other hand, it is advisable to set brief expiration times to lower the likelihood that a potential attacker will repurpose them.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-community/Session_Timeout"
                ],
                "locale": "en",
                "title": "Insufficient Session Expiration",
                "vulnType": "OWASP WSTG",
                "description": "<p>Authenticated users' unique session cookies, which are typically used by web applications, must be configured with a lifetime so that they expire after a maximum set amount of time. Because of this, if a user logs in on another computer without manually ending their session, any other user who logs in on that computer and accesses the application will continue to be in the previous authenticated user's session.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: An attacker could stay logged for long, which could reuse old or deleted IDs and direct references.</p></li></ul>",
                "remediation": "<p>Reduce the session expiration times.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/03-Testing_for_Session_Fixation",
                    "https://cwe.mitre.org/data/definitions/384.html"
                ],
                "locale": "en",
                "title": "Session Fixation",
                "vulnType": "OWASP WSTG",
                "description": "<p>Authenticating a user, or establishing a new user session, without invalidating any existing session identifiers, gives an attacker the opportunity to steal authenticated sessions.</p><p>This scenario is commonly observed when:</p><ol><li><p>A web application authenticates a user without first invalidating the existing session, thus continuing the session already associated with the user.</p></li><li><p>An attacker is able to force a known session identifier on a user so that, once the user authenticates, the attacker has access to the authenticated session.</p></li><li><p>The application or container uses predictable session identifiers. In the generic exploit of session fixation vulnerabilities, an attacker creates a new session in a web application and registers the associated session identifier. The attacker then has the victim associate, and possibly authenticate, against the server using that session identifier, giving the attacker access to the user's account through the active session.</p></li></ol>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: An attacker could stay logged for long, which could reuse old or deleted IDs and direct references.</p></li></ul>",
                "remediation": "<p>The countermeasure for a session fixation vulnerability is to hard-code the application in such a way that prevents the application from accepting a token that has been forced into the victim's session.</p><p>The following steps provide a robust way to secure a web application against these attacks:</p><ul><li><p>Do not accept session identifiers in GET or POST parameters. This makes it much more difficult for an attacker to exploit, as it is easier to trick a victim into making the request without browser vulnerabilities. In addition, all session IDs must be generated by the server; there should be no need for the client to propose a new session ID for the application.</p></li><li><p>Change the session ID after login. The server should generate a new session ID and set it as a cookie after the user has logged in. Any existing session for the user should be destroyed on the server.</p></li><li><p>Provide a logout function and expire old sessions. The user should be able to choose when to end their session with the application, which should immediately terminate any current session on the server and not simply delete the cookie from the browser. Session data should also expire automatically after a certain period, to reduce the time an attacker can make use of a compromised session.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery",
                    "https://cwe.mitre.org/data/definitions/352.html"
                ],
                "locale": "en",
                "title": "Cross-site Request Forgery (CSRF)",
                "vulnType": "OWASP WSTG",
                "description": "<p>A CSRF attack aims to trick a user into unwittingly executing functionality in a vulnerable web application that will be of benefit to the attacker and to the detriment of the affected user.</p><p>Specifically, the attack is carried out by forcing the browser of an unsuspecting user to make a request to the vulnerable website, a request that the user will carry out without realizing it, and succeeding as long as the user is logged into the website since the already established credentials (session ID, cookies,...) will be automatically used.</p><p>Unlike XSS attacks, which exploit the trust that a user has in a particular site, Cross Site Request Forgery exploits the trust that a site has in a particular user. This is an insufficient authentication vulnerability in which the application does not properly validate the origin of the request.</p>",
                "observation": "<ul><li><p>Access Control: DoS: Crash, Exit, or Restart: The consequences will vary depending on the nature of the functionality that is vulnerable to CSRF. An attacker could effectively perform any operations as the victim. If the victim is an administrator or privileged user, the consequences may include obtaining complete control over the web application - deleting or stealing data, uninstalling the product, or using it to launch other attacks against all of the product's users. Because the attacker has the identity of the victim, the scope of CSRF is limited only by the victim's privileges.</p></li></ul>",
                "remediation": "<p>To avoid Cross-Site Request Forgery attacks, it is necessary that each request made to the website contains a unique identifier (a synchronizer token), which must be a parameter that the attacker cannot find out.</p><p>For example, it is suggested to send in a parameter the session identifier of the legitimate user. The server must check this parameter as a way of validating that it is indeed the current user who is requesting the current operation.</p><p>Additionally, user interaction can be requested for sensitive transactions as a form of double authentication or by responding to a CAPTCHA.</p><p>Also, the REFERER header in the client request should be checked to ensure that each request is coming from the original site and not from an external source. This mitigation, although necessary, can be bypassed by an attacker using other types of vulnerabilities such as XSS.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery",
                    "https://cwe.mitre.org/data/definitions/352.html"
                ],
                "locale": "en",
                "title": "Absence of token anti-CSRF",
                "vulnType": "OWASP WSTG",
                "description": "<p>A CSRF attack aims to trick a user into unwittingly executing functionality in a vulnerable web application that will be of benefit to the attacker and to the detriment of the affected user.</p><p>Specifically, the attack is carried out by forcing the browser of an unsuspecting user to make a request to the vulnerable website, a request that the user will carry out without realizing it, and succeeding as long as the user is logged into the website since the already established credentials (session ID, cookies,...) will be automatically used.</p><p>Unlike XSS attacks, which exploit the trust that a user has in a particular site, Cross Site Request Forgery exploits the trust that a site has in a particular user. This is an insufficient authentication vulnerability in which the application does not properly validate the origin of the request.</p>",
                "observation": "<ul><li><p>Access Control: DoS: Crash, Exit, or Restart: The consequences will vary depending on the nature of the functionality that is vulnerable to CSRF. An attacker could effectively perform any operations as the victim. If the victim is an administrator or privileged user, the consequences may include obtaining complete control over the web application - deleting or stealing data, uninstalling the product, or using it to launch other attacks against all of the product's users. Because the attacker has the identity of the victim, the scope of CSRF is limited only by the victim's privileges.</p></li></ul>",
                "remediation": "<p>The application should be updated to include anti-CSRF token support for any sensitive forms that are accessible during an authenticated session.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/06-Testing_for_Logout_Functionality",
                    "https://cwe.mitre.org/data/definitions/287.html"
                ],
                "locale": "en",
                "title": "Weaknesses in the logout process.",
                "vulnType": "OWASP WSTG",
                "description": "<p>The applications' user logout mechanism is improperly implemented.</p><p>A user can interact with the application again without having to enter their login information again because the session is not properly invalidated.</p>",
                "observation": "<ul><li><p>Access Control: Execute Unauthorized Code or Commands: This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.</p></li></ul>",
                "remediation": "<p>It is advised that the logout button be present on all application pages, that it invalidate the session on both the client and the server, and that the server reject any further connections made with the same token.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/07-Testing_Session_Timeout",
                    "https://cwe.mitre.org/data/definitions/1018.html"
                ],
                "locale": "en",
                "title": "Weaknesses in the logout process due to inactivity.",
                "vulnType": "OWASP WSTG",
                "description": "<p>All applications should implement an inactivity timeout for sessions. This timeout defines the amount of time a session will remain active in case of no user activity, closing and invalidating the session after the defined period of inactivity since the last HTTP request received by the web application for a given session ID. The most appropiate timeout should be a balance between security (shorter timeout) and usability (longer timeout) and depends largely on the level of sensitivity of the data handled by the application. For example, a 60-minute logout time for a public forum may be acceptable, but such a long time would be too long in a home banking application (where a maximum timeout of 15 minutes is recommended). In any case, any application that does not enforce a timeout-based logout should be considered insecure, unless such behavior is required by a specific functional requirement.</p><p>Timeout limits the possibilities for an attacker to guess and use a valid session ID of another user, and in certain circumstances could protect public computers from session reuse. However, if the attacker is able to hijack a given session, the inactivity timeout does not limit the attacker's actions, as he or she can generate activity in the session periodically to keep the session active for a longer period of time.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: An attacker could stay logged for long, which could reuse old or deleted IDs and direct references.</p></li></ul>",
                "remediation": "<p>The server side must implement session timeout management and expiration. An attacker could manipulate client-controlled data that is used to enforce session timeout, such as cookie values or other client parameters that track time references (such as the number of minutes since the login time), in order to lengthen the session. As a result, the application must monitor server-side idle time and, once the timeout period has passed, automatically invalidate the current user's session and delete all client-side data.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/09-Testing_for_Session_Hijacking",
                    "https://capec.mitre.org/data/definitions/593.html"
                ],
                "locale": "en",
                "title": "Session Hijacking",
                "vulnType": "OWASP WSTG",
                "description": "<p>The session hijacking attack consists of exploiting the web session control mechanism, which is normally managed for a session token.</p><p>Since http communication uses many different TCP connections, the web server needs a method to recognize each user's connections. The most useful method relies on a token that the web server sends to the client browser after successful client authentication. A session token is typically composed of a variable width string and can be used in a variety of ways, such as in the URL, in the HTTP request header as a cookie, in other parts of the HTTP request header, or even in the body of the HTTP request.</p><p>The Session Hijacking attack compromises the session token by stealing or predicting a valid session token to gain unauthorized access to the web server.</p><p>The session token can be compromised in different ways; the most common ones are:- Session token prediction.- Session scanning.- Client-side attacks (XSS, malicious JavaScript code, Trojans, etc).- Man-in-the-middle attack.- Man-in-the-browser attack.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: An attacker could stay logged for long, which could reuse old or deleted IDs and direct references.</p></li></ul>",
                "remediation": "<p>Use industry-standard session key generation processes that generate session keys using a lot of entropy, and properly encrypt and sign identity tokens in transit. You can rely on a lot of common web and application servers to handle this task. For each session, use a session timeout. After this timeout period, end the user's session if they didn't explicitly log out. A new session key must be generated if the user logs in again.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Session Management",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-community/attacks/Session_hijacking_attack"
                ],
                "locale": "en",
                "title": "Concurrent logins not properly controlled.",
                "vulnType": "OWASP WSTG",
                "description": "<p>Applications requiring authentication must only permit one active session per user and must not permit multiple authenticated user sessions across various browsers or computers.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: An attacker could stay logged for long, which could reuse old or deleted IDs and direct references.</p></li></ul>",
                "remediation": "<p>It is advised that the same user's sessions not run concurrently and that they always receive notification when an old session is still active.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/159.html"
                ],
                "locale": "en",
                "title": "(generic) Failure to Sanitize input",
                "vulnType": "OWASP WSTG",
                "description": "<p>The incorrect use of special elements in user-controlled input is not properly filtered, removed, quoted, or otherwise managed by the product, which could have a negative impact on its behavior and integrity.</p>",
                "observation": "<ul><li><p>Availability: DoS: Crash, Exit, or Restart: Client-side validation checks can be easily bypassed, allowing malformed or unexpected input to pass into the application, potentially as trusted data. This may lead to unexpected states, behaviours and possibly a resulting crash.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.</p></li></ul>",
                "remediation": "<p>Developers should anticipate that special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and whitelists to ensure only valid, expected and appropriate input is processed by the system.Implementation</p><ul><li><p>Assume all input is malicious. Use an \"\"accept known good\"\" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"\"boat\"\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colours such as \"red\" or \"blue.\" Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.</p></li><li><p>While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict whitelist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (88).</p></li><li><p>Inputs should be decoded and canonicalized to the application's current internal representation before being validated (180). Make sure that the application does not decode the same input twice (174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting",
                    "https://owasp.org/www-community/attacks/xss/",
                    "https://cwe.mitre.org/data/definitions/79.html"
                ],
                "locale": "en",
                "title": "(generic) Cross-Site Scripting (XSS)",
                "vulnType": "OWASP WSTG",
                "description": "<p>The \"Cross-Site Scripting (XSS)\" vulnerability enables outside parties to inject Java Script or HTML code into specific application web pages. By doing this, it is possible to steal user sessions, compromise the security of the system, and obtain sensitive or proprietary information from the application.</p><p>This vulnerability is typically brought on by an application's failure to validate input and output parameters, which frequently happens with forms.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser -- performs some activity (such as sending all site cookies to a given E-mail address). This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is combined with other flaws.</p></li><li><p>Access Control: Read Application Data: The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running \"Active X\" controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.</p></li></ul>",
                "remediation": "<p>Every parameter that the application manages needs to be validated, especially when it comes to input data provided by the user. This validation is always carried out on the server side and NEVER relies on validations carried out on the client side.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting",
                    "https://owasp.org/www-community/attacks/xss/",
                    "https://cwe.mitre.org/data/definitions/79.html"
                ],
                "locale": "en",
                "title": "Reflected Cross-Site Scripting (Reflected XSS)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Through a Cross-Site Scripting (XSS) attack, an attacker can insert malicious code that runs in the victim's browser, take control of the browser, and use it to access credentials, sensitive data, or session data from the affected application.</p><p>For Reflected Cross-Site Scripting to work, the attacker must be in direct contact with the victim in order to send the malicious code that will be run in the victim's browser as part of the application.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser -- performs some activity (such as sending all site cookies to a given E-mail address). This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is combined with other flaws.</p></li><li><p>Access Control: Read Application Data: The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running \"Active X\" controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.</p></li></ul>",
                "remediation": "<p>Preventing Cross-site Scripting (XSS) attacks is not trivial depending on the complexity of the application and how it handles user-controllable data and the type of Cross-site Scripting (XSS) vulnerability.</p><p>However, there are certain general principles that the following measures should implement:</p><ul><li><p>Filter data input: Treat all user input as untrusted, filter as strictly as possible based on what is expected or is valid input.</p></li><li><p>Use encryption: With the use of an appropriate encryption technique prevent it from being interpreted as legitimate content.</p></li><li><p>Use secure response headers: Browsers accept different types of headers to prevent Cross-site Scripting (XSS) attacks, such as a Content Security Policy (CSP) and 'X-XSS-Protection'.</p></li><li><p>Protect cookies: It is necessary to mitigate possible access to session cookies with the 'HttpOnly' flag. This flag disables access to cookies through client-side JavaScript.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-community/attacks/Server_Side_Request_Forgery https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_SS heet.html"
                ],
                "locale": "en",
                "title": "Stored Cross-Site Scripting (Stored XSS)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser -- performs some activity (such as sending all site cookies to a given E-mail address). This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is combined with other flaws.</p></li><li><p>Access Control: Read Application Data: The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running \"Active X\" controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.</p></li></ul>",
                "remediation": "<p>Sanitizing all server-side input is necessary to reduce the risk of stored XSS. To serve all the data to the client side, create a White box filter with the permitted characters and use html encoding.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution",
                    "https://cwe.mitre.org/data/definitions/235.html",
                    "https://capec.mitre.org/data/definitions/460.html"
                ],
                "locale": "en",
                "title": "HTTP Parameter Pollution (HPP)",
                "vulnType": "OWASP WSTG",
                "description": "<p>HTTP Parameter Pollution takes advantage of the application's incorrect behavior when responding to HTTP requests that have the same parameter defined on the server but were sent with different values. HTTP Parameter Pollution takes advantage of the application's incorrect behavior when responding to HTTP requests that have the same parameter defined on the server but were sent with different values.</p>",
                "observation": "<ul><li><p>Integrity: Unexpected State: An attacker could manipulate parameters in the application</p></li></ul>",
                "remediation": "<p>This kind of attack would be avoided by properly sanitizing input data, verifying the number of individual parameter instances in a request, and looking for requests with duplicate assignments.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://www.owasp.org/index.php/SQL_Injection"
                ],
                "locale": "en",
                "title": "(generic) SQL Injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>Through the use of SQL code injection (SQLi), it is possible to change the logic of SQL statements and enable the execution of different kinds of database queries. In addition to adding new records or deleting/modifying existing ones, it is possible to obtain data from the database that should, in theory, not be accessible, such as users, passwords, details about the application itself, etc. If the database user has more rights than necessary, it might be possible for them to access other databases or even run system commands. The primary root cause of SQL code injection (SQLi) is improper application input parameter validation.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.</p></li><li><p>Access Control: Bypass Protection Mechanism: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.</p></li><li><p>Access Control: Bypass Protection Mechanism: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.</p></li><li><p>Integrity: Modify Application Data: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL injection attack.</p></li></ul>",
                "remediation": "<p>Validate the parameters that the application manages, especially when the user submits them as input data. This validation is always carried out on the server side and never depends on client-side validations.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection",
                    "https://owasp.org/www-community/attacks/Blind_SQL_Injection",
                    "https://cwe.mitre.org/data/definitions/89.html"
                ],
                "locale": "en",
                "title": "In band Union-based SQL Injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>The SQL Injection (SQLi) attack attempts to obtain information or even execute commands through this vulnerability by interacting unexpectedly with the database. Since it is a blind sql injection in this instance, the response does not directly provide information about it; instead, an attacker must decipher the server's response messages in order to obtain the information.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.</p></li><li><p>Access Control: Bypass Protection Mechanism: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.</p></li><li><p>Access Control: Bypass Protection Mechanism: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.</p></li><li><p>Integrity: Modify Application Data: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL injection attack.</p></li></ul>",
                "remediation": "<p>Sanitizing the application's input parameters is advised to address this issue because doing so prevents attackers from introducing characters that could change the SQL query and enable information retrieval.</p><p>The main suggestion is to put in place a \"White List\" system where only the words and characters defined in the list are accepted and any other value is ignored before being used in the database. If this option is not feasible, a \"\"Black List\"\" that avoids the defined characters can be made using characters that are vulnerable to this kind of attack, such as % #'\"\"\"\"'\"\"\"\" () +, ;, and SQL query keywords such as \"select,\" \"where,\" \"union,\" \"join,\" and \"update.\" Additionally, you must look for any encoding variations for these characters, such as URL encoding, unicode/UTF-8, and hex.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection",
                    "https://cwe.mitre.org/data/definitions/89.html"
                ],
                "locale": "en",
                "title": "In band Error-Based SQL Injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>An unexpected database interaction known as a SQL injection (SQLi) attack tries to obtain information or even execute commands using this flaw. Since it is an error-based sql injection in this instance, the response does not directly provide information about it; instead, an attacker must interpret the error messages the server provides in order to obtain the information.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.</p></li><li><p>Access Control: Bypass Protection Mechanism: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.</p></li><li><p>Access Control: Bypass Protection Mechanism: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.</p></li><li><p>Integrity: Modify Application Data: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL injection attack.</p></li></ul>",
                "remediation": "<p>Sanitizing the application's input parameters is advised to address this issue because doing so prevents attackers from introducing characters that could change the SQL query and enable information retrieval.</p><p>The main suggestion is to put in place a \"White List\" system where only the words and characters defined in the list are accepted and any other value is ignored before being used in the database. If this option is not feasible, a \"\"Black List\"\" that avoids the defined characters can be made using characters that are vulnerable to this kind of attack, such as % #'\"\"\"\"'\"\"\"\" () +, ;, and SQL query keywords such as \"select,\" \"where,\" \"union,\" \"join,\" and \"update.\" Additionally, you must look for any encoding variations for these characters, such as URL encoding, unicode/UTF-8, and hex.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection",
                    "https://cwe.mitre.org/data/definitions/89.html"
                ],
                "locale": "en",
                "title": "Blind Time-Based SQL Injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>The SQL Injection (SQLi) attack attempts to obtain information or even execute commands through this vulnerability by interacting unexpectedly with the database. Since it is a time-based sql injection in this instance, the response does not directly provide information about it; rather, an attacker must interpret the server's response times to obtain the necessary information.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.</p></li><li><p>Access Control: Bypass Protection Mechanism: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.</p></li><li><p>Access Control: Bypass Protection Mechanism: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.</p></li><li><p>Integrity: Modify Application Data: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL injection attack.</p></li></ul>",
                "remediation": "<p>Sanitizing the application's input parameters is advised to address this issue because doing so prevents attackers from introducing characters that could change the SQL query and enable information retrieval.</p><p>The main suggestion is to put in place a \"White List\" system where only the words and characters defined in the list are accepted and any other value is ignored before being used in the database. If this option is not feasible, a \"\"Black List\"\" that avoids the defined characters can be made using characters that are vulnerable to this kind of attack, such as % #'\"\"\"\"'\"\"\"\" () +, ;, and SQL query keywords such as \"select,\" \"where,\" \"union,\" \"join,\" and \"update.\" Additionally, you must look for any encoding variations for these characters, such as URL encoding, unicode/UTF-8, and hex.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection",
                    "https://cwe.mitre.org/data/definitions/89.html"
                ],
                "locale": "en",
                "title": "Blind Boolean-Based SQL Injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>The attacker uses boolean-based SQL injection to send SQL queries to the database, forcing the application to return a different result depending on whether the query returns true or false. The HTTP response's content may change or stay the same depending on the outcome. Even if no data is returned from the database, this enables an attacker to determine whether the result is true or false.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.</p></li><li><p>Access Control: Bypass Protection Mechanism: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.</p></li><li><p>Access Control: Bypass Protection Mechanism: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.</p></li><li><p>Integrity: Modify Application Data: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL injection attack.</p></li></ul>",
                "remediation": "<p>Sanitizing the application's input parameters is advised to address this issue because doing so prevents attackers from introducing characters that could change the SQL query and enable information retrieval.</p><p>The main suggestion is to put in place a \"White List\" system where only the words and characters defined in the list are accepted and any other value is ignored before being used in the database. If this option is not feasible, a \"\"Black List\"\" that avoids the defined characters can be made using characters that are vulnerable to this kind of attack, such as % #'\"\"\"\"'\"\"\"\" () +, ;, and SQL query keywords such as \"select,\" \"where,\" \"union,\" \"join,\" and \"update.\" Additionally, you must look for any encoding variations for these characters, such as URL encoding, unicode/UTF-8, and hex.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection",
                    "https://cwe.mitre.org/data/definitions/89.html"
                ],
                "locale": "en",
                "title": "Out of Band SQL Injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>Out-of-Band SQL injection exfiltrates data through the output channel, which can be the DNS or HTTP protocol, as opposed to in-band and blind SQL injection. Depending on the available function, a database system may or may not be able to start an outgoing HTTP or DNS request. The function may set a connection (for instance, DBMS LDAP.INIT, UTL HTTP.request) or operate on files (for instance, load file(), master..xp dirtree). The targeted web and database servers must comply with the following requirements in order to exploit OOB SQL injection:</p><ul><li><p>The web application's lack of input validation</p></li><li><p>A network environment that dispenses with security perimeters and permits the target database server to initiate outgoing requests (via DNS or HTTP) to the general public</p></li><li><p>Enough rights to run the function required to send the exit request</p></li></ul>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.</p></li><li><p>Access Control: Bypass Protection Mechanism: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.</p></li><li><p>Access Control: Bypass Protection Mechanism: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.</p></li><li><p>Integrity: Modify Application Data: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL injection attack.</p></li></ul>",
                "remediation": "<ul><li><p>On both the client and server sides, input validation.</p></li><li><p>Correct handling of errors to prevent detailed information about them from being displayed.</p></li><li><p>Examine the architectures for the network and security.</p></li><li><p>Use the least privilege possible when allocating the database account to the application.</p></li><li><p>The use of additional security measures like intrusion prevention systems (IPS) and web application firewalls (WAF).</p></li><li><p>Constantly keeping an eye out for anomalies and having effective incident response procedures in place as a network of security controls.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/06-Testing_for_LDAP_Injection",
                    "https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html",
                    "https://cwe.mitre.org/data/definitions/90.html"
                ],
                "locale": "en",
                "title": "LDAP Injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>Information about users, hosts, and numerous other objects is stored using the Lightweight Directory Access Protocol (LDAP). An LDAP injection is a server-side attack that can reveal, modify, or insert sensitive data about users and hosts represented in an LDAP structure. Input parameters that are later passed to the internal find, add, and modify functions are changed to accomplish this.</p><p>To allow users to authenticate or look up other users' information within a corporate structure, a web application might use LDAP. LDAP injection attacks aim to insert LDAP search filter metacharacters into an application query that will be executed.</p>",
                "observation": "<ul><li><p>Integrity: Modify Application Data: An attacker could include input that changes the LDAP query which allows unintended commands or code to be executed, allows sensitive data to be read or modified or causes other unintended behavior.</p></li></ul>",
                "remediation": "<p>Assume that all inputs are malicious. Use an \"accept the good-known\" input validation strategy, that is, use a list of acceptable inputs that strictly conform to specifications. Reject any input that doesn't strictly conform to specs, or transform it into something that does.</p><p>When performing input validation, consider all potentially relevant properties, such as length, input type, full range of acceptable values, missing or extra inputs, syntax, consistency between related fields and compliance with business rules. As an example of business rule logic, \"ship\" may be syntactically valid because it contains only alphanumeric characters, but it is not valid if the input is expected to contain only colors such as \"red\" or \"blue\".</p><p>Do not rely only on searching for malicious or malformed entries. At least one unwanted input is likely to be missed, especially if the environment of the code changes. This can give attackers enough room to bypass the intended validation. However, deny lists can be useful for detecting potential attacks or determining which entries are so malformed that they should be rejected outright.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/611.html",
                    "https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing https://capec.mitre.org/data/definitions/201.html"
                ],
                "locale": "en",
                "title": "XML External Entity Processing (XXE)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Some applications transmit data between the browser and the server using the XML format. Applications that perform this almost always process the XML data on the server using a standard library or platform API. An example of a special XML entity is one whose defined values are loaded from sources other than the DTD in which they are declared. From a security standpoint, external entities are particularly intriguing because they enable the definition of an entity based on the contents of a file path or URL.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Files or Directories: If the attacker is able to include a crafted DTD and a default entity resolver is enabled, the attacker may be able to access arbitrary files on the system.</p></li><li><p>Integrity: Bypass Protection Mechanism: The DTD may include arbitrary HTTP requests that the server may execute. This could lead to other attacks leveraging the server's trust relationship with other entities.</p></li><li><p>Availability: DoS: Resource Consumption (Memory): The software could consume excessive CPU cycles or memory using a URI that points to a large file, or a device that always returns data such as /dev/random. Alternately, the URI could reference a file that contains many nested or recursive entity references to further slow down parsing.</p></li></ul>",
                "remediation": "<p>According to the OWASP Cheat Sheet \"XXE Prevention,\" turn off processing of XML external entities and DTDs in all XML parsers in the application.Additionally, use server-side input validation, filtering, or sanitization that is positive (\"whitelisting\") to ward off hostile data in XML documents, headers, or nodes.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/08-Testing_for_SSI_Injection",
                    "https://owasp.org/www-community/attacks/Server-Side_Includes_(SSI)_Injection#:~:text=The%20Server%2DSide%20Includes%20attack,use%20through%20user%20input%20fields.",
                    "- http://httpd.apache.org/docs/current/howto/ssi.html",
                    "https://cwe.mitre.org/data/definitions/96.html",
                    "https://cwe.mitre.org/data/definitions/116.html",
                    "https://cwe.mitre.org/data/definitions/159.html"
                ],
                "locale": "en",
                "title": "Server Side Injection (SSI)",
                "vulnType": "OWASP WSTG",
                "description": "<p>SSI (Server-Side Includes) are directives present in web applications that are used to feed an HTML page with dynamic content. They are similar to CGIs, except that SSIs are used to execute some actions before the current page is loaded or while it is being displayed. To do this, the web server parses the SSIs before serving the page to the user.</p><p>The SSI injection attack allows you to attack a web application by injecting scripts into HTML pages or by executing arbitrary code remotely. It can be exploited through manipulation of SSI directives in use in the application or force their use by injecting new directives through user input fields.</p><p>It is possible to check if the application is correctly validating the data in the input fields by inserting characters that are used in SSI directives, such as:</p><p>&lt; ! # = / . \" - &gt; and [a-zA-Z0-9]</p><p>Another way to find out if the application is potentially vulnerable is to check for the presence of pages with .stm, .shtm and .shtml extensions. However, the absence of such pages does not mean that the application is protected against SSI attacks.</p><p>In either case, the attack will only be successful if the web server allows SSI to run without performing proper validation first. If this occurs, it may be possible to access and manipulate system files and processes under the permission of the web server process owner.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The injected code could access restricted data / files.</p></li><li><p>Access Control: Bypass Protection Mechanism: In some cases, injectable code controls authentication; this may lead to a remote vulnerability.</p></li><li><p>Access Control: Gain Privileges or Assume Identity: Injected code can access resources that the attacker is directly prevented from accessing.</p></li><li><p>Other: Execute Unauthorized Code or Commands: Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.</p></li><li><p>Non-Repudiation: Hide Activities: Often the actions performed by injected control code are unlogged.</p></li><li><p>Integrity: Modify Application Data: The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.</p></li></ul>",
                "remediation": "<p>User-controllable data should not, whenever possible, be embedded by applications in pages that are rendered for SSI directives. There are generally safer alternate ways to implement the necessary functionality. If this is deemed impractical, the data must be rigorously validated. Ideally, you ought to employ a white list of particular acceptable values. Only brief alphanumeric strings will be accepted in the absence of this. Any additional data, including any potential SSI metacharacter, should be excluded from input.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/09-Testing_for_XPath_Injection",
                    "https://owasp.org/www-community/attacks/XPATH_Injection",
                    "https://cwe.mitre.org/data/definitions/94.html"
                ],
                "locale": "en",
                "title": "XPATH injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>Similar to SQL injection, XPath injection attacks take place when a website builds an XPath query for XML data using data supplied by the user.XPath is a kind of straightforward descriptive statement that enables searching the XML for a specific piece of information. You can specify specific attributes to look for and patterns to match, just like in SQL. It is common practice to accept some kind of input in the query string when using XML for a website in order to identify the content to find and display on the page. Such queries can be changed to return more data than they should or even run server-side code if the attacker sends a malicious XPath string.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: In some cases, injectable code controls authentication; this may lead to a remote vulnerability.</p></li><li><p>Access Control: Gain Privileges or Assume Identity: Injected code can access resources that the attacker is directly prevented from accessing.</p></li><li><p>Other: Execute Unauthorized Code or Commands: Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.</p></li><li><p>Non-Repudiation: Hide Activities: Often the actions performed by injected control code are unlogged.</p></li></ul>",
                "remediation": "<p>Before being included in XPATH (XML) queries, user input must be strictly validated. It is advised to employ a whitelist that restricts the characters or values that the application will accept as user input.</p><p>If whitelisting is not an option, a less preferred alternative is to employ a blacklist that at the very least eliminates the characters \"\"'/ @ = * [] (y)</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/35.html",
                    "https://capec.mitre.org/data/definitions/126.html"
                ],
                "locale": "en",
                "title": "File Path Manipulation",
                "vulnType": "OWASP WSTG",
                "description": "<p>When user-controllable data is inserted into a file or URL path that is used on the server to access local resources, which may be located inside or outside the web root, file path manipulation vulnerabilities are created. If a file path is vulnerable, an attacker can change it to access different resources.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Files or Directories: An attacker could read confidential data if they are able to control resource references.</p></li><li><p>Integrity: Modify Files or Directories: An attacker could modify sensitive data, either by writing the data directly to a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.</p></li></ul>",
                "remediation": "<p>Believing that all input is malicious Use a list of inputs that are strictly compliant with specifications as part of a \"accept known good\" input validation strategy. Any input that does not strictly adhere to the specifications should be rejected or changed. Use strict whitelists that restrict the character set that can be used when validating filenames. To prevent vulnerabilities like CWE-23, only allow a single \".\" character in the filename, and keep directory separators like \"/\" out.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/73.html"
                ],
                "locale": "en",
                "title": "External Control of Filename",
                "vulnType": "OWASP WSTG",
                "description": "<p>Due to a vulnerability, file names used by the filesystem can be changed or controlled by user input. An attacker can create a package that changes the ZIP file's downloadable extension.</p>",
                "observation": "<ul><li><p>Confidentiality: Modify Files or Directories: The application can operate on unexpected files. Confidentiality is violated when the targeted filename is not directly readable by the attacker.</p></li><li><p>Integrity: Modify Files or Directories: The application can operate on unexpected files. This may violate integrity if the filename is written to, or if the filename is for a program or other form of executable code.</p></li><li><p>Availability: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (Other): The application can operate on unexpected files. Availability can be violated if the attacker specifies an unexpected file that the application modifies. Availability can also be affected if the attacker specifies a filename for a large file, or points to a special device or a file that does not have the format that the application expects.</p></li></ul>",
                "remediation": "<p>Believing that all input is malicious Use a list of inputs that are strictly compliant with specifications as part of a \"accept known good\" input validation strategy. Any input that does not strictly adhere to the specifications should be rejected or changed. Use strict whitelists that restrict the character set that can be used when validating filenames. To prevent vulnerabilities like CWE-23, only allow a single \".\" character in the filename, and keep directory separators like \"/\" out.Believing that all input is malicious Use a list of inputs that are strictly compliant with specifications as part of a \"accept known good\" input validation strategy. Any input that does not strictly adhere to the specifications should be rejected or changed. Use strict whitelists that restrict the character set that can be used when validating filenames.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion",
                    "https://cwe.mitre.org/data/definitions/20.html",
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11-Testing_for_Code_Injection"
                ],
                "locale": "en",
                "title": "Remote code execution (RCE) by injection of local files",
                "vulnType": "OWASP WSTG",
                "description": "<p>Utilizing the application's vulnerable file call procedures, local file inclusion (LFI) is the process of including files that are already on the server. For instance, when a page receives input that is the path to a local file, this vulnerability manifests. Characters traversing the directory may be injected to access other files on the server if this entry is not properly sanitized.</p>",
                "observation": "<ul><li><p>Access Control: Execute Unauthorized Code or Commands: This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.</p></li></ul>",
                "remediation": "<p>The best way to get rid of file inclusion vulnerabilities is to never give any file system/framework APIs any user input. If this is not possible, the application can keep a list of permitted files that the page may include, and then use an index number or other identifier to access the desired file. So that malicious users cannot manipulate the route, any request that contains an invalid identifier should be rejected. It is advised to adhere to the recommendations of the OWASP guide (https://cheatsheetseries.owasp.org/cheatsheets/File Upload Cheat Sheet.html) for good remediation practices against File inclusion vulnerabilities.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion",
                    "https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html",
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "en",
                "title": "Remote code execution (RCE)",
                "vulnType": "OWASP WSTG",
                "description": "<p>Attacks known as remote code execution (RCE) give an attacker the ability to remotely run malicious code on a computer. An RCE vulnerability may result in the execution of malware or the complete takeover of a compromised machine by an attacker.</p>",
                "observation": "<ul><li><p>Access Control: Execute Unauthorized Code or Commands: This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.</p></li></ul>",
                "remediation": "<p>Restrict the source, whether it is an input or an open path leading to an application, from which the RCE is being accessed.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion",
                    "https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html",
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "en",
                "title": "Remote code execution (RCE) by remote file injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>The process of including references to remote files from another server through the use of weak file call procedures that were implemented in the application is known as remote file inclusion (RFI). This flaw, for instance, appears when a page downloads files from outside sources and then includes them in the application. It is possible to alter the resource to make the request against one that is controlled by an attacker if that input is not properly sanitized.</p>",
                "observation": "<ul><li><p>Access Control: Execute Unauthorized Code or Commands: This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.</p></li></ul>",
                "remediation": "<p>The best way to get rid of file inclusion vulnerabilities is to never give any file system/framework APIs any user input. If this is not possible, the application can keep a list of permitted files that the page may include, and then use an index number or other identifier to access the desired file. So that malicious users cannot manipulate the route, any request that contains an invalid identifier should be rejected. It is advised to adhere to the recommendations of the OWASP guide (https://cheatsheetseries.owasp.org/cheatsheets/File Upload Cheat Sheet.html) for good remediation practices against File inclusion vulnerabilities.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/284.html"
                ],
                "locale": "en",
                "title": "Improper access control",
                "vulnType": "OWASP WSTG",
                "description": "<p>The software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.Access control involves the use of several protection mechanisms such as:</p><ul><li><p>Authentication (proving the identity of an actor)</p></li><li><p>Authorization (ensuring that a given actor can access a resource)</p></li><li><p>Accountability (tracking of activities that were performed)</p></li></ul><p>When any mechanism is not applied or otherwise fails, attackers can compromise the security of the software by gaining privileges, reading sensitive information, executing commands, evading detection, etc.</p><p>There are two distinct behaviors that can introduce access control weaknesses:</p><ul><li><p>Specification: incorrect privileges, permissions, ownership, etc. are explicitly specified for either the user or the resource (for example, setting a password file to be world-writable, or giving administrator capabilities to a guest user). This action could be performed by the program or the administrator.</p></li><li><p>Enforcement: the mechanism contains errors that prevent it from properly enforcing the specified access control requirements (e.g., allowing the user to specify their own privileges, or allowing a syntactically-incorrect ACL to produce insecure settings). This problem occurs within the program itself, in that it does not actually enforce the intended security policy that the administrator specifies.</p></li></ul>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: Access control checks for specific user data or functionality can be bypassed.</p></li></ul>",
                "remediation": "<p>Architecture and Design</p><ul><li><p>Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.</p></li><li><p>Compartmentalize the system to have \"safe\" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.</p></li><li><p>Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Authorization",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/284.html"
                ],
                "locale": "en",
                "title": "Remote Code Execution (RCE) by Improper Access Control",
                "vulnType": "OWASP WSTG",
                "description": "<p>The software's failure to impose access controls on a website object is referred to as an improper access control vulnerability. When accessing the web service, a malicious user may compromise the software's security and take certain unapproved actions.</p>",
                "observation": "<ul><li><p>Other: Varies by Context: An attacker can access any functionality that is inadvertently accessible to the source.</p></li></ul>",
                "remediation": "<p>Do not allow anonymous users to access this website.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection",
                    "https://portswigger.net/web-security/os-command-injection",
                    "https://cwe.mitre.org/data/definitions/77.html",
                    "https://cwe.mitre.org/data/definitions/78.html"
                ],
                "locale": "en",
                "title": "Command Injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>Command injection vulnerabilities typically occur when:</p><ol><li><p>Data enters the app from an untrusted source.</p></li><li><p>The data is part of a string that is executed as a command by the application.</p></li><li><p>By executing the command, the application gives an attacker a privilege or capability that they would not have otherwise.</p></li></ol><p>Many protocols and products have their own custom command language. While shell or operating system command strings are frequently discovered and targeted, developers may not realize that these other command languages ​​can also be vulnerable to attack.</p>",
                "observation": "<ul><li><p>Integrity: Execute Unauthorized Code or Commands: If a malicious user injects a character (such as a semi-colon) that delimits the end of one command and the beginning of another, it may be possible to then insert an entirely new and unrelated command that was not intended to be executed.</p></li><li><p>Confidentiality: Read Application Data: The injected code could access restricted data / files.</p></li><li><p>Access Control: Bypass Protection Mechanism: In some cases, injectable code controls authentication; this may lead to a remote vulnerability.</p></li><li><p>Access Control: Gain Privileges or Assume Identity: Injected code can access resources that the attacker is directly prevented from accessing.</p></li><li><p>Other: Execute Unauthorized Code or Commands: Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.</p></li><li><p>Non-Repudiation: Hide Activities: Often the actions performed by injected control code are unlogged.</p></li></ul>",
                "remediation": "<p>It is recommended to limit the user's capabilities as much as possible when allowing him or her to execute specific commands on the server and assess and evaluate, in the first instance, whether it is absolutely necessary for the user to be able to carry out this type of action, as they involve a potential danger inherently.</p><p>It would be appropriate to restrict these capabilities given that many languages have built-in functions for executing commands on the computer, such as the system() function in PHP, and that it is possible to restrict the capabilities of the interpreter that runs the application (as in the case of PHP).</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection",
                    "https://cwe.mitre.org/data/definitions/644.html"
                ],
                "locale": "en",
                "title": "Injection of commands into HTTP Host headers.",
                "vulnType": "OWASP WSTG",
                "description": "<p>A web server typically hosts multiple web applications on the same IP address, referencing each application through the virtual host. On an incoming HTTP request, web servers typically send the request to the destination virtual host based on the value supplied in the Host header. Without proper validation of the header value, the attacker can supply invalid data to cause the web server to:</p><ul><li><p>Send the requests to the first virtual host in the list.</p></li><li><p>Cause a redirection to a domain controlled by the attacker.</p></li><li><p>Perform a poisoning of the web cache.</p></li><li><p>Manipulate the password reset functionality.</p></li></ul>",
                "observation": "<ul><li><p>Access Control: Execute Unauthorized Code or Commands: This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.</p></li></ul>",
                "remediation": "<p>To filter, escape, or encode unsecure data sent from the server in an HTTP response header, perform output validation.</p><p>Disable the ability for the client's browser to run scripts.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-side_Template_Injection",
                    "https://cwe.mitre.org/data/definitions/94.html",
                    "https://portswigger.net/research/server-side-template-injection"
                ],
                "locale": "en",
                "title": "Server-Side Template Injection (SSTI)",
                "vulnType": "OWASP WSTG",
                "description": "<p>When a user requests an HTML view, modern applications generate it using a template engine (also known as \"templates\"). The programming language's built-in functions in these template engines allow for the execution of risky functions and even code on the server hosting the application. It is possible to use those functions to run code on the server if a malicious user can inject template directives, and these are then rendered by the template engine.</p>",
                "observation": "<ul><li><p>Access Control: Bypass Protection Mechanism: In some cases, injectable code controls authentication; this may lead to a remote vulnerability.</p></li><li><p>Access Control: Gain Privileges or Assume Identity: Injected code can access resources that the attacker is directly prevented from accessing.</p></li><li><p>Other: Execute Unauthorized Code or Commands: Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.</p></li><li><p>Non-Repudiation: Hide Activities: Often the actions performed by injected control code are without been logged.</p></li></ul>",
                "remediation": "<p>Make sure you are not passing user-controllable variables to the functions that render templates. Sanitizing the input is crucial in the event that it is required to prevent characters from being interpreted.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/19-Testing_for_Server-Side_Request_Forgery",
                    "https://cwe.mitre.org/data/definitions/918.html"
                ],
                "locale": "en",
                "title": "Server-Side Request Forgery (SSRF)",
                "vulnType": "OWASP WSTG",
                "description": "<p>The SSRF (Server-Side Request Forgery) vulnerability arises when it is possible to direct the server to send a request to any domain using the user's input data. When the user making the request does not receive the server's response, this vulnerability may become \"blind.\" No such response is provided in this instance. However, based on the server response time, an enumeration of nearby machines on the network can be carried out.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The injected code could access restricted data / files.</p></li><li><p>Integrity: Execute Unauthorized Code or Commands: The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.</p></li></ul>",
                "remediation": "<p>Whitelisting the inputs that are permitted by that parameter is the appropriate mitigation for this vulnerability. In other words, only accept the paths to the resources that you actually need to access because, as of right now, doing otherwise gives www-data user access to any area of the permissions system where they can read.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "en",
                "title": "JSON validation schema",
                "vulnType": "OWASP WSTG",
                "description": "<p>A vocabulary called JSON Schema enables you to annotate and validate JSON documents.</p><p>You have better control over the kinds of user input that can be supplied in your application when adding schemas to your JSON files.When done properly, this drastically reduces an attacker's vector.</p><p>However, as an additional line of defense, you should always apply your own input validation and rejection. This strategy is also preferred because you also want to counteract and record user requests and input.</p>",
                "observation": "<ul><li><p>Availability: DoS: Resource Consumption (Memory): An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.</p></li><li><p>Confidentiality: Read Files or Directories: An attacker could read confidential data if they are able to control resource references.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.</p></li></ul>",
                "remediation": "<p>To ensure a properly formatted JSON request, confirm that JSON schema validation occurs. Next, validate each input field before any data processing is done.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "en",
                "title": "XML schema (XSD)",
                "vulnType": "OWASP WSTG",
                "description": "<p>You have better control over the kind of user input that can be provided in your application when adding schemas to your XML files. When done properly, this drastically reduces an attacker's vector. However, as an additional line of defense, you should always apply your own input validation and rejection. This strategy is also preferred because you also want to counteract and record user requests and input.</p>",
                "observation": "<ul><li><p>Availability: DoS: Resource Consumption (Memory): An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.</p></li><li><p>Confidentiality: Read Files or Directories: An attacker could read confidential data if they are able to control resource references.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.</p></li></ul>",
                "remediation": "<p>Check that the XSD schema is validated to ensure that the XML document is correctly formatted, and then validate each input field before the data is processed.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
        "category": "Input Validation",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "en",
                "title": "Verify that structured data is strongly typed and validated",
                "vulnType": "OWASP WSTG",
                "description": "<p>When structured data is tightly typed and checked against a specified schema, a defendable proactive application can be created. By using the defined schemas, the application can now measure everything that is outside of its intended operation and should be used to reject input if the schema checks return false.</p>",
                "observation": "<ul><li><p>Availability: DoS: Resource Consumption (Memory): An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.</p></li><li><p>Confidentiality: Read Files or Directories: An attacker could read confidential data if they are able to control resource references.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.</p></li></ul>",
                "remediation": "<p>Check that structured data is strongly typed and validated against a defined schema, including the permitted characters, length, and pattern (for example, credit card numbers or phone numbers, or validating that two related fields are logical, such as validating suburbs and zip or post codes match).</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "category": "Error handling",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling"
                ],
                "locale": "en",
                "title": "Disclosure of sensitive information due to improper handling of application errors.",
                "vulnType": "OWASP WSTG",
                "description": "<p>Verbose errors that are not properly controlled frequently result in responses that inform the user of the application's internal architecture. Versions of installed software or database information are some examples of the data that can be retrieved in this way.</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The attacker gets information from an error message response</p></li></ul>",
                "remediation": "<p>To stop the application from displaying sensitive information from your infrastructure or database, implement a proper system of redirections to secure pages or generic texts in the response.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
        "category": "Functionality/Business Logic",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/06-Testing_for_the_Circumvention_of_Work_Flows"
                ],
                "locale": "en",
                "title": "Abuse of application logic workflow.",
                "vulnType": "OWASP WSTG",
                "description": "<p>Workflow vulnerabilities involve any type of vulnerability that allows an attacker to misuse an application/system in a way that allows them to bypass (not follow) the designed/intended workflow.</p><p>Definition of a workflow on Wikipedia:</p><p>A workflow consists of a sequence of connected steps in which each step follows without delay or gap, ending just before the next step can begin. It is a representation of a sequence of operations, stated as the work of a person or group, an organization of personnel, or one or more simple or complex mechanisms. Workflow can be thought of as an abstraction of actual work.</p><p>The application's business logic should require the user to complete specific steps in the correct/specific order and if the workflow is terminated without completing it successfully, all actions and generated actions are \"\"rolled back\"\" or aborted. Vulnerabilities related to workflow circumvention of correct business logic are unique in that they are very application/system specific and careful manual abuse cases must be developed using the requirements. and use cases.</p><p>The applications business process must have checks to ensure that user transactions/actions proceed in the correct/acceptable order and if a transaction triggers some type of action, that action will be \"\"rolled back\"\" and killed if the transaction does not complete successfully.</p>",
                "observation": "<ul><li><p>Other: Alter Execution Logic: An attacker could cause the software to skip critical steps or perform them in the wrong order, bypassing its intended business logic. This can sometimes have security implications.</p></li></ul>",
                "remediation": "<p>The application needs controls that ensure users complete each workflow step in the proper order and stop attackers from bypassing, skipping, or replaying any steps or processes in the workflow. It also needs to be self-aware. Creating business logic abuse or misuse cases with the objective of successfully completing the business process while not completing the correct steps in the correct order is how testing for workflow vulnerabilities is done.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Functionality/Business Logic",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/09-Test_Upload_of_Malicious_Files.html",
                    "https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html"
                ],
                "locale": "en",
                "title": "Insecure validation in file upload functionality",
                "vulnType": "OWASP WSTG",
                "description": "<p>Many applications allow users to upload data to their business processes. Although input validation for text-based input fields is widely understood, accepting files makes it more challenging to implement. Despite the fact that many websites use straightforward restrictions based on a list of permitted (or blocked) extensions, this is insufficient to stop attackers from loading safe file types with malicious content.</p>",
                "observation": "<ul><li><p>Availability: Execute Unauthorized Code or Commands: Arbitrary code execution is possible if an uploaded file is interpreted and executed as code by the recipient. This is especially true for .asp and .php extensions uploaded to web servers because these file types are often treated as automatically executable, even when file system permissions do not specify execution. For example, in Unix environments, programs typically cannot run unless the execute bit is set, but PHP programs may be executed by the web server without directly invoking them on the operating system.</p></li></ul>",
                "remediation": "<p>Control the types of files that are sent to the application properly. Examine the file type, paying attention to both the extension and the content.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
        "category": "Functionality/Business Logic",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/01-Test_Business_Logic_Data_Validation",
                    "https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html",
                    "https://cwe.mitre.org/data/definitions/502.html"
                ],
                "locale": "en",
                "title": "Insecure deserialization",
                "vulnType": "OWASP WSTG",
                "description": "<p>It is often convenient to serialize objects for communication or to save them for later use. However, deserialized code or data can often be modified without using the provided access functions if they do not use cryptography to protect themselves. Also, any crypto would still be client-side security, which is a dangerous security assumption.</p><p>Untrusted data cannot be trusted to be well-formed. When developers don't put restrictions on \"\"gadget chains\"\", or series of instances and method invocations that can auto-execute during the deserialization process (i.e. before the object is returned to the caller), They can sometimes be exploited by attackers to perform unauthorized actions, such as generating a shell.</p><p>Serialization and deserialization refer to the process of taking the data related to the program's internal object, packaging it in a way that allows the data to be stored or transferred externally (\"\"serialization\"\"), and then extracting the serialized data to reconstruct the object. original (\"\"deserialization\"\").</p>",
                "observation": "<ul><li><p>Integrity: Unexpected State: Attackers can modify unexpected objects or data that was assumed to be safe from modification.</p></li><li><p>Availability: DoS: Resource Consumption (CPU): If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.</p></li><li><p>Other: Varies by Context: The consequences can vary widely, because it depends on which objects or methods are being de-serialized, and how they are used. Making an assumption that the code in the de-serialized object is valid is dangerous and can enable exploitation.</p></li></ul>",
                "remediation": "<p>Possible mitigations for different phases of the application creation process are described below:</p><ul><li><p>Phases: Architecture and design; implementation. If available, use the programming language's signing/sealing features to ensure that the deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.</p></li><li><p>Phase: Implementation. When deserializing data, it is recommended to populate a new object rather than just deserialize. The result is that the data goes through secure input validation and the functions are secure.</p></li><li><p>Phase: Implementation. Explicitly define a final() object to avoid deserialization.</p></li><li><p>Phases: Architecture and Design; Implementation. Make fields transient to protect them from deserialization. An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is a great way to prevent temporary, environment, or sensitive variables from being transferred and misused.</p></li><li><p>Phase: Implementation. Avoid having unnecessary types or gadgets available that can be exploited for malicious purposes. This limits the possibility of unwanted or unauthorized types and gadgets being exploited by the attacker. Add only acceptable classes to an allow list. Note: New gadgets are constantly being discovered, so this alone is not a sufficient mitigation.</p></li></ul>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Web client side",
        "details": [
            {
                "references": [
                    "https://cwe.mitre.org/data/definitions/601.html",
                    "https://portswigger.net/kb/issues/00500100_open-redirection-reflected"
                ],
                "locale": "en",
                "title": "Client-Side URL Redirect (Open Redirection)",
                "vulnType": "OWASP WSTG",
                "description": "<p>A vulnerability known as Open Redirect occurs when a program inadvertently incorporates user-controllable data into the destination of a redirection. Within the application, an attacker can create a URL that directs traffic to any external domain.</p>",
                "observation": "<ul><li><p>Access Control: Gain Privileges or Assume Identity: The user may be redirected to an untrusted page that contains malware which may then compromise the user's machine. This will expose the user to extensive risk and the user's interaction with the web server may also be compromised if the malware conducts keylogging or other attacks that steal credentials, personally identifiable information (PII), or other important data.</p></li><li><p>Other: Other: The user may be subjected to phishing attacks by being redirected to an untrusted page. The phishing attack may point to an attacker controlled web page that appears to be a trusted web site. The phishers may then steal the user's credentials and then use these credentials to access the legitimate web site.</p></li></ul>",
                "remediation": "<p>By disabling the redirection function or keeping a server-side list of all URLs that are allowed for redirection, applications should, whenever possible, avoid incorporating user-controllable data into redirection targets.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Web client side",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/03-Testing_for_HTML_Injection",
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "en",
                "title": "HTML Content Injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>HTML injections allow for the client-side injection of HTML code that the victim's browser will interpret when visiting a URL. It is possible to alter the DOM and, in some circumstances, to inject JavaScript code to assist in stealing data from the victim's browser.</p>",
                "observation": "<ul><li><p>Availability: DoS: Resource Consumption (Memory): An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.</p></li><li><p>Confidentiality: Read Files or Directories: An attacker could read confidential data if they are able to control resource references.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.</p></li></ul>",
                "remediation": "<p>This kind of attack can be stopped by properly sanitizing user input or correctly validating the contents that the server receives and sends.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
        "category": "Web client side",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/05-Testing_for_CSS_Injection",
                    "https://research.securitum.com/css-data-exfiltration-in-firefox-via-single-injection-point/",
                    "https://cwe.mitre.org/data/definitions/20.html"
                ],
                "locale": "en",
                "title": "CSS Content Injection",
                "vulnType": "OWASP WSTG",
                "description": "<p>Similar to how HTML or XSS injections work, CSS injections give hackers the ability to insert CSS code on the client side, which the victim's browser will then interpret when they visit a URL. It has been demonstrated that it is possible to exfiltrate data from the DOM using only CSS, despite the fact that CSS does not have the same potential as HTML or JavaScript and is only capable of exporting styles.</p>",
                "observation": "<ul><li><p>Availability: DoS: Resource Consumption (Memory): An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.</p></li><li><p>Confidentiality: Read Files or Directories: An attacker could read confidential data if they are able to control resource references.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.</p></li></ul>",
                "remediation": "<p>This kind of attack can be stopped by properly validating the contents that the server receives and sends, or correctly sanitizing the user input.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Web client side",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/01-Testing_for_DOM-based_Cross_Site_Scripting",
                    "https://cwe.mitre.org/data/definitions/79.html"
                ],
                "locale": "en",
                "title": "DOM based Cross-Site Scripting (XSS)",
                "vulnType": "OWASP WSTG",
                "description": "<p>An XSS attack known as DOM-based XSS causes client-side code to run in a \"unexpected\" manner by altering the DOM \"environment\" that the victim's browser was designed to use by the original client-side script. As a result of malicious changes made to the DOM environment, the client-side code contained in the page executes differently even though the page itself (i.e., the HTTP response) remains the same.</p><p>Other XSS attacks (stored or reflected), in contrast, place the attack payload on the response page (due to a server-side failure).</p>",
                "observation": "<ul><li><p>Confidentiality: Read Application Data: The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser -- performs some activity (such as sending all site cookies to a given E-mail address). This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.</p></li><li><p>Availability: Execute Unauthorized Code or Commands: In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is combined with other flaws.</p></li><li><p>Access Control: Read Application Data: The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running \"Active X\" controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.</p></li></ul>",
                "remediation": "<p>There is no single action that can completely eliminate the threat of DOM-based attacks. Generally speaking, however, the most effective way to prevent DOM-based vulnerabilities is to prevent data from any untrusted source from dynamically altering the value that is passed to any receiver.</p><p>If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within client-side code. In many cases, relevant data can be validated against a whitelist, allowing only content that is known to be safe. In other cases, it will be necessary to sanitize or encrypt the data. This can be a complex task and, depending on the context in which the data is to be inserted, may involve a combination of JavaScript escaping, HTML encoding, and URL encoding, in the appropriate sequence.</p>"
            }
        ]
    },
    {
        "cvssv3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
        "category": "Web client side",
        "details": [
            {
                "references": [
                    "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/07-Testing_Cross_Origin_Resource_Sharing",
                    "https://cwe.mitre.org/data/definitions/942.html",
                    "https://developer.mozilla.org/es/docs/Web/HTTP/CORS",
                    "https://stackoverflow.com/questions/1653308/access-control-allow-origin-multiple-origin-domains"
                ],
                "locale": "en",
                "title": "Cross-Origin Resource Sharing (CORS) missconfiguration",
                "vulnType": "OWASP WSTG",
                "description": "<p>CORS stands for Cross-Origin Resource Sharing. It is a feature offering the possibility for:- A web application to expose resources to all or restricted domain.- A web client to make AJAX request for resource on another domain than its source domain.An unrestrictive CORS policy can be abused in several ways that can risk the user’s confidentiality, availability and integrity information.</p>",
                "observation": "<ul><li><p>Other: Varies by Context: An attacker can access any functionality that is inadvertently accessible to the source.</p></li></ul>",
                "remediation": "<p>Only allow the trusted domains or subdomains that the application should trust in the Access-Control-Allow-Origin header.</p>"
            }
        ]
    }
]