Web Pentest.yml

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N'
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-INPV-05: SQL Injection'
      vulnType: Pentest
      description: >-
        <p>SQL injection (SQLi) is a type of attack where an attacker exploits a
        vulnerability in a web application that allows them to execute malicious
        SQL statements. This is typically accomplished by inserting SQL commands
        or fragments of SQL code into input fields or parameters that are sent
        to a web application's database, which can result in unauthorized access
        to data, modification or deletion of data, or even complete takeover of
        the web application.</p><p>For example, an attacker might use SQL
        injection to bypass authentication mechanisms by entering a specially
        crafted input that causes the database to return all user records or
        grant administrative access. They could also modify or delete data by
        injecting SQL code that modifies or deletes database entries, or even
        drop or corrupt the entire database.</p>
      remediation: >-
        <p>The affected parameters should be checked for validity on the server
        side and special characters should be filtered out.</p><p>Ideally,
        prepared statements should be used for the database queries to avoid SQL
        injection vulnerabilities.</p><p></p>
      references:
        - 'https://owasp.org/www-community/attacks/SQL_Injection'
      customFields: []
  priority: 4
  remediationComplexity: 2

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L'
  priority: 3
  remediationComplexity: 2
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-INPV-01: Cross-Site-Scripting in GET-Request'
      vulnType: Pentest
      description: >-
        <p>Cross-Site Scripting (XSS) is a type of web security vulnerability
        where attackers inject malicious scripts into a website or web
        application. These scripts are then executed in the context of other
        users' browsers, allowing the attacker to carry out malicious actions.
        XSS attacks exploit the trust between a user and a website, often
        targeting areas where user-generated content is displayed without proper
        validation or escaping.</p><p>By exploiting this vulnerability,
        cross-site scripting attacks on website visitors are possible. Possible
        effects of successful cross-site scripting attacks
        include:</p><ul><li><p>Stealing credentials, session information,
        cookies,</p></li><li><p>Complete takeover of the client browser,
        including remote control of the client, if exploits exist for the
        browser used,</p></li><li><p>compromising the functionality of the web
        application,</p></li><li><p>alteration of the content and design of the
        pages.</p></li></ul><p>For example, if a user opens a crafted link, the
        attacker is able to manipulate the web page content and include a link
        to third-party malware to infect attacked clients.</p>
      observation: <p>THIS IS MY POC</p>
      remediation: >-
        <p>Countermeasures against XSS include input validation, output
        encoding, and implementing content security policies. This includes
        verifying that input is of the correct type and length, and that it does
        not contain any potentially malicious characters or code. Input
        validation ensures only legitimate data is accepted, output encoding
        prevents script execution, and content security policies restrict the
        sources of allowed scripts, reducing the attack surface. Regular updates
        and secure coding practices enhance protection.</p><p>More info can be
        found in the OWASP cheat sheet from the reference section.</p><p>A check
        via JavaScript on the client side is not sufficient, since this can also
        be manipulated by the client.</p>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting
        - >-
          https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N'
  priority: 2
  remediationComplexity: 1
  category: Web Pentest
  details:
    - references:
        - >-
          https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html
      locale: EN
      title: 'WSTG-CONF-07: HSTS-Header not set'
      vulnType: Pentest
      description: >-
        <p>HSTS stands for HTTP Strict Transport Security. It is a security
        feature that is implemented using an HTTP response header that instructs
        web browsers to only connect to a website using HTTPS (HTTP over
        SSL/TLS) protocol, even if the user types "http" in the URL
        bar.</p><p>The HSTS header helps prevent "Man-in-the-Middle" (MITM)
        attacks where an attacker could intercept the user's connection to the
        website and redirect them to a fake website where they could steal
        sensitive information like login credentials, credit card details,
        etc.</p><p>When a website sends the HSTS header to the browser, it
        instructs the browser to remember that the website should always be
        accessed via HTTPS for a specified period of time (usually for several
        months). Once the browser has received this instruction, it will
        automatically upgrade any HTTP requests to HTTPS requests for that
        website, even if the user types "http" in the URL bar.</p><p>HSTS is an
        important security feature for websites, and it is recommended to
        implement it along with other security features such as SSL/TLS
        encryption, proper certificate management, and secure authentication
        methods.</p>
      remediation: >-
        <p>It is recommended to set the HTTP Strict-Transport-Security
        header.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N'
  priority: 1
  remediationComplexity: 1
  category: Web Pentest
  details:
    - references: []
      locale: EN
      title: 'WSTG-INFO-02: Revealed Webserver Technology'
      vulnType: Pentest
      description: >-
        <p>Knowing the technology of a webserver can aid an attacker to
        determine how more targeted attacks can be conducted.<br>Webservers
        often times reveal the technology they are running on in response
        headers, even including concrete version numbers.<br>Attackers can then
        check if the version is affected by some kind of vulnerability and try
        to abuse it.</p><p></p>
      remediation: >-
        <p>It is recommened to publish as little information as possible about
        installed version statuses and reconfiguring the header information
        accordingly.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N'
  priority: 4
  remediationComplexity: 1
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-CONF-09: Unauthenticated File Access'
      vulnType: Pentest
      description: >-
        <p>File permissions are meant to restrict access to data so that only
        people that need access to it are allowed to.</p><p>Unrestricted file
        access poses a significant security risk due to the following
        reasons:</p><ul><li><p>Unauthorized Access: Unrestricted file access
        means that anyone, including malicious actors, can view, modify, or
        delete sensitive files. It allows unauthorized individuals or attackers
        to gain access to confidential information, personal data, intellectual
        property, or system files.</p></li><li><p>Data Leakage: Unrestricted
        file access increases the risk of data leakage. Sensitive or
        confidential information may be inadvertently or deliberately shared
        with unauthorized parties. This can lead to financial losses,
        reputational damage, compliance violations, or legal
        consequences.</p></li><li><p>Malware Injection: Malicious actors can
        exploit unrestricted file access to inject malware into the system. By
        accessing and modifying critical files, they can introduce malicious
        code, viruses, or ransomware that can compromise the integrity and
        functionality of the system.</p></li><li><p>Unauthorized Modifications:
        Unrestricted file access allows unauthorized users to modify or tamper
        with files. This can result in unauthorized changes to system
        configurations, application settings, or critical data, leading to
        system instability, operational disruptions, or compromised
        functionality.</p></li><li><p>Privilege Escalation: Unrestricted file
        access can enable privilege escalation attacks. If an attacker gains
        access to certain files with elevated privileges, they can exploit
        vulnerabilities or weak security controls to escalate their privileges,
        gaining unauthorized administrative access to the system or sensitive
        resources.</p></li><li><p>Insider Threats: Unrestricted file access
        increases the risk of insider threats. Employees or insiders with
        legitimate access to files may misuse their privileges, intentionally or
        unintentionally, by leaking sensitive information, modifying critical
        files, or stealing valuable data.</p></li><li><p>Compliance Violations:
        Unrestricted file access may lead to non-compliance with industry
        regulations and data protection standards. Many regulatory frameworks,
        such as the General Data Protection Regulation (GDPR), require
        organizations to implement appropriate access controls and restrictions
        to protect personal data and ensure privacy.</p></li></ul><p>To mitigate
        these risks, it is essential to implement strong access controls, file
        permissions, and security measures. Access should be restricted to
        authorized individuals based on the principle of least privilege, where
        users only have access to the files necessary for their roles and
        responsibilities. Regular monitoring, auditing, and encryption of
        sensitive files can further enhance security.</p>
      remediation: >-
        <p>Restrict access to the files according to the principle of least
        privileges.</p>
      references:
        - 'https://owasp.org/www-community/Broken_Access_Control'
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N'
  priority: 3
  remediationComplexity: 1
  category: Web Pentest
  details:
    - references: []
      locale: EN
      title: 'WSTG-ATHN-01: Unencrypted Login via HTTP'
      vulnType: Pentest
      description: >-
        <p>Credentials, such as usernames and passwords, are sensitive
        information that should be protected from unauthorized access or
        interception. Transporting them over encrypted channels helps to ensure
        their confidentiality, integrity, and authenticity.</p><p>Encryption is
        a process of converting plaintext into ciphertext using an encryption
        algorithm and a secret key. The resulting ciphertext can only be
        decrypted back into plaintext using the same key. This ensures that only
        authorized parties with access to the key can read the contents of the
        message.</p><p>When credentials are transported over an encrypted
        channel, such as HTTPS, the data is protected from interception and
        tampering. This is because the encryption process makes it difficult for
        attackers to read or modify the contents of the message. It also
        provides assurance that the sender is who they claim to be, and that the
        message has not been altered in transit.</p><p>Without encryption,
        credentials can be easily intercepted by attackers who have access to
        the communication channel, such as through packet sniffing or
        man-in-the-middle attacks. This can lead to unauthorized access to
        sensitive data, such as personal information, financial data, or
        intellectual property.</p><p>In summary, transporting credentials over
        encrypted channels is essential to protect them from interception and
        ensure their confidentiality, integrity, and authenticity.</p>
      observation: >-
        <p>The application can be accessed over HTTP as well as HTTPS.<br>As
        there are no HSTS headers set (refer to chapter XYZ), the user can
        freely decide if to use the encrypted or unencrypted version.<br>In the
        case of the latter one, the credentials are transported unencrypted and
        as such easily to retrieve in Man-in-the-Middle attacks.</p>
      remediation: >-
        <p>Only use secured protocols and services to run applications.<br>In
        this case turn of the possibility to use the unencrypted HTTP version of
        the webapplication.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N'
  priority: 2
  remediationComplexity: 2
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-ATHN-03: Missing Brute-Force Protection'
      vulnType: Pentest
      description: >-
        <p>Brute-force protection is a mechanism used to prevent attackers from
        guessing a user's login credentials through a trial-and-error process
        known as a brute-force attack. In this type of attack, an attacker tries
        multiple combinations of usernames and passwords until they find the
        correct one, allowing them to gain unauthorized access to the
        system.</p><p>To prevent brute-force attacks, login functionality may
        include various brute-force protection measures. One common method is to
        limit the number of login attempts within a specified time frame. For
        example, after three failed login attempts, the system may lock the
        account or impose a time delay before allowing additional login
        attempts. This prevents an attacker from trying an unlimited number of
        combinations in a short period.</p><p>Another method of brute-force
        protection is to implement a CAPTCHA (Completely Automated Public Turing
        test to tell Computers and Humans Apart) system, which requires the user
        to enter a visual or audio challenge-response test that only humans can
        solve. This helps to prevent automated bots from attempting multiple
        login attempts in quick succession.</p><p>In summary, brute-force
        protection is used to prevent attackers from guessing a user's login
        credentials through a trial-and-error process. This is typically
        achieved by limiting the number of login attempts within a specified
        time frame, or by implementing a CAPTCHA system to prevent automated
        attacks. These measures help to improve the security of login
        functionality and protect user accounts from unauthorized access.</p>
      remediation: >-
        <p>Implement countermeasures like timeouts, lockout policies and
        captchas.</p>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism
        - 'https://owasp.org/www-community/attacks/Brute_force_attack'
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N'
  priority: 2
  remediationComplexity: 2
  category: Web Pentest
  details:
    - references:
        - >-
          https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
      locale: EN
      title: 'WSTG-ATHN-03: Weak Lockout Policy'
      vulnType: Pentest
      description: >-
        <p>A lockout policy is a security mechanism used to prevent unauthorized
        access to an account by locking the account after a certain number of
        failed login attempts. This is done to prevent brute-force attacks, in
        which an attacker tries to guess a user's login credentials by
        repeatedly submitting different username and password
        combinations.</p><p>The lockout policy typically includes the number of
        failed login attempts that trigger the account lockout, as well as the
        duration of the lockout period. For example, a lockout policy might
        specify that after five failed login attempts, the account will be
        locked for 30 minutes.</p><p>Lockout policies help to improve the
        security of user accounts by preventing attackers from gaining
        unauthorized access through brute-force attacks. They also encourage
        users to create strong passwords and take other security measures to
        protect their accounts, as they know that repeated failed login attempts
        could lead to a lockout.</p><p>However, lockout policies can also have
        drawbacks if they are set too strictly. For example, if the number of
        failed login attempts is set too low, users may accidentally trigger the
        lockout policy by mistyping their password or forgetting their password
        and attempting to reset it. Additionally, if the lockout period is too
        long, it can be frustrating for users who need to access their account
        urgently. As such, lockout policies should be carefully designed and
        tested to balance security needs with user experience.</p>
      remediation: >-
        <p>Implement according policies that lockout accounts after a predefined
        amount of failed attempts.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N'
  priority: 3
  remediationComplexity: 1
  category: Web Pentest
  details:
    - references:
        - >-
          https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
      locale: EN
      title: 'WSTG-ATHN-07: Weak Password Policy'
      vulnType: Pentest
      description: >-
        <p>A password policy is a set of rules and guidelines that dictate the
        requirements for creating and using passwords in a system. The primary
        purpose of a password policy is to improve the security of user accounts
        by ensuring that passwords are strong, unique, and not easily
        guessable.</p><p>Password policies may include requirements such as
        minimum length, complexity, and expiration period. For example, a
        password policy might require that passwords be at least 8 characters
        long, contain a combination of letters, numbers, and symbols, and expire
        every 90 days. The policy may also prohibit the use of common passwords
        or dictionary words, and may enforce a limit on the number of failed
        login attempts before locking the account.</p><p>Password policies are
        important because weak passwords are a common vulnerability that can be
        easily exploited by attackers. By requiring strong passwords and
        enforcing regular password changes, password policies can help to
        prevent unauthorized access and data breaches.</p><p>However, password
        policies can also have drawbacks if they are too strict or complicated.
        For example, if the requirements for password complexity are too
        difficult to remember, users may resort to writing down their passwords
        or reusing the same password across multiple accounts, which can also
        pose security risks. As such, password policies should be carefully
        designed to balance security needs with user experience and
        convenience.</p>
      remediation: >-
        <p>Implement a strong password policy that hinders users to set weak
        passwords.</p><p>Best practices include:<br></p><ol><li><p>Length:
        Encourage the use of longer passwords, typically a minimum of 12
        characters or more. Longer passwords are generally more secure as they
        increase the number of possible combinations, making them harder to
        guess or crack.</p></li><li><p>Complexity: Require a combination of
        uppercase and lowercase letters, numbers, and special characters. This
        ensures a broader range of characters are used, making passwords more
        resistant to dictionary-based attacks.</p></li><li><p>Avoid common
        patterns and predictable information: Discourage the use of easily
        guessable patterns (e.g., "123456" or "abcdef") and information commonly
        associated with users (e.g., names, birthdates, or common words). These
        can be easily exploited by attackers.</p></li><li><p>Avoid forced
        regular password changes: Research suggests that frequent password
        changes may lead to weaker passwords, as users tend to choose simpler
        passwords when forced to change them frequently. Instead, encourage
        password changes when there is a suspected compromise or evidence of
        weak security.</p></li><li><p>Password blacklisting: Maintain a list of
        commonly used or compromised passwords and prevent users from selecting
        them. This helps to block the use of easily guessable or breached
        passwords.</p></li><li><p>Two-factor authentication (2FA): Encourage or
        require the use of additional authentication factors, such as SMS codes,
        authenticator apps, or hardware tokens, to add an extra layer of
        security to user accounts. This helps protect against unauthorized
        access even if the password is compromised.</p></li><li><p>User
        education and awareness: Provide clear guidelines to users on how to
        create strong passwords and the importance of good password hygiene.
        Educate users about the risks of password reuse, phishing attacks, and
        the significance of protecting their accounts.</p></li></ol><p>Remember
        that password complexity policies should be balanced to ensure they are
        strong enough to resist attacks but not overly burdensome for users.
        Striking the right balance promotes better security practices and user
        compliance.<br></p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
  priority: 4
  remediationComplexity: 3
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-ATHZ-03: Elevation of Privileges'
      vulnType: Pentest
      description: >-
        <p>Privilege escalation refers to the act of gaining increased access or
        permissions on a computer system, network, or application beyond what
        was originally authorized. This can be achieved through exploiting
        vulnerabilities, misconfigurations, or weaknesses in security
        controls.</p><p>Privilege escalation is generally considered a bad thing
        because it can lead to unauthorized access and control over sensitive
        information, systems, and resources. Attackers can use privilege
        escalation to perform malicious activities such as stealing data,
        modifying data, installing malware, or disrupting
        services.</p><p>Privilege escalation can also undermine the integrity
        and confidentiality of data, as well as violate privacy laws and
        regulations. It can lead to financial losses, reputational damage, and
        legal consequences for both individuals and organizations.</p><p>In
        summary, privilege escalation is a bad thing because it can lead to
        unauthorized access and control, which can result in serious security
        and privacy breaches.</p>
      remediation: >-
        <p>The separation of user rights should not only take place on the GUI
        level. Functions and endpoints meant for administrative purposes should
        only be available to users that are assigned to the according
        groups.</p><p>Implement according measures to ensure a correct
        separation of user rights and functions. </p><p></p>
      references: []
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N'
  priority: 2
  remediationComplexity: 1
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-SESS-02: Session-Cookie without httpOnly-Flag'
      vulnType: Pentest
      description: >-
        <p>The httpOnly flag is an optional parameter for cookies and specifies
        that cookies secured with this flag may not be read via client-side
        scripts.</p><p>In the context of cross-site scripting attacks, for
        example, attempts are often made to take over a user's session by
        reading the cookie via JavaScript. This attack vector is prevented by
        setting the httpOnly flag.</p>
      remediation: <p>Set the <em>httpOnly </em>flag for all session relevant cookies.</p>
      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
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N'
  priority: 4
  remediationComplexity: 2
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-SESS-05: Cross Site Request Forgery (CSRF)'
      vulnType: Pentest
      description: >-
        <p>Cross-site request forgery (CSRF or XSRF) is a type of attack where a
        malicious actor tricks a user into performing an action on a website
        without their knowledge or consent. This is achieved by sending a
        request from a user's browser that appears to originate from a
        legitimate website that the user is logged into, but is actually sent by
        the attacker. <br>The purpose of a CSRF attack is to exploit the trust
        that a website has in a user's browser, allowing the attacker to perform
        actions on the user's behalf, such as making unauthorized purchases or
        changing account settings.</p>
      remediation: >-
        <p>To protect against CSRF attacks, websites can implement
        countermeasures such as using CSRF tokens or requiring user confirmation
        for sensitive actions.<br>The tokens should be set for all critical
        functions.<br>More info can be found in the cheat sheet from the
        reference section.</p>
      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://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L'
  priority: 3
  remediationComplexity: 2
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-INPV-01: Reflected Cross-Site-Scripting'
      vulnType: Pentest
      description: >-
        <p>Cross-Site Scripting (XSS) is a type of web security vulnerability
        where attackers inject malicious scripts into a website or web
        application. These scripts are then executed in the context of other
        users' browsers, allowing the attacker to carry out malicious actions.
        XSS attacks exploit the trust between a user and a website, often
        targeting areas where user-generated content is displayed without proper
        validation or escaping.</p><p>By exploiting this vulnerability,
        cross-site scripting attacks on website visitors are possible. Possible
        effects of successful cross-site scripting attacks
        include:</p><ul><li><p>Stealing credentials, session information,
        cookies,</p></li><li><p>Complete takeover of the client browser,
        including remote control of the client, if exploits exist for the
        browser used,</p></li><li><p>compromising the functionality of the web
        application,</p></li><li><p>alteration of the content and design of the
        pages.</p></li></ul><p>In the case of reflected XSS the attacker needs
        the victim to execute the code, e.g. by sending him a malicious link he
        needs to click.</p>
      remediation: >-
        <p>Countermeasures against XSS include input validation, output
        encoding, and implementing content security policies. This includes
        verifying that input is of the correct type and length, and that it does
        not contain any potentially malicious characters or code. Input
        validation ensures only legitimate data is accepted, output encoding
        prevents script execution, and content security policies restrict the
        sources of allowed scripts, reducing the attack surface. Regular updates
        and secure coding practices enhance protection.</p><p>More info can be
        found in the OWASP cheat sheet from the reference section.</p><p>A check
        via JavaScript on the client side is not sufficient, since this can also
        be manipulated by the client.</p>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting
        - >-
          https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L'
  priority: 4
  remediationComplexity: 2
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-INPV-02: Stored Cross-Site-Scripting'
      vulnType: Pentest
      description: >-
        <p>Cross-Site Scripting (XSS) is a type of web security vulnerability
        where attackers inject malicious scripts into a website or web
        application. These scripts are then executed in the context of other
        users' browsers, allowing the attacker to carry out malicious actions.
        XSS attacks exploit the trust between a user and a website, often
        targeting areas where user-generated content is displayed without proper
        validation or escaping.</p><p>By exploiting this vulnerability,
        cross-site scripting attacks on website visitors are possible. Possible
        effects of successful cross-site scripting attacks
        include:</p><ul><li><p>Stealing credentials, session information,
        cookies,</p></li><li><p>Complete takeover of the client browser,
        including remote control of the client, if exploits exist for the
        browser used,</p></li><li><p>compromising the functionality of the web
        application,</p></li><li><p>alteration of the content and design of the
        pages.</p></li></ul><p>In the case of stored XSS the attacker is able to
        place the malicious code inside the application. He then needs to wait
        for his victims to trigger the code e.g. by using a specific function
        inside the application.</p>
      remediation: >-
        <p>Countermeasures against XSS include input validation, output
        encoding, and implementing content security policies. This includes
        verifying that input is of the correct type and length, and that it does
        not contain any potentially malicious characters or code. Input
        validation ensures only legitimate data is accepted, output encoding
        prevents script execution, and content security policies restrict the
        sources of allowed scripts, reducing the attack surface. Regular updates
        and secure coding practices enhance protection.</p><p>More info can be
        found in the OWASP cheat sheet from the reference section.</p><p>A check
        via JavaScript on the client side is not sufficient, since this can also
        be manipulated by the client.</p>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting
        - >-
          https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N'
  priority: 2
  remediationComplexity: 2
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-CRYP-01: Weak TLS Configuration'
      vulnType: Pentest
      description: >-
        <p>Transport Layer Security (TLS) is a cryptographic protocol that
        provides secure communication over a network by encrypting data sent
        between two devices. TLS is commonly used to secure HTTP connections,
        which are used to transfer data between web servers and clients, and is
        often referred to as HTTPS.</p><p>TLS works by creating a secure
        communication channel between two devices, using a combination of public
        key encryption and symmetric key encryption. During the initial
        connection, the client and server exchange cryptographic keys to
        establish a secure session. The keys are then used to encrypt and
        decrypt data sent between the two devices.</p><p>While Transport Layer
        Security (TLS) is a widely used and effective protocol for securing
        communication over a network, it is not without weaknesses. Some of the
        weaknesses of TLS include:</p><ul><li><p>Weak cipher suites: Some older
        cipher suites used in TLS are now considered weak and vulnerable to
        attacks, such as the infamous POODLE attack. It is important to use
        strong cipher suites and disable any deprecated or insecure cipher
        suites.</p></li><li><p>Certificate authority (CA) vulnerabilities: The
        trust model of TLS relies on the security of the CA system, which can be
        vulnerable to attacks such as phishing or compromise of CAs. This can
        result in fake or fraudulent certificates being issued, which can then
        be used to perform man-in-the-middle
        attacks.</p></li><li><p>Implementation flaws: TLS implementations can
        contain flaws that could be exploited by attackers, such as the
        Heartbleed vulnerability, which allowed attackers to steal sensitive
        information from servers using a specific version of the OpenSSL
        cryptographic library.</p></li><li><p>Key management: TLS relies on
        secure key management practices to ensure the integrity and
        confidentiality of data in transit. If keys are compromised or not
        managed properly, it can result in the encryption being broken and
        sensitive information being exposed.</p></li><li><p>Attacks against the
        protocol itself: New attacks against the TLS protocol are regularly
        discovered and may require updates or changes to the protocol to address
        them.</p></li></ul><p>It is important to stay up to date with the latest
        best practices for using TLS, including using strong cipher suites,
        implementing proper certificate validation, and regularly updating TLS
        implementations to address new vulnerabilities.</p>
      remediation: >-
        <p>Disable SSLv3.<br>Update the Webserver and SSL implementation to the
        latest version.<br>Disable weak ciphers (SEED, IDEA, RC2, RC4) on the
        server.<br>Configure the server to use a 2048-bit Diffie-Hellman
        group.<br>Disable cipher with 64-bit block size (3DES, DES,
        Blowfish).<br>Disable HTTP compression on the server or ignore if there
        is no secret in the page.<br>Do not use self signed certificates for
        internet facing services.</p>
      references:
        - >-
          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
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L'
  priority: 4
  remediationComplexity: 1
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-BUSL-09: Upload of Malicious Files'
      vulnType: Pentest
      description: >-
        <p>Allowing users to upload files to a web server can pose significant
        risks, as it can provide an opportunity for attackers to upload and
        execute malicious code on the server. Some of the risks of allowing file
        uploads include:</p><ul><li><p>Malware distribution: Attackers can use
        file uploads to distribute malware, such as viruses, worms, or Trojans,
        to other users who download the infected files.</p></li><li><p>Website
        defacement: Attackers can upload malicious files that can deface the
        website, altering its appearance and possibly damaging its
        reputation.</p></li><li><p>Server compromise: Attackers can use file
        uploads to gain access to the server and execute remote code, allowing
        them to take full control of the system and potentially steal sensitive
        information.</p></li><li><p>Backdoor access: Attackers can use file
        uploads to create a backdoor on the server, allowing them to access the
        system even after they are removed.</p></li><li><p>Resource exhaustion:
        Attackers can upload files that consume a large amount of server
        resources, such as disk space or memory, causing the server to crash or
        become unavailable.</p></li></ul>
      remediation: >-
        <p>It is recommended performing a server-side check of the file
        extensions as well as the file type. However, checking the file
        extension itself is not a sufficient protection and in addition the
        magic bytes of the files uploaded should be checked.</p><p>Furthermore,
        uploaded files should be checked for malware using antivirus software.
        Possible embedded objects should be removed. Among other things,
        Microsoft Office documents, PDF files and images can contain embedded
        objects, which are not always detected by antivirus programs. These can
        be converted to safe files using file disinfection (for example, PDF to
        PDFA). Further recommendations can be found in the OWASP Guideline.</p>
      references:
        - >-
          https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N'
  priority: 3
  remediationComplexity: 1
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-BUSL-07: Application Logic Flaw - Passwords length visible'
      vulnType: Pentest
      description: >-
        <p>Hiding passwords in applications in general is a good idea.
        </p><p>Access to such sensitive info should be restricted as good as
        possible and revealing should ask you for confirmation. The length of
        the hiding characters should always be the same so that no conclusions
        can be drawn on the actual length of the password.</p>
      remediation: >-
        <p>Mask the password in a way that no conclusions regarding the length
        can be drawn.</p>
      references: []
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:L/A:N'
  priority: 2
  remediationComplexity: 3
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-SESS-03: Session Fixation'
      vulnType: Pentest
      description: >-
        <p>Session fixation is a vulnerability that allows an attacker to hijack
        a user's session on a web application. This type of attack involves
        manipulating the session ID (identifier) used to authenticate a user's
        session.</p><p>An attacker can exploit this vulnerability by providing a
        user with a valid session ID, often obtained by sending a crafted link
        or through a phishing attack. If the user logs in using the provided
        session ID, the attacker can then use the same session ID to gain access
        to the user's account or carry out actions on behalf of the
        user.</p><p>To prevent session fixation, web applications should ensure
        that a new session ID is generated for each user upon login, rather than
        accepting a pre-existing session ID. Additionally, the session ID should
        be regenerated upon certain events such as a change in user privilege or
        login status. This helps to ensure that the session ID cannot be fixed
        and is therefore more secure.</p>
      remediation: >-
        <p>To protect against session fixation, there are several best practices
        that web applications should follow:</p><ul><li><p>Regenerate Session
        IDs: Upon login, web applications should generate a new session ID for
        each user. This ensures that the session ID cannot be predetermined or
        fixed by an attacker. Additionally, the session ID should be regenerated
        upon certain events such as a change in user privilege or login
        status.</p></li><li><p>Use Strong Session IDs: Session IDs should be
        long, random, and complex. This makes them difficult for an attacker to
        guess or brute-force.</p></li><li><p>Use HTTPS: Web applications should
        use HTTPS to encrypt all communication between the client and server.
        This helps to prevent session hijacking and other types of attacks that
        can compromise the user's session.</p></li><li><p>Use HttpOnly and
        Secure Cookies: HttpOnly cookies cannot be accessed by client-side
        scripts, which helps to prevent cross-site scripting (XSS) attacks.
        Secure cookies can only be transmitted over HTTPS, which helps to
        prevent the interception of session IDs over unsecured
        connections.</p></li><li><p>Implement Session Timeout: Web applications
        should implement a session timeout to automatically log out users after
        a period of inactivity. This reduces the risk of session hijacking if
        the user leaves their session open on a public computer or if their
        device is lost or stolen.</p></li></ul><p>For ASP applications the OWASP
        foundation has some additional recommnedations on how this situation
        could be
        tackled:<br>https://owasp.org/www-community/controls/Session_Fixation_Protection</p>
      references:
        - 'https://owasp.org/www-community/attacks/Session_fixation'
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N'
  priority: 3
  remediationComplexity: 1
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-SESS-01: Session-Token in URL'
      vulnType: Pentest
      description: >-
        <p>Session tokens are used to identify and authenticate a user's session
        on a website or application. They need to be secured to prevent
        unauthorized access to a user's account and sensitive information, such
        as personal data or financial information. If a session token is
        compromised, an attacker could hijack a user's session and gain access
        to their account, potentially causing significant harm to the user and
        the organization.</p><p>When session tokens are sent as part of the URL,
        they appear in the user's browser history and in log files on web
        servers or proxies. A compromise of the user's client might allow an
        attacker to get access to the session token via the history and take
        over the session if it has not already been invalidated.
        <br>Administrators may have access the session tokens of all users via
        the logs of proxies or web servers. <br>A compromised web server would
        allow an attacker to access all sessions or accounts.</p>
      remediation: >-
        <p>Session tokens should not be send as part of the URL. <br>Using HTTP
        cookies or hidden fields in forms submitted with POST parameters should
        be used as a safe way of transmitting session tokens. This measure
        ensures that the session tokens are not visible in the browser history
        or in log files.</p>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/06-Session_Management_Testing/01-Testing_for_Session_Management_Schema
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N'
  priority: 2
  remediationComplexity: 1
  category: Web Pentest
  details:
    - references: []
      locale: EN
      title: 'WSTG-IDNT-04: User Enumeration'
      vulnType: Pentest
      description: >-
        <p>User enumeration is a technique used by attackers to discover valid
        usernames or email addresses associated with user accounts in a web
        application. This is typically done by submitting login requests with
        various usernames or email addresses and observing the response from the
        server.</p><p>The response from the server can indicate whether a
        username or email address is valid or not. For example, if an attacker
        submits a login request with an invalid username, the server may respond
        with a message indicating that the username is incorrect. On the other
        hand, if the attacker submits a login request with a valid username, the
        server may respond with a message indicating that the password is
        incorrect. By using this technique, attackers can gradually build a list
        of valid usernames or email addresses that can be used in further
        attacks, such as password guessing or targeted phishing
        attacks.</p><p>User enumeration is dangerous because it provides
        attackers with a list of valid usernames or email addresses that can be
        used to launch more targeted attacks against the web application or its
        users. For example, if an attacker knows that a particular email address
        is associated with a user account on the web application, they can
        launch a phishing attack that appears to come from the web application
        and requests the user to reset their password, giving the attacker
        access to the user's account.</p><p>Furthermore, user enumeration can
        also help attackers understand the structure of the web application and
        identify potential vulnerabilities. For instance, if the server responds
        differently to invalid and valid usernames, this may indicate that the
        application is vulnerable to a timing attack, where an attacker can use
        timing differences to determine valid usernames or
        passwords.</p><p>Overall, user enumeration is a dangerous vulnerability
        in web applications that can be exploited by attackers to launch
        targeted attacks and gain unauthorized access to sensitive data. It is
        important for web application developers to implement measures to
        prevent user enumeration, such as returning the same error message for
        all login failures or using CAPTCHA to prevent automated login
        attempts.</p>
      remediation: >-
        <p>Generate unspecific error messages that do not allow an attacker to
        draw conclusions if a user exists or not.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N'
  priority: 2
  remediationComplexity: 1
  category: Web Pentest
  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
      locale: EN
      title: 'WSTG-ATHN-06: Browser Cache holding Sensitive Data'
      vulnType: Pentest
      description: >-
        <p>Browser Cache Weaknesses refer to vulnerabilities in web applications
        that allow sensitive information, such as personal data, authentication
        tokens, or other confidential information, to be stored in the cache of
        the user's web browser. This information can remain in the cache even
        after the user logs out of the web application or closes the browser,
        and can be accessible to attackers who gain access to the user's
        computer or device.</p><p>These weaknesses are dangerous because they
        can enable attackers to obtain sensitive information without needing to
        directly attack the web application itself. Instead, attackers can
        exploit the weakness by accessing the user's cache, either through
        physical access to the user's device or by using malware or other
        techniques to gain remote access.</p><p>Once an attacker gains access to
        the cached information, they can use it for a variety of malicious
        purposes, such as identity theft, fraud, or unauthorized access to the
        web application or other systems that use the same authentication
        tokens.</p><p>To mitigate Browser Cache Weaknesses, developers should
        implement appropriate measures, such as using HTTPS connections, setting
        proper caching headers, and implementing mechanisms to clear the cache
        of sensitive information when the user logs out or closes the browser.
        Additionally, users should be educated on the risks of cached
        information and advised to clear their browser cache regularly.</p>
      observation: <p></p><p></p>
      remediation: >-
        <p>Implement a strict control of the browser's cache for sensitive data
        by using the Cache-Control headers.<br>More info can be found here:
        https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#web-content-caching</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N'
  priority: 2
  remediationComplexity: 1
  category: Web Pentest
  details:
    - references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL
      locale: EN
      title: 'WSTG-APIT-01: Exposed GraphQL Playground'
      vulnType: Pentest
      description: >-
        <p>GraphQL Playground is a graphical user interface (GUI) that is used
        to test, explore, and interact with GraphQL APIs. It provides an
        interactive environment that allows developers to query a GraphQL API,
        see the schema, and test various queries and mutations.</p><p>GraphQL
        Playground is a useful tool for both frontend and backend developers, as
        it enables them to easily test and iterate on their GraphQL API without
        having to manually construct requests and parse responses. With GraphQL
        Playground, developers can quickly test out new queries and mutations,
        see the results in real-time, and experiment with different parameters
        and inputs.</p><p>Additionally, GraphQL Playground provides a variety of
        features that make working with GraphQL APIs easier, such as syntax
        highlighting, autocomplete, and documentation. It can also be used to
        view the GraphQL schema, explore the available types, and understand the
        structure of the API.</p><p>Overall, GraphQL Playground is a powerful
        tool that simplifies the process of developing and testing GraphQL APIs,
        and makes it easier for developers to build high-quality
        applications.<br><br>From an attacker's perspective all this info can
        come in useful, leaving them with a documentation what and how things
        are working.</p>
      remediation: >-
        <p>Restrict access to the GrapQL Playground, so only authorized users or
        systems can access it.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L'
  priority: 2
  remediationComplexity: 1
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-BUSL-07: Application Misuse due to missing Throttling'
      vulnType: Pentest
      description: >-
        <p>Abusing an application by sending masses of requests can have several
        negative impacts on an application:<br>- It might get slow or even
        unresponsive<br>- It gets flooded with garbage data which makes it
        harder to use the app<br>- Flooding the database might kill backend
        systems or result in unexpected behavior<br>- ...<br></p>
      remediation: >-
        <p>Implement measures that reduce the amount of requests that can be
        made within a certain timeframe from a dedicated IP.</p>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/10-Business_Logic_Testing/07-Test_Defenses_Against_Application_Misuse
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N'
  priority: 1
  remediationComplexity: 2
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-SESS-06: Missing Session Termination'
      vulnType: Pentest
      description: >-
        <p>Session termination is an important part of the session lifecycle.
        Reducing to a minimum the lifetime of the session tokens decreases the
        likelihood of a successful session hijacking attack. This can be seen as
        a control against preventing other attacks like Cross Site Scripting and
        Cross Site Request Forgery. Such attacks have been known to rely on a
        user having an authenticated session present. Not having a secure
        session termination only increases the attack surface for any of these
        attacks.</p><p>A secure session termination requires at least the
        following components:</p><ul><li><p>Availability of user interface
        controls that allow the user to manually log out.</p></li><li><p>Session
        termination after a given amount of time without activity (session
        timeout).</p></li><li><p>Proper invalidation of server-side session
        state.</p></li></ul>
      remediation: >-
        <p>Sessions should get terminated automatically after a certain amount
        of time.<br>Sessions should also get terminated when a user uses the
        logout function of the application.<br>Make sure to find the right
        balance between user experience and security.<br><br></p>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/06-Session_Management_Testing/06-Testing_for_Logout_Functionality
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:H/A:N'
  priority: 3
  remediationComplexity: 2
  category: Web Pentest
  details:
    - references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/10-Business_Logic_Testing/07-Test_Defenses_Against_Application_Misuse
      locale: EN
      title: 'WSTG-BUSL-07: Application Misuse Input Validation'
      vulnType: Pentest
      description: >-
        <p>Input validation is a crucial aspect of web security that involves
        verifying and sanitizing user input to prevent malicious or unintended
        actions. In web applications, user input can come from various sources,
        such as form submissions, URL parameters, and HTTP headers, and it is
        important to ensure that this input is valid and safe to use before
        processing it.</p><p>Input validation involves checking that the user
        input conforms to expected formats, types, and ranges, and rejecting any
        input that does not meet these criteria. This can help prevent a wide
        range of attacks, including SQL injection, cross-site scripting (XSS),
        and command injection, which can be used to steal sensitive data, modify
        application behavior, or take over the server.</p><p>In addition to
        validating input, it is also important to sanitize it by removing any
        potentially dangerous characters or sequences, such as HTML tags,
        JavaScript code, or shell commands. This can help prevent attacks that
        rely on injecting malicious code into the application, and can help
        ensure that the user input is used only for its intended
        purpose.</p><p>Overall, input validation and sanitization are essential
        techniques for ensuring web security, and should be applied consistently
        throughout the application to help prevent a wide range of attacks. By
        carefully validating and sanitizing user input, developers can help
        protect their users' data and prevent malicious actors from exploiting
        vulnerabilities in the application.</p>
      remediation: >-
        <p>Input validation should be implemented throughout the application.
        Special characters and things like URLs should be sanitized.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N'
  priority: 2
  remediationComplexity: 2
  category: Web Pentest
  details:
    - locale: EN
      title: 'WSTG-ATHN-03: Faulty Brute-Force Protection'
      vulnType: Pentest
      description: >-
        <p>Brute-force protection is a mechanism used to prevent attackers from
        guessing a user's login credentials through a trial-and-error process
        known as a brute-force attack. In this type of attack, an attacker tries
        multiple combinations of usernames and passwords until they find the
        correct one, allowing them to gain unauthorized access to the
        system.</p><p>To prevent brute-force attacks, login functionality may
        include various brute-force protection measures. One common method is to
        limit the number of login attempts within a specified time frame. For
        example, after three failed login attempts, the system may lock the
        account or impose a time delay before allowing additional login
        attempts. This prevents an attacker from trying an unlimited number of
        combinations in a short period.</p><p>Another method of brute-force
        protection is to implement a CAPTCHA (Completely Automated Public Turing
        test to tell Computers and Humans Apart) system, which requires the user
        to enter a visual or audio challenge-response test that only humans can
        solve. This helps to prevent automated bots from attempting multiple
        login attempts in quick succession.</p><p>In summary, brute-force
        protection is used to prevent attackers from guessing a user's login
        credentials through a trial-and-error process. This is typically
        achieved by limiting the number of login attempts within a specified
        time frame, or by implementing a CAPTCHA system to prevent automated
        attacks. These measures help to improve the security of login
        functionality and protect user accounts from unauthorized access.</p>
      remediation: >-
        <p>Implement a valuable protection mechanism against brute-force
        attempts.<br>Detailed info can be found in the description section of
        this finding.<br>In this case check why the implemented protection is
        not working as designed.</p>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism
        - 'https://owasp.org/www-community/attacks/Brute_force_attack'
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N'
  priority: 1
  remediationComplexity: 1
  category: Web Pentest
  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: 'WSTG-ERRH-01: Detailed Stack Traces'
      vulnType: Pentest
      description: >-
        <p>In a web app, a stack trace is a report that shows the sequence of
        function calls that led to an error or exception being thrown. It helps
        developers diagnose and fix issues in the code by identifying the
        specific code paths that caused the error.</p><p>However, if a detailed
        stack trace is visible to an attacker, it can reveal sensitive
        information about the application, including the underlying
        architecture, technologies, and potential vulnerabilities. An attacker
        can use this information to exploit the application, gain unauthorized
        access, or launch other types of attacks. Therefore, it is crucial to
        protect the stack trace from being accessible to unauthorized users and
        to minimize the amount of sensitive information it reveals.</p>
      remediation: >-
        <p>Stack traces should be disabled to not reveal any sensitive info that
        might be useful to an attacker.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N'
  priority: 1
  remediationComplexity: 1
  details:
    - locale: EN
      title: 'WSTG-CONF-12: Content Security Header Configuration'
      vulnType: Pentest
      description: >-
        <p>The CSP (Content Security Policy) header is a security feature used
        in web applications to specify which sources of content, such as
        scripts, styles, images, and other resources, are allowed to be loaded
        and executed by a web page. It helps protect against cross-site
        scripting (XSS) attacks and data injection attacks by controlling the
        origins from which content can be loaded and executed in a web page's
        context. CSP enhances web security by reducing the risk of unauthorized
        or malicious code execution, making it more challenging for attackers to
        inject and execute harmful scripts on a website.</p>
      remediation: >-
        <p>Configure the CSP header according to best practices to increase
        security. <br>For further info refer to the OWASP cheat sheet in the
        resource section.</p>
      references:
        - >-
          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://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
      customFields: []
  category: Web Pentest

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N'
  priority: 3
  remediationComplexity: 2
  details:
    - locale: EN
      title: 'WSTG-ATHZ-04: Insecure Direct Object Reference (IDOR)'
      vulnType: Pentest
      description: >-
        <p>IDOR, or Insecure Direct Object Reference, is a web security
        vulnerability that occurs when an application provides direct access to
        objects based on user-supplied input, such as file names, URLs, or
        database keys. In an IDOR vulnerability, an attacker can manipulate
        these references to access unauthorized data or perform actions they
        shouldn't have access to. IDOR arises when an application lacks proper
        access controls and relies solely on user input to identify and access
        objects or resources. An attacker can exploit IDOR by tampering with
        parameters (e.g., changing a URL parameter or modifying hidden fields in
        a form) to access or manipulate data or actions that they are not
        authorized to perform. IDOR vulnerabilities can lead to unauthorized
        data exposure, data manipulation, account takeover, or even the
        modification or deletion of sensitive records.</p><p>In summary, IDOR is
        a security flaw that occurs when an application doesn't adequately
        protect against direct manipulation of object references, potentially
        allowing attackers to access or manipulate data or actions they should
        not have access to. It's important for developers to implement robust
        access controls and validate user input to mitigate IDOR
        vulnerabilities.</p>
      remediation: >-
        <p>To prevent IDOR vulnerabilities, developers should implement proper
        access controls, validate user input, and use authentication and
        authorization mechanisms to ensure that users can only access the data
        and actions they are authorized for.<br>Further details can be found in
        the reference section.</p>
      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://portswigger.net/web-security/access-control/idor'
        - >-
          https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html
      customFields: []
  category: Web Pentest

- cvssv3: 'CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N'
  priority: 1
  remediationComplexity: 1
  details:
    - locale: EN
      title: 'WSTG-CONF-05: Administrative Interfaces'
      vulnType: Pentest
      description: >-
        <p>Exposing administrative interfaces of a web application to the public
        increases the risk of unauthorized access and potential security
        breaches. Keeping these interfaces restricted to the corporate network
        or dedicated management machines helps mitigate these risks. This
        approach:</p><ul><li><p><strong>Reduces Attack Surface:</strong>
        Limiting access to administrative interfaces minimizes the exposure of
        critical components to the external environment, lowering the chances of
        exploitation.</p></li><li><p><strong>Enhances Confidentiality:</strong>
        Internal access ensures that sensitive information, configurations, and
        functionalities are not easily accessible to unauthorized external
        entities.</p></li><li><p><strong>Mitigates Unauthorized Access:</strong>
        External exposure increases the likelihood of unauthorized users
        attempting to access administrative functions. Restricting access to
        internal networks adds an extra layer of
        protection.</p></li><li><p><strong>Protects Against Brute Force
        Attacks:</strong> Limiting access to specific networks reduces the
        attack surface for brute force attacks on administrative
        credentials.</p></li><li><p><strong>Preserves Availability:</strong> By
        preventing potential attacks from the public internet, the web
        application's administrative functionalities are less susceptible to
        denial-of-service attempts or other
        disruptions.</p></li><li><p><strong>Aligns with Least Privilege
        Principle:</strong> Granting access only to trusted networks adheres to
        the principle of least privilege, ensuring that only necessary entities
        have access to sensitive functionalities.</p></li></ul><p>In summary,
        restricting access to administrative interfaces helps maintain a more
        secure and controlled environment, safeguarding critical aspects of the
        web application from external threats.</p>
      remediation: >-
        <p>Restrict access to administrative functions to only allow access from
        specific IPs and / or networks.<br></p>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces
      customFields: []
  category: Web Pentest

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N'
  priority: 3
  remediationComplexity: 2
  details:
    - locale: EN
      title: 'WSTG-CLNT-13: CSV Injection'
      description: >-
        <p>CSV injection, also known as formula injection, occurs when a cell in
        a CSV (Comma-Separated Values) file contains data that, when interpreted
        by a spreadsheet program, is treated as a formula rather than plain
        text. This can be dangerous due to the following
        reasons:</p><ul><li><p><strong>Arbitrary Code Execution:</strong> An
        attacker can embed malicious formulas or commands into the CSV file.
        When opened by a spreadsheet program, these formulas may execute
        arbitrary code on the user's system.</p></li><li><p><strong>Spreadsheet
        Program Vulnerabilities:</strong> Certain spreadsheet programs may have
        vulnerabilities that can be exploited through CSV injection. Attackers
        leverage these vulnerabilities to execute malicious
        actions.</p></li><li><p><strong>Data Manipulation:</strong> CSV
        injection can lead to unauthorized manipulation of data within the
        spreadsheet. This could result in data loss, corruption, or unauthorized
        access to sensitive information.</p></li><li><p><strong>Phishing
        Attacks:</strong> Malicious formulas can be crafted to create phishing
        scenarios, tricking users into revealing sensitive information or
        performing unintended actions.</p></li><li><p><strong>Cross-Site
        Scripting (XSS):</strong> In web applications that process CSV uploads,
        CSV injection may lead to XSS attacks if the injected data is reflected
        back to users without proper validation and sanitization.</p></li></ul>
      remediation: >-
        <ul><li><p><strong>Avoid Executable Content:</strong> Ensure that
        user-input data in CSV files is treated as plain text and not as
        executable content.</p></li><li><p><strong>Sanitize Input:</strong>
        Implement strict input validation and sanitization mechanisms to prevent
        the inclusion of formulas or malicious
        content.</p></li><li><p><strong>Use Cell Formatting:</strong> Apply
        proper cell formatting to explicitly define data types, preventing the
        automatic execution of formulas.</p></li><li><p><strong>Educate
        Users:</strong> Raise awareness among users about the risks of opening
        CSV files from untrusted sources and the importance of validating file
        contents.</p></li></ul>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/13-Testing_for_Cross_Site_Script_Inclusion
      customFields: []
  category: Web Pentest

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N'
  priority: null
  remediationComplexity: null
  details:
    - locale: EN
      title: 'WSTG-CRYP-04: Weak Hashing'
      vulnType: Pentest
      description: >-
        <p>Hashing is a one-way process of converting input data (of any size)
        into a fixed-length string of characters, which is typically a hash
        value or digest. The output, known as the hash, should be unique to the
        input data, making it practically impossible to reverse the
        process.</p><p>Hash functions are commonly used to verify the integrity
        of data. Even a small change in the input data should result in a
        substantially different hash value. This property helps detect tampering
        or corruption.</p><p>Hashing is widely employed to secure passwords.
        Storing hashed passwords instead of plaintext enhances security.
        However, using weak hashing algorithms or short hash lengths makes it
        easier for attackers to perform brute-force or rainbow table
        attacks.</p><p><strong>Security Risks of Weak
        Hashing:</strong></p><ul><li><p><strong>Brute-Force Attacks:</strong>
        Weak hash algorithms can be more easily broken using brute-force
        attacks, where attackers systematically try all possible inputs to find
        a match.</p></li><li><p><strong>Collision Vulnerabilities:</strong> Weak
        hashing may lead to collisions, where different inputs produce the same
        hash output. This compromises the uniqueness of the hash and introduces
        security vulnerabilities.</p></li></ul><p>Many security standards and
        regulations mandate the use of strong and cryptographically secure
        hashing algorithms to protect sensitive data. Weak hashing practices may
        result in non-compliance and increased susceptibility to unauthorized
        access.</p><p>In summary, using weak hashing algorithms poses security
        risks by making it easier for attackers to compromise password security,
        undermine data integrity, and violate privacy. Strong and
        well-established hashing practices are essential for robust data
        protection</p>
      observation: <p>Scoring based on situation and used hashing alg</p>
      remediation: >-
        <ul><li><p><strong>Use Cryptographically Secure Hash Functions:</strong>
        Choose well-established and cryptographically secure hash functions
        designed for security, such as SHA-256 or SHA-3. These algorithms are
        rigorously tested and widely accepted in the security
        community.</p></li><li><p><strong>Keyed Hashing for Passwords:</strong>
        For password hashing, use a key derivation function (KDF) designed for
        this purpose, such as bcrypt, Argon2, or scrypt. These KDFs include
        additional parameters like salt and iteration count, enhancing the
        security of password storage.</p></li><li><p><strong>Salt the
        Hash:</strong> Always use a unique salt for each piece of sensitive data
        before hashing. Salting ensures that even identical inputs produce
        different hash outputs, preventing attackers from using precomputed
        tables (rainbow tables) for attacks.</p></li><li><p><strong>Consider
        Using Pepper:</strong> Pepper is a secret key added to the data before
        hashing, providing an additional layer of security. Unlike salt, pepper
        is kept secret and can be implemented as a configuration parameter
        separate from the hashed data.</p></li><li><p><strong>Stay Informed and
        Update:</strong> Regularly review industry best practices and updates
        related to hashing algorithms. Security evolves, and algorithms that
        were once secure may become vulnerable over time. Stay informed about
        the latest developments and be prepared to update hashing practices
        accordingly.</p></li><li><p><strong>Implement Strong Access
        Controls:</strong> Limit access to the hashed data, ensuring that only
        authorized individuals or systems can retrieve or manipulate sensitive
        information. This adds an extra layer of protection even if the hash is
        somehow exposed.</p></li><li><p><strong>Encrypt Sensitive Data Before
        Hashing (if applicable):</strong> Depending on the context, consider
        encrypting sensitive data before hashing it. Encryption adds an extra
        layer of protection, especially in scenarios where confidentiality is a
        primary concern.</p></li></ul>
      references:
        - >-
          https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/04-Testing_for_Weak_Encryption
        - >-
          https://owasp.org/www-community/vulnerabilities/Using_a_broken_or_risky_cryptographic_algorithm
      customFields: []
  category: Web Pentest

- cvssv3: 'CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N'
  priority: 1
  remediationComplexity: 1
  details:
    - locale: EN
      title: 'WSTG-INFO-09: Outdated Software'
      vulnType: Pentest
      description: >-
        <p>Used soft- and firmware as well as operating systems should always be
        kept on the most current versions.</p><p>Using outdated versions poses
        several direct and indirect security risks like:<br>- Security
        vulnerabilities: outdated software may have unpatched security holes
        that can be exploited by attackers.<br>- Compatibility issues: new
        hardware or software may not be compatible with old systems.<br>-
        Performance degradation: outdated software may run slower, become less
        responsive, or crash more often.<br>- Lack of features: newer software
        may have additional features or improvements that are not available in
        older versions.<br>- Compliance problems: outdated software may not meet
        industry regulations or standards.<br><br>Staying up to date is a
        mandatory requirement to a matured security culture and should be part
        of the patch management process.</p>
      observation: <p>Criticality based on what the outdated software allowed us to do.</p>
      remediation: >-
        <p>Check if any of the mentioned software components can be upgraded /
        updated and if important security updates are missing.<br>Implement a
        patch management strategy and process that ensures that all your systems
        are up to date and that updates are applied timely according to their
        criticality.<br>Apply workarounds when no patches are available when
        tackling critical flaws.</p>
      references: []
      customFields: []
  category: Web Pentest