Vulnerability Scan Result

Vulnerability description

We noticed that the target application lacks the Content-Security-Policy (CSP) header in its HTTP responses. The CSP header is a security measure that instructs web browsers to enforce specific security rules, effectively preventing the exploitation of Cross-Site Scripting (XSS) vulnerabilities.

Recommendation

Configure the Content-Security-Header to be sent with each HTTP response in order to apply the specific policies needed by the application.

Vulnerability description

We noticed that the target application lacks the HTTP Strict-Transport-Security header in its responses. This security header is crucial as it instructs browsers to only establish secure (HTTPS) connections with the web server and reject any HTTP connections.

Recommendation

The Strict-Transport-Security HTTP header should be sent with each HTTPS response. The syntax is as follows: `Strict-Transport-Security: max-age=<seconds>[; includeSubDomains]` The parameter `max-age` gives the time frame for requirement of HTTPS in seconds and should be chosen quite high, e.g. several months. A value below 7776000 is considered as too low by this scanner check. The flag `includeSubDomains` defines that the policy applies also for sub domains of the sender of the response.

Vulnerability description

We noticed that the target application's server responses lack the <code>X-Content-Type-Options</code> header. This header is particularly important for preventing Internet Explorer from reinterpreting the content of a web page (MIME-sniffing) and thus overriding the value of the Content-Type header.

Recommendation

We recommend setting the X-Content-Type-Options header such as `X-Content-Type-Options: nosniff`.

Vulnerability description

We noticed that server software and technology details are exposed, potentially aiding attackers in tailoring specific exploits against identified systems and versions.

Recommendation

We recommend you to eliminate the information which permits the identification of software platform, technology, server and operating system: HTTP server headers, HTML meta information, etc.

Vulnerability description

Website is accessible.

Vulnerability description

We have noticed that the server is missing the security.txt file, which is considered a good practice for web security. It provides a standardized way for security researchers and the public to report security vulnerabilities or concerns by outlining the preferred method of contact and reporting procedures.

Recommendation

We recommend you to implement the security.txt file according to the standard, in order to allow researchers or users report any security issues they find, improving the defensive mechanisms of your server.

Vulnerability description

We found that the Sender Policy Framework (SPF) record for the domain is configured with ~all (soft fail), which indicates that emails from unauthorized IP addresses are not explicitly denied. Instead, the recipient mail server is instructed to treat these messages with suspicion but may still accept them. This configuration may not provide enough protection against email spoofing and unauthorized email delivery, leaving the domain more vulnerable to impersonation attempts.

Recommendation

We recommend changing the SPF record's ~all (soft fail) directive to -all (hard fail). The -all setting tells recipient mail servers to reject emails from any IP addresses not listed in the SPF record, providing stronger protection against email spoofing. Ensure that all legitimate IP addresses and services that send emails on behalf of your domain are properly included in the SPF record before implementing this change.

Vulnerability description

We found that the target uses p=quarantine in the DMARC policy. When a DMARC policy is set to p=quarantine, emails that fail DMARC validation are delivered but placed in the recipient’s spam or junk folder. Although it offers some protection, this policy is less strict than p=reject, which blocks such emails entirely.

Recommendation

We recommend considering moving to a stricter policy, such as p=reject, where emails that fail DMARC validation are completely rejected rather than delivered to spam folders. This reduces the risk of users interacting with potentially malicious emails.

Vulnerability description

We found that the DMARC record for the domain is not configured with ruf tag. A missing ruf (forensic reporting) tag in a DMARC record indicates that the domain owner has not enabled the collection of detailed failure reports. Forensic reports provide valuable insights into specific instances where emails fail DMARC authentication. Without the ruf tag, the domain administrator loses the ability to receive and analyze these reports, making it difficult to investigate individual email failures or identify targeted phishing or spoofing attacks that may be exploiting weaknesses in the email authentication setup.

Recommendation

We recommend configuring the ruf tag in the DMARC record. This tag specifies where forensic reports should be sent, providing the domain owner with detailed data on DMARC validation failures. Forensic reports allow administrators to analyze why certain emails failed authentication, making it easier to fine-tune DMARC policies or address potential vulnerabilities. Ensure that the ruf email address belongs to a secure and trusted location capable of handling sensitive email data.

Recommendation

We recommend reviewing all DNS records associated with the domain and identifying and removing unused or obsolete records.

Vulnerability description

OS detection couldn't determine the operating system.

Vulnerability description

We noticed that server software and technology details are exposed, potentially aiding attackers in tailoring specific exploits against identified systems and versions.

Recommendation

We recommend you to eliminate the information which permits the identification of software platform, technology, server and operating system: HTTP server headers, HTML meta information, etc.

Vulnerability description

We noticed that server software and technology details are exposed, potentially aiding attackers in tailoring specific exploits against identified systems and versions.

Recommendation

We recommend you to eliminate the information which permits the identification of software platform, technology, server and operating system: HTTP server headers, HTML meta information, etc.

Vulnerability description

We noticed that server software and technology details are exposed, potentially aiding attackers in tailoring specific exploits against identified systems and versions.

Recommendation

We recommend you to eliminate the information which permits the identification of software platform, technology, server and operating system: HTTP server headers, HTML meta information, etc.

Vulnerability description

We noticed that server software and technology details are exposed, potentially aiding attackers in tailoring specific exploits against identified systems and versions.

Recommendation

We recommend you to eliminate the information which permits the identification of software platform, technology, server and operating system: HTTP server headers, HTML meta information, etc.