<?xml version="1.0" ?>
<report type="security">
   <report_infos>
      <info name="generatorName">wapiti</info>
      <info name="generatorVersion">WAPITI_VERSION</info>
      <info name="scope">folder</info>
      <info name="dateOfScan">Thu, 01 Jan 1970 00:00:00 +0000</info>
      <info name="target">http://perdu.com</info>
      <info name="crawledPages">1</info>
      <info name="auth" xsi:nil="true"/>
      <crawled_pages>
         <entry>
            <response>
               <status_code>200</status_code>
               <body><![CDATA[Hello from crawled page]]></body>
               <headers>
                  <header name="Content-Type">text/html</header>
               </headers>
            </response>
         </entry>
      </crawled_pages>
   </report_infos>
   <vulnerabilities>
      <vulnerability name="Backup file">
         <description><![CDATA[It may be possible to find backup files of scripts on the webserver that the web-admin put here to save a previous version or backup files that are automatically generated by the software editor used (like for example Emacs). These copies may reveal interesting information like source code or credentials.]]></description>
         <solution><![CDATA[The webadmin must manually delete the backup files or remove it from the web root. He should also reconfigure its editor to deactivate automatic backups.]]></solution>
         <references>
            <reference>
               <title>OWASP: Review Old Backup and Unreferenced Files for Sensitive Information</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-530: Exposure of Backup File to an Unauthorized Control Sphere</title>
               <url>https://cwe.mitre.org/data/definitions/530.html</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Cleartext Submission of Password">
         <description><![CDATA[A password was submitted to the application using an unencrypted HTTP connection. This makes the password vulnerable to eavesdropping by attackers on the network, potentially leading to account compromise or further attacks.]]></description>
         <solution><![CDATA[Ensure that all password submissions and sensitive data transmissions are performed exclusively over HTTPS (HTTP Secure). Implement HSTS (HTTP Strict Transport Security) to enforce the use of HTTPS and prevent downgrades to HTTP.]]></solution>
         <references>
            <reference>
               <title>PortSwigger: Cleartext submission of password</title>
               <url>https://portswigger.net/kb/issues/00300100_cleartext-submission-of_password</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Transport Layer Protection</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-319: Cleartext Transmission of Sensitive Information</title>
               <url>https://cwe.mitre.org/data/definitions/319.html</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Weak credentials">
         <description><![CDATA[The web application is using either default credentials or weak passwords that can be found in well-known passwords lists.]]></description>
         <solution><![CDATA[Do not ship or deploy with any default credentials, particularly for admin users. Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.]]></solution>
         <references>
            <reference>
               <title>CWE-798: Use of Hard-coded Credentials</title>
               <url>https://cwe.mitre.org/data/definitions/798.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-521: Weak Password Requirements</title>
               <url>https://cwe.mitre.org/data/definitions/521.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Testing for Weak Password Policy</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Password_Policy</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="CRLF Injection">
         <description><![CDATA[The term CRLF refers to Carriage Return (ASCII 13, \r) Line Feed (ASCII 10, \n). A CRLF Injection attack occurs when a user manages to submit a CRLF into an application. This is most commonly done by modifying an HTTP parameter or URL.]]></description>
         <solution><![CDATA[Check the submitted parameters and do not allow CRLF to be injected when it is not expected.]]></solution>
         <references>
            <reference>
               <title>OWASP: CRLF Injection</title>
               <url>https://owasp.org/www-community/vulnerabilities/CRLF_Injection</url>
               <wstg/>
            </reference>
            <reference>
               <title>Acunetix: What Are CRLF Injection Attacks</title>
               <url>https://www.acunetix.com/websitesecurity/crlf-injection/</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')</title>
               <url>https://cwe.mitre.org/data/definitions/93.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Testing for HTTP Splitting Smuggling</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/15-Testing_for_HTTP_Splitting_Smuggling</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Content Security Policy Configuration">
         <description><![CDATA[Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks.]]></description>
         <solution><![CDATA[Configuring Content Security Policy involves adding the Content-Security-Policy HTTP header to a web page and giving it values to control what resources the user agent is allowed to load for that page.]]></solution>
         <references>
            <reference>
               <title>Mozilla: Content Security Policy (CSP)</title>
               <url>https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Content Security Policy Cheat Sheet</title>
               <url>https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: How to do Content Security Policy (PDF)</title>
               <url>https://owasp.org/www-pdf-archive/2019-02-22_-_How_do_I_Content_Security_Policy_-_Print.pdf</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Content Security Policy</title>
               <url>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</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Cross Site Request Forgery">
         <description><![CDATA[Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.]]></description>
         <solution><![CDATA[Check if your framework has built-in CSRF protection and use it. If framework does not have built-in CSRF protection add CSRF tokens to all state changing requests (requests that cause actions on the site) and validate them on backend.]]></solution>
         <references>
            <reference>
               <title>OWASP: Testing for Cross Site Request Forgery</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Cross-Site Request Forgery Prevention Cheat Sheet</title>
               <url>https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-352: Cross-Site Request Forgery (CSRF)</title>
               <url>https://cwe.mitre.org/data/definitions/352.html</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Potentially dangerous file">
         <description><![CDATA[A file with potential vulnerabilities has been found on the website.]]></description>
         <solution><![CDATA[Make sure the script is up-to-date and restrict access to it if possible.]]></solution>
         <references>
            <reference>
               <title>Mitre: Search details of a CVE</title>
               <url>https://cve.mitre.org/cve/search_cve_list.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Test Network Infrastructure Configuration</title>
               <url>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</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Command execution">
         <description><![CDATA[This attack consists in executing system commands on the server. The attacker tries to inject this commands in the request parameters.]]></description>
         <solution><![CDATA[Prefer working without user input when using file system calls.]]></solution>
         <references>
            <reference>
               <title>OWASP: Command Injection</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-78: Improper Neutralization of Special Elements used in an OS Command (OS Command Injection)</title>
               <url>https://cwe.mitre.org/data/definitions/78.html</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Path Traversal">
         <description><![CDATA[This attack is known as Path or Directory Traversal. Its aim is the access to files and directories that are stored outside the web root folder. The attacker tries to explore the directories stored in the web server. The attacker uses some techniques, for instance, the manipulation of variables that reference files with 'dot-dot-slash (../)' sequences and its variations to move up to root directory to navigate through the file system.]]></description>
         <solution><![CDATA[Prefer working without user input when using file system calls. Use indexes rather than actual portions of file names when templating or using language files (eg: value 5 from the user submission = Czechoslovakian, rather than expecting the user to return 'Czechoslovakian'). Ensure the user cannot supply all parts of the path - surround it with your path code. Validate the user's input by only accepting known good - do not sanitize the data. Use chrooted jails and code access policies to restrict where the files can be obtained or saved to.]]></solution>
         <references>
            <reference>
               <title>OWASP: Path Traversal</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/01-Testing_Directory_Traversal_File_Include</url>
               <wstg/>
            </reference>
            <reference>
               <title>Acunetix: What is a Directory Traversal attack?</title>
               <url>https://www.acunetix.com/websitesecurity/directory-traversal/</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</title>
               <url>https://cwe.mitre.org/data/definitions/22.html</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Fingerprint web application framework">
         <description><![CDATA[The version of a web application framework can be identified due to the presence of its specific fingerprints.]]></description>
         <solution><![CDATA[This is only for informational purposes.]]></solution>
         <references>
            <reference>
               <title>OWASP: Fingerprint Web Application Framework</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/01-Information_Gathering/08-Fingerprint_Web_Application_Framework.html</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Fingerprint web server">
         <description><![CDATA[The version of a web server can be identified due to the presence of its specific fingerprints.]]></description>
         <solution><![CDATA[This is only for informational purposes.]]></solution>
         <references>
            <reference>
               <title>OWASP: Fingerprint Web Server</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server.html</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Htaccess Bypass">
         <description><![CDATA[Htaccess files are used to restrict access to some files or HTTP method. In some case it may be possible to bypass this restriction and access the files.]]></description>
         <solution><![CDATA[Make sure every HTTP method is forbidden if the credentials are bad.]]></solution>
         <references>
            <reference>
               <title>A common Apache .htaccess misconfiguration</title>
               <url>http://blog.teusink.net/2009/07/common-apache-htaccess-misconfiguration.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-538: Insertion of Sensitive Information into Externally-Accessible File or Directory</title>
               <url>https://cwe.mitre.org/data/definitions/538.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: HTTP Methods</title>
               <url>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</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="HTML Injection">
         <description><![CDATA[HTML injection is a type of injection vulnerability that occurs when a user is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. This vulnerability can allow the attacker to modify the page content seen by the victims.]]></description>
         <solution><![CDATA[Avoid Raw HTML Rendering: Whenever possible, avoid directly rendering user-generated content as raw HTML. Instead, use built-in templating systems or libraries that automatically escape user input by default, such as Django's template engine or AngularJS's ng-bind directive. With PHP you can use the htmlspecialchars() function to convert special characters to their corresponding HTML entities.]]></solution>
         <references>
            <reference>
               <title>OWASP: Testing for HTML Injection</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/03-Testing_for_HTML_Injection</url>
               <wstg/>
            </reference>
            <reference>
               <title>IMPERVA: HTML Injection</title>
               <url>https://www.imperva.com/learn/application-security/html-injection/</url>
               <wstg/>
            </reference>
            <reference>
               <title>HackTricks: Dangling Markup - HTML scriptless injection</title>
               <url>https://book.hacktricks.xyz/pentesting-web/dangling-markup-html-scriptless-injection</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Clickjacking Protection">
         <description><![CDATA[Clickjacking is a technique that tricks a user into clicking something different from what the user perceives, potentially revealing confidential information or taking control of their computer.]]></description>
         <solution><![CDATA[Implement X-Frame-Options or Content Security Policy (CSP) frame-ancestors directive.]]></solution>
         <references>
            <reference>
               <title>OWASP: Clickjacking</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/09-Testing_for_Clickjacking</url>
               <wstg/>
            </reference>
            <reference>
               <title>KeyCDN: Preventing Clickjacking</title>
               <url>https://www.keycdn.com/support/prevent-clickjacking</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="HTTP Strict Transport Security (HSTS)">
         <description><![CDATA[HSTS is a web security policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking.]]></description>
         <solution><![CDATA[Implement the HTTP Strict Transport Security header to enforce secure connections to the server.]]></solution>
         <references>
            <reference>
               <title>OWASP: HTTP Strict Transport Security</title>
               <url>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</url>
               <wstg/>
            </reference>
            <reference>
               <title>KeyCDN: Enabling HSTS</title>
               <url>https://www.keycdn.com/support/hsts</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="MIME Type Confusion">
         <description><![CDATA[MIME type confusion can occur when a browser interprets files as a different type than intended, which could lead to security vulnerabilities like cross-site scripting (XSS).]]></description>
         <solution><![CDATA[Implement X-Content-Type-Options to prevent MIME type sniffing.]]></solution>
         <references>
            <reference>
               <title>OWASP: MIME Sniffing</title>
               <url>https://owasp.org/www-community/attacks/MIME_sniffing</url>
               <wstg/>
            </reference>
            <reference>
               <title>KeyCDN: Preventing MIME Type Sniffing</title>
               <url>https://www.keycdn.com/support/preventing-mime-type-sniffing</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="HttpOnly Flag cookie">
         <description><![CDATA[HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it).]]></description>
         <solution><![CDATA[While creation of the cookie, make sure to set the HttpOnly Flag to True.]]></solution>
         <references>
            <reference>
               <title>OWASP: Testing for Cookies Attributes</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/06-Session_Management_Testing/02-Testing_for_Cookies_Attributes.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: HttpOnly</title>
               <url>https://owasp.org/www-community/HttpOnly</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Unencrypted Channels">
         <description><![CDATA[Sensitive data must be protected when it is transmitted through the network.]]></description>
         <solution><![CDATA[Use HTTPS for the whole web site and redirect any HTTP requests to HTTPS.]]></solution>
         <references>
            <reference>
               <title>Testing for Sensitive Information Sent via Unencrypted Channels</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/03-Testing_for_Sensitive_Information_Sent_via_Unencrypted_Channels</url>
               <wstg/>
            </reference>
            <reference>
               <title>Testing for Weak Transport Layer Security</title>
               <url>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</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Inconsistent Redirection">
         <description><![CDATA[An HTTP 3xx redirection response should typically contain only minimal content (or none), as clients are expected to follow the Location header. However, this response also contains HTML content (such as links or forms). This may confuse clients, expose unintended information, or allow attackers to craft malicious redirections.]]></description>
         <solution><![CDATA[Ensure that 3xx HTTP responses only return the appropriate redirection headers and do not include unnecessary HTML content. If user feedback is required, provide a clear message without interactive elements (like links or forms). Always rely on the Location header for redirection logic.]]></solution>
         <references>
            <reference>
               <title>ZAP Alert 10044-1: Inconsistent Redirection</title>
               <url>https://www.zaproxy.org/docs/alerts/10044-1/</url>
               <wstg/>
            </reference>
            <reference>
               <title>MDN: HTTP Redirections</title>
               <url>https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections</url>
               <wstg/>
            </reference>
            <reference>
               <title>WSTG: Review Webpage Content for Information Leakage</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Webpage_Content_for_Information_Leakage</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Information Disclosure - Full Path">
         <description><![CDATA[The application response discloses full system paths. This information can help attackers understand the server environment, directory structure, and operating system, which can facilitate further attacks.]]></description>
         <solution><![CDATA[Ensure that error messages and application responses do not disclose full filesystem paths or other sensitive system information. Use generic error messages for end users and log detailed errors only on the server side.]]></solution>
         <references>
            <reference>
               <title>OWASP: Information Leakage</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Web_Page_Content_for_Information_Leakage</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-209: Generation of Error Message Containing Sensitive Information</title>
               <url>https://cwe.mitre.org/data/definitions/209.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>WASC-13: Information Leakage</title>
               <url>http://projects.webappsec.org/w/page/13246936/Information%20Leakage</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="LDAP Injection">
         <description><![CDATA[LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries.]]></description>
         <solution><![CDATA[To protect against XPATH injection, Escape all variables using the right LDAP encoding function. Use Frameworks that Automatically Protect from LDAP Injection.]]></solution>
         <references>
            <reference>
               <title>LDAP Injection</title>
               <url>https://owasp.org/www-community/attacks/LDAP_Injection</url>
               <wstg/>
            </reference>
            <reference>
               <title>LDAP Injection Prevention Cheat Sheet</title>
               <url>https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')</title>
               <url>https://cwe.mitre.org/data/definitions/90.html</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Log4Shell">
         <description><![CDATA[Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.]]></description>
         <solution><![CDATA[From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to "true" or it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).]]></solution>
         <references>
            <reference>
               <title>NVD: CVE-2021-44228 Detail</title>
               <url>https://nvd.nist.gov/vuln/detail/CVE-2021-44228</url>
               <wstg/>
            </reference>
            <reference>
               <title>NITRE: CVE-2021-44228</title>
               <url>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Code Injection</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11-Testing_for_Code_Injection</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="NS takeover">
         <description><![CDATA[A DNS NS record points to a non existing domain that an attacker can take control of, allowing them to hijack the entire DNS zone.]]></description>
         <solution><![CDATA[Prevent dangling DNS entries by making sure you already have control over the pointed domain. Remove any NS record pointing to an external domain you don't use.]]></solution>
         <references>
            <reference>
               <title>Subdomain Takeover: Going beyond CNAME</title>
               <url>https://0xpatrik.com/subdomain-takeover-ns/</url>
               <wstg/>
            </reference>
            <reference>
               <title>A Guide to DNS Takeovers: The Misunderstood Cousin of Subdomain Takeovers</title>
               <url>https://projectdiscovery.io/blog/guide-to-dns-takeovers</url>
               <wstg/>
            </reference>
            <reference>
               <title>MasterCard DNS Error Went Unnoticed for Years</title>
               <url>https://krebsonsecurity.com/2025/01/mastercard-dns-error-went-unnoticed-for-years/</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Open Redirect">
         <description><![CDATA[Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.]]></description>
         <solution><![CDATA[Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.]]></solution>
         <references>
            <reference>
               <title>Unvalidated Redirects and Forwards Cheat Sheet</title>
               <url>https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>Acunetix: What Are Open Redirects?</title>
               <url>https://www.acunetix.com/blog/web-security-zone/what-are-open-redirects/</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</title>
               <url>https://cwe.mitre.org/data/definitions/601.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Client-side URL Redirect</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/04-Testing_for_Client-side_URL_Redirect</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Reflected Cross Site Scripting">
         <description><![CDATA[Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users. Examples of such code include HTML code and client-side scripts.]]></description>
         <solution><![CDATA[The best way to protect a web application from XSS attacks is ensure that the application performs validation of all headers, cookies, query strings, form fields, and hidden fields. Encoding user supplied output in the server side can also defeat XSS vulnerabilities by preventing inserted scripts from being transmitted to users in an executable form. Applications can gain significant protection from javascript based attacks by converting the following characters in all generated output to the appropriate HTML entity encoding: <, >, &, ', (, ), #, %, ; , +, -]]></solution>
         <references>
            <reference>
               <title>OWASP: Cross Site Scripting (XSS)</title>
               <url>https://owasp.org/www-community/attacks/xss/</url>
               <wstg/>
            </reference>
            <reference>
               <title>Wikipedia: Cross-site scripting</title>
               <url>https://en.wikipedia.org/wiki/Cross-site_scripting</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</title>
               <url>https://cwe.mitre.org/data/definitions/79.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Reflected Cross Site Scripting</title>
               <url>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</url>
               <wstg/>
            </reference>
         </references>
         <entries>
            <entry>
               <method>GET</method>
               <path>/riri</path>
               <level>1</level>
               <parameter>foo</parameter>
               <info>This is dope</info>
               <referer></referer>
               <module>xss</module>
               <http_request><![CDATA[GET /riri?foo=bar HTTP/1.1]]></http_request>
               <curl_command><![CDATA[curl "http://perdu.com/riri?foo=bar"]]></curl_command>
               <wstg/>
               <detail>
                  <response>
                     <status_code>200</status_code>
                     <body><![CDATA[<html><body>riri</body></html>]]></body>
                     <headers>
                        <header name="content-type">text/html</header>
                        <header name="content-length">30</header>
                     </headers>
                  </response>
               </detail>
            </entry>
         </entries>
      </vulnerability>
      <vulnerability name="Secure Flag cookie">
         <description><![CDATA[The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text.]]></description>
         <solution><![CDATA[When generating the cookie, make sure to set the Secure Flag to True.]]></solution>
         <references>
            <reference>
               <title>OWASP: Testing for Cookies Attributes</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/06-Session_Management_Testing/02-Testing_for_Cookies_Attributes.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Secure Cookie Attribute</title>
               <url>https://owasp.org/www-community/controls/SecureCookieAttribute</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Spring4Shell">
         <description><![CDATA[A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment.If the application is deployed as a Spring Boot executable jar, i.e. the default,it is not vulnerable to the exploit. However, the nature of the vulnerability is more general,and there may be other ways to exploit it.]]></description>
         <solution><![CDATA[Users of affected versions should apply the following mitigation: 5.3.x users should upgrade to 5.3.18+,5.2.x users should upgrade to 5.2.20+. No other steps are necessary.There are other mitigation steps for applications that cannot upgrade to the above versions.]]></solution>
         <references>
            <reference>
               <title>CYBERWATCH: Spring4Shell CVE-2022-22965</title>
               <url>https://cyberwatch.fr/cve/spring4shell-tout-savoir-sur-la-vulnerabilite-0-day-liee-a-java-spring/</url>
               <wstg/>
            </reference>
            <reference>
               <title>VMWARE: CVE-2022-22965 Detail</title>
               <url>https://tanzu.vmware.com/security/cve-2022-22965</url>
               <wstg/>
            </reference>
            <reference>
               <title>MITRE: CVE-2022-22965</title>
               <url>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Code Injection</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11-Testing_for_Code_Injection</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="SQL Injection">
         <description><![CDATA[SQL injection vulnerabilities allow an attacker to alter the queries executed on the backend database. An attacker may then be able to extract or modify information stored in the database or even escalate his privileges on the system. Blind SQL injection is a technique that exploits a vulnerability occurring in the database of an application. This kind of vulnerability is harder to detect than basic SQL injections because no error message will be displayed on the webpage.]]></description>
         <solution><![CDATA[To protect against SQL injection, user input must not directly be embedded in SQL statements. Instead, user input must be escaped or filtered or parameterized statements must be used.]]></solution>
         <references>
            <reference>
               <title>OWASP: SQL Injection</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection</url>
               <wstg/>
            </reference>
            <reference>
               <title>Wikipedia: SQL injection</title>
               <url>https://en.wikipedia.org/wiki/SQL_injection</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</title>
               <url>https://cwe.mitre.org/data/definitions/89.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Blind SQL Injection</title>
               <url>https://owasp.org/www-community/attacks/Blind_SQL_Injection</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="TLS/SSL misconfigurations">
         <description><![CDATA[The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications. Over the years numerous vulnerabilities have been discovered in some SSL/TLS version or specific ciphers making the integrity of the communications at risk (eavesdropping, alteration...)]]></description>
         <solution><![CDATA[To protect against SSL/TLS vulnerabilities, make sure that deprecated versions of the protocol are disabled. Refer to up-to-date recommendations to only allow modern versions of TLS with Perfect Forward Secrecy.]]></solution>
         <references>
            <reference>
               <title>SSL Labs: SSL and TLS Deployment Best Practices</title>
               <url>https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices</url>
               <wstg/>
            </reference>
            <reference>
               <title>Mozilla: Server Side TLS recommended configurations</title>
               <url>https://wiki.mozilla.org/Security/Server_Side_TLS</url>
               <wstg/>
            </reference>
            <reference>
               <title>Beagle Security: Importance of TLS 1.3, SSL and TLS Vulnerabilities</title>
               <url>https://beaglesecurity.com/blog/article/importance-of-tls-1-3-ssl-and-tls-vulnerabilities.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>Security of TLS cipher suites</title>
               <url>https://ciphersuite.info/</url>
               <wstg/>
            </reference>
            <reference>
               <title>Trail of Bits: What Application Developers Need To Know About TLS Early Data (0RTT)</title>
               <url>https://blog.trailofbits.com/2019/03/25/what-application-developers-need-to-know-about-tls-early-data-0rtt/</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Weak SSL TLS Ciphers Insufficient Transport Layer Protection</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_SSL_TLS_Ciphers_Insufficient_Transport_Layer_Protection</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Server Side Request Forgery">
         <description><![CDATA[The target application may have functionality for importing data from a URL, publishing data to a URL or otherwise reading data from a URL that can be tampered with.]]></description>
         <solution><![CDATA[Every URI received by the web application should be checked, especially scheme and hostname. A whitelist should be used.]]></solution>
         <references>
            <reference>
               <title>OWASP: Server Side Request Forgery</title>
               <url>https://owasp.org/www-community/attacks/Server_Side_Request_Forgery</url>
               <wstg/>
            </reference>
            <reference>
               <title>Acunetix: What is Server Side Request Forgery (SSRF)?</title>
               <url>https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/</url>
               <wstg/>
            </reference>
            <reference>
               <title>What is the Server Side Request Forgery Vulnerability &amp; How to Prevent It?</title>
               <url>https://www.netsparker.com/blog/web-security/server-side-request-forgery-vulnerability-ssrf/</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-918: Server-Side Request Forgery (SSRF)</title>
               <url>https://cwe.mitre.org/data/definitions/918.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Server-Side Request Forgery</title>
               <url>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</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Stored HTML Injection">
         <description><![CDATA[HTML injection is a type of injection vulnerability that occurs when a user is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. This vulnerability can allow the attacker to modify the page content seen by the victims.]]></description>
         <solution><![CDATA[Avoid Raw HTML Rendering: Whenever possible, avoid directly rendering user-generated content as raw HTML. Instead, use built-in templating systems or libraries that automatically escape user input by default, such as Django's template engine or AngularJS's ng-bind directive. With PHP you can use the htmlspecialchars() function to convert special characters to their corresponding HTML entities.]]></solution>
         <references>
            <reference>
               <title>OWASP: Testing for HTML Injection</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/03-Testing_for_HTML_Injection</url>
               <wstg/>
            </reference>
            <reference>
               <title>IMPERVA: HTML Injection</title>
               <url>https://www.imperva.com/learn/application-security/html-injection/</url>
               <wstg/>
            </reference>
            <reference>
               <title>HackTricks: Dangling Markup - HTML scriptless injection</title>
               <url>https://book.hacktricks.xyz/pentesting-web/dangling-markup-html-scriptless-injection</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Stored Cross Site Scripting">
         <description><![CDATA[Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users. Examples of such code include HTML code and client-side scripts.]]></description>
         <solution><![CDATA[The best way to protect a web application from XSS attacks is ensure that the application performs validation of all headers, cookies, query strings, form fields, and hidden fields. Encoding user supplied output in the server side can also defeat XSS vulnerabilities by preventing inserted scripts from being transmitted to users in an executable form. Applications can gain significant protection from javascript based attacks by converting the following characters in all generated output to the appropriate HTML entity encoding: <, >, &, ', (, ), #, %, ; , +, -]]></solution>
         <references>
            <reference>
               <title>OWASP: Cross Site Scripting (XSS)</title>
               <url>https://owasp.org/www-community/attacks/xss/</url>
               <wstg/>
            </reference>
            <reference>
               <title>Wikipedia: Cross-site scripting</title>
               <url>https://en.wikipedia.org/wiki/Cross-site_scripting</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</title>
               <url>https://cwe.mitre.org/data/definitions/79.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Stored Cross Site Scripting</title>
               <url>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</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Subdomain takeover">
         <description><![CDATA[A DNS CNAME record points to a non existing domain or to a content that an attacker can take control of.]]></description>
         <solution><![CDATA[Prevent dangling DNS entries by making sure you already have control over the pointed domain.]]></solution>
         <references>
            <reference>
               <title>Microsoft: Prevent dangling DNS entries and avoid subdomain takeover</title>
               <url>https://docs.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover</url>
               <wstg/>
            </reference>
            <reference>
               <title>Can I take over XYZ? — a list of services and how to claim (sub)domains with dangling DNS records.</title>
               <url>https://github.com/EdOverflow/can-i-take-over-xyz</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Subdomain Takeover</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/10-Test_for_Subdomain_Takeover</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Blind SQL Injection">
         <description><![CDATA[Blind SQL injection is a technique that exploits a vulnerability occurring in the database of an application. This kind of vulnerability is harder to detect than basic SQL injections because no error message will be displayed on the webpage.]]></description>
         <solution><![CDATA[To protect against SQL injection, user input must not directly be embedded in SQL statements. Instead, user input must be escaped or filtered or parameterized statements must be used.]]></solution>
         <references>
            <reference>
               <title>OWASP: Blind SQL Injection</title>
               <url>https://owasp.org/www-community/attacks/Blind_SQL_Injection</url>
               <wstg/>
            </reference>
            <reference>
               <title>Wikipedia: SQL injection</title>
               <url>https://en.wikipedia.org/wiki/SQL_injection</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</title>
               <url>https://cwe.mitre.org/data/definitions/89.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: SQL Injection</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Unrestricted File Upload">
         <description><![CDATA[File upload vulnerabilities are when a web server allows users to upload files to its filesystem without sufficiently validating things like their name, type, contents, or size. Failing to properly enforce restrictions on these could allow an attacker to upload potentially dangerous files. This could even include server-side script files that enable remote code execution.]]></description>
         <solution><![CDATA[Check the file extension against a whitelist of permitted extensions rather than a blacklist of prohibited ones. Make sure the filename doesn't contain any substrings that may be interpreted as a directory or a traversal sequence (../). Rename uploaded files to avoid collisions that may cause existing files to be overwritten. Do not upload files to the server's permanent filesystem until they have been fully validated.]]></solution>
         <references>
            <reference>
               <title>HackTricks: File Upload</title>
               <url>https://book.hacktricks.xyz/pentesting-web/file-upload</url>
               <wstg/>
            </reference>
            <reference>
               <title>PortSwigger : File upload vulnerabilities</title>
               <url>https://portswigger.net/web-security/file-upload</url>
               <wstg/>
            </reference>
            <reference>
               <title>CWE-434: Unrestricted Upload of File with Dangerous Type</title>
               <url>https://cwe.mitre.org/data/definitions/434.html</url>
               <wstg/>
            </reference>
            <reference>
               <title>OWASP: Test Upload of Unexpected File Types</title>
               <url>https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/08-Test_Upload_of_Unexpected_File_Types</url>
               <wstg/>
            </reference>
         </references>
         <entries/>
      </vulnerability>
      <vulnerability name="Vulnerable software">
         <description><![CDATA[The detected software in its installed version is known to be vulnerable to one or more vulnerabilities.]]></description>
         <solution><![CDATA[Update the software to its latest version or applied security patches.]]></solution>
         <references/>
         <entries/>
      </vulnerability>
   </vulnerabilities>
   <anomalies/>
   <additionals/>
</report>
