FAQ

Configuration

Outdated CMS Version

The use of an outdated version of a content management system (CMS) can lead to various security issues. A list of known security vulnerabilities sorted by version number can be found in the publicly accessible CVE Details database¹. In many cases the only countermeasure is to update to the latest version.

Solution

The best protection against security vulnerabilities due to outdated versions are regular updates. Always use the current version and check periodically for new updates. This also applies for plugins, themes and other third party products used in combination with your CMS.

Vulnerable CMS Version

Your Content Management System (CMS) has known security vulnerabilities which can be found in the publicly accessible CVE Details database¹. Depending on the severity of the vulnerability this may cause security incidents like confidential information disclosure, bypassing access control mechanisms,attacks against users as well as a take-over of your systems by an attacker.

Solution

Stay informed about known vulnerabilities of your CMS and follow instructions of the vendor to fix security issues. Furthermore, always use the latest version and check periodically for new updates. This also applies for plugins, themes and other third party products used in combination with your CMS.

Downloadable Source Code

Source code on your web site can be accessed and downloaded. While this is not considered as a security vulnerability per se, this may provide valuable information to an attacker for a successful attack, such as programming language specific security holes, version numbers located in the source code, programming errors and bugs that lead to possible attacks, etc.

Solution

Make sure your source code is securely stored and it can not be accessed by unauthorized persons.

Reputation

Hatred or Violence

Browser plug-ins like WOT [1] allow to evaluate a website by the user, e.g.regarding questionable contents like hate speech, racism or discrimination. Your website has received poor ratings in this category. The result is that the plug-in warns users about a possible danger when visiting your website. This can lead to a damage of your reputation.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

Misleading

Browser plug-ins like WOT [1] allow to evaluate a website by the user, e.g. point out misleading, incorrect or unethical content or unproven product claims. Your website has received poor ratings in this category. The result is that the plug-in warns users about a possible danger when visiting your website. This can lead to a damage of your reputation.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

Adware

Browser plug-ins like WOT [1] allow to evaluate a website by the user, e.g.regarding unwanted advertisements like highly annoying ads and pop-ups. Your website has received poor ratings in this category. The result is that the plug-in warns users about a possible danger when visiting your website. This can lead to a damage of your reputation.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

Experience

Browser plug-ins like WOT [1] allow to evaluate a website by the user, e.g. user experience regarding unacceptable user experience, low quality products or unreliable deliveries. Your website has received poor ratings in this category. The result is that the plug-in warns users about a possible danger when visiting your website. This can lead to a damage of your reputation.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

Scam

Your website has been blacklisted as it has been identified as fraud. This might indicate that your website has been hacked and third parties may have access to your system. This means that your website may harm users by phishing attacks and scam which can have a negative impact on your reputation.

Solution

Carry out an anti virus scan immediately and contact your web hosting provider to inform him about you being hacked. Furthermore, please check the following information that may help you to resolve this issue [1]. If you suffer from hacking attacks frequently or if the problem persists even after the recovery we strongly recommend to consult an IT security expert to help you.

Illegal

Your website has been blacklisted as it has been identified to hosting malicious or illegal content. This might indicate that your website has been hacked and third parties may have access to your system. In Addition to a severe damage of your reputation, hosting illegal and malicious content may have legal consequences for you.

Solution

Carry out an anti virus scan immediately and contact your web hosting provider to inform him about you being hacked. Furthermore, please check the following information that may help you to resolve this issue [1]. If you suffer from hacking attacks frequently or if the problem persists even after the recovery we strongly recommend to consult an IT security expert to help you.

Potentially Unwanted Application (PUA)

Browser plug-ins like WOT [1] allow to evaluate a website by the user, e.g. if the site installs or is involved in the distribution of potentially unwanted programs or applications (PUA) like toolbars without notifying the user. Your website has received poor ratings in this category. The result is that the plug-in warns users about a possible danger when visiting your website. This can lead to a damage of your reputation.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

SPAM

Your website has been blacklisted as it has been identified to send spam. This might indicate that your website has been hacked and third parties may have access to your system. Furthermore, this can refer to insecure configuration of a mail server which is used as an open relay. Another reason for blacklisting can be poor user evaluation via browser plugins such as the WOT Add-on [1] which allows users to tag websites if they are used to sending spam or if they are referred to in spam mails.

The consequence is, additionally to a great loss of reputation, impairment of the e-mail traffic on the system as mails are marked as spam mails.

Solution

Try to figure out the reason why your website has been blacklisted. Check if your system can be used as an open relay and secure your system’s configuration [2]. Moreover, it is recommended to carry out an anti virus scan and to contact your web hosting provider to inform him about your problem. If the problem was due to malicious software, please check the following information that may help you to resolve this issue [3].

If you managed to solve the underlying problem follow the blacklist removal process of the specific blacklist provider.

If you suffer from being blacklisted frequently or if the problem persists even after fixing your configuration issues we strongly recommend to consult an IT security expert to help you.

Malware

Your website has been blacklisted as it has been identified to hosting malicious software. This might indicate that your website has been hacked and third parties may have access to your system. This means that your website may harm users which can have a negative impact on your reputation.

Solution

Carry out an anti virus scan immediately and contact your web hosting provider to inform him about you being hacked. Furthermore, please check the following information that may help you to resolve this issue [1]. If you suffer from hacking attacks frequently or if the problem persists even after the recovery we strongly recommend to consult an IT security expert to help you.

Reputation

Browser plug-ins like WOT [1] allow to evaluate a website by the user regarding several categories. Your website has received general poor ratings by them indicating a bad reputation. The result is that the plug-in warns users about a possible danger when visiting your website.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

The domain of an outgoing link found on your website is on a blacklist. There are two possible causes. Either your website has been hacked, and someone placed malicious links on your website, or the legit website you are linking to has been hacked and was indentified by a blacklist. Both can cause an immediate reputation loss, because search engines use outgoing links in their ranking calculation.

Solution

Review the links. If they lead to legit websites, inform the owner of that website about the blacklist listing. If they lead to unknown/malicious websites delete them and take further actions to resecure your website. Please check the following information that may help you to resolve this issue [1]. If you suffer from hacking attacks frequently or if the problem persists even after the recovery we strongly recommend to consult an IT security expert to help you.

Phishing

Your website has been blacklisted as it has been identified as phishing site. This might indicate that your website has been hacked and third parties may have access to your system. Your website may be misused, by masquerading as a trustworthy entity to obtain sensitive information from your users.

Solution

Please check the following information that may help you to resolve this issue [1]. If you suffer from hacking attacks frequently or if the problem persists even after the recovery we strongly recommend to consult an IT security expert to help you.

 

Transport Layer Security (TLS)

Certificate

Legacy Certificates

By legacy we mean distrusted certificates. An example from the past is the distrust of the Symantec PKI [1]. The best solution to date is, to replace the existing distrusted certificate with a new one from any Certificate Authority trusted by Google, Mozilla, Apple and Microsoft (and probably other browser vendors).

Misconfigured Chain

A correctly configured webserver should provide clients with the whole certificate chain up to the root certificate. If the server delivers a misconfigured certificate chain (e.g. incomplete or wrongly sorted) most browsers recover by verifying the certificate via AIA. [1]

This process, however, slows down page loading and browsers that do not support AIA may show the user a security warning.

Revoked Certificate

A Certificate may be revoked for various reasons (e.g. (possible) loss of the private key, domain closed, etc...). This means that the certificate is not valid anymore and users are shown a warning page in most browsers.

Protocol

TLS (Transport Layer Security) or SSL (Secure Socket Layer) is a protocol used to securely transmit encrypted data. Since SSL v3 the protocol is known as TLS, where TLS 1.0 corresponds to SSL v3.1. The currently recommended versions are TLS 1.2 and TLS 1.3. All the other versions are considered weak or contain vulnerabilities.

SSL v3/SSL v3.1/TLS 1.0

Those versions have also considerable security vulnerabilities. A well known attack is the Chained Initialization Vector CBC Mode MiTM Weakness (BEAST) attack. The attack is based on the usage of the CBC mode for encrypting the block ciphers and enables Man-in-The-Middle attacks which can be used to obtain plaintext HTTP header data. [1] Additionally, the key derivation function for the master key depends on a MD5 hash function. The possibility of collision based attacks let the protocol be considered as insecure in general. In October 2014 the POODLE attack has been published. This attack targets all implementations of SSL v3/TLS 1.0 which leads to the point that this protocol is not recommended to use any more. Using a Man-in-The-Middle attack, encrypted data can be decrypted and an attacker can gain access to plain text data. [2]

TLS 1.1 deprecation

The Internet Engineering Task Force (IETF) no longer recommends the use of TLS versions older than TLS 1.2. According to the following draft document (https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/) TLS 1.0 and TLS 1.1 are deprecated. Negotiation of TLS 1.0 or 1.1 from any version of TLS MUST NOT be permitted. All major browser vendors are deprecating support for these versions of TLS by March 2020.

Ciphers

DES

The recommended key length for TLS is at least 128 bits. [1] Keys with a shorter length could be broken and would allow the decryption of communications. The Data Encryption Standard (DES) is using only 56 bits. Therefore, DES based cipher suites should not be used.

3DES

3DES or Triple-DES is a cryptographic block cipher algorithm which uses 64-bit blocks for data encryption between a client and server. Mostly used for establishing HTTPS connections, this cipher is known to be weak due to his short block size (in comparison, AES uses 128-bit blocks). With the emergence of the Sweet32 attack, there is a documented way of exploiting this trait. [1] The security measures of 3DES start to crumble whenever the birthday bound is reached. The point, at which a collision between the encrypted blocks is expected. Under certain circumstances, the attacker can then retrieve sensible data like session cookies.

Export

Export Cipher Suites are weak by design. They are encrypted but only with weak key material. This leads to the fact that the encryption can be broken very easily as there are used 40 bit or 56 bit algorithms.

IDEA

IDEA uses 64-bit blocks for encryption which is considered as weak. Per RFC5469 this cipher is deprecated. It has been completely removed in TLS 1.2.

LOW

LOW are low strength encryption cipher suites, using 64 or 56 bit encryption algorithms but excluding export cipher suites. As of OpenSSL 1.0.2g, this is disabled in default builds. Src: OpenSSL

Null

Using Null ciphers mean that no encryption for the data is used at all. They do not offer any privacy or security for the user of a web service. For this reason it is urgently recommended not to use Null ciphers.

RC2

It is advised not to use RC2 for encryption as it has an insufficient key size and is therefore seen as untrustworthy.

RC4

It has been known that RC4 has a weakness in its encryption and should therefore be avoided. On the other hand, there is no secure alternative as many clients still require RC4 support. However, since March 2013, RC4 is demonstrably broken and is classified as insecure in combination with TLS (Transport Layer Security). [1] The attack demonstrates that parts of the plain text can be recovered. For this reason, it is recommended that the support for this cipher should be removed in the near future.

SEED

SEED is an older South Korean cipher. OWASP recommends to not use this (and other older) cipher anymore.

Hash Functions

MD5

The use of the MD5 hash algorithm should be avoided in general as this algorithm is prone for collision attacks. [1]

SHA1

Known for its cryptographic and mathematical weaknesses, the SHA-1 hash algorithm was already replaced by the SHA-2 ciphers family as the recommended standard in 2002. As of begin of 2017, popular browser vendors like Microsoft, Mozilla or Google will stop accepting SHA-1 signed TLS certificates. Instead, the browsers will start displaying a warning sign if any certificate in the trust chain uses the outdated algorithm. Therefore, the upgrade of the web server's and of all intermediate certificates to the SHA-2 family should be considered as soon as possible.

Key Exchange Algorithms

Anonymous Diffie-Hellmann

Anonymous Diffie-Hellman Cipher Suites are used for anonymous Diffie-Hellman communications in which neither party is authenticated. Therefore this mode is vulnerable to Man-in-The-Middle attacks. [1]

 

Verifying PDF Integrity

The Cyber Risk Rating Portal issues multiple documents at the end of the rating process for every supplier. The documents are among others the Cyber Risk Rating Certificate which contains the overall rating scores for the supplier along with the WebRisk score and the Cyber Risk Rating Assessment Report that lists the answers of the supplier along with the validation results.

To ensure the integrity of the documents and prevent potential compromises by others during the download process, a signature file for each document is added that contains the signed digest per document. By signing the digest, the document integrity is guaranteed as changing the document's content would consequently create a different digest, failing to match the provided signature. Additionally, the signature cannot be altered given that it was signed using our own secret RSA private key. The algorithms used for the process are SHA256 to create digest of the document and RSA PKCS#1 v1.5 for the signing.

Verifying the integrity on the command line

It is advised to verify the integrity of each document after downloading them as a zipped archive. For each document, the corresponding signature file .sig represents the signed digest in byte form. Furthermore, the public key that was used on our side is required. It can be downloaded here: Cyber Risk Rating Signature Public Key.

The verification can be done using OpenSSL v1.1.1f or above.

$ openssl dgst -sha256 -verify crr-signature-key.pub -signature Cyber-Risk-Rating-Report-Valid.pdf.sha256.sig Cyber-Risk-Rating-Report-Valid.pdf
Verified OK

If the documents are compromised, the verification will fail. In this case, contact `support@nimbusec.com` immediately for further help.

$ openssl dgst -sha256 -verify crr-signature-key.pub -signature Cyber-Risk-Rating-Report-Valid.pdf.sha256.sig Cyber-Risk-Rating-Report-Compromised.pdf
Verification Failure

CyberRisk Rating Signature Public Key

You can download the signature key as file here: Cyber Risk Rating Signature Public Key,

or use the plain text version printed below:

-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwGd+TC2FkOrz/CqU9lUk
xNi8uhQ73D9YVlQ93Jkl4plVRYcquGOK0hLqWSTDkHAfd9fKCqgmJWF1X6eF/fz7
B6a7HeCHAPlut3aclEneJef03JWsLZWoMD724v7vDXHolUcDNHuICWQpWMpZ/xaM
E1FzNlzqSH41tF3YPOaxGiQA39+POxaWItYk7hBKBWhU6F4PBzZfM2gE/3AOqcRi
4DRFYPh3ZwIVTGqDtfiYMWUYLDI5u0KzdFne6qvBHflBwB1Nd9l3ckEFiv91s2Sg
3AaiXEqgSvLIL02tbmVnbfImVXksE9VeNWpr0LKWnTApheX++DQ0itB7zbg9JIfv
rEG9JNuP/dXlFjYRsBlsaz950vulzwwWjeHs6LikqHUz+4xy8+GU6vs0QFbvkHlD
DRcJGeCWsCiijh9dtM+yDcZfr8WjEr9AQfskMSfoWuVqAMBqJ05C51fDnZdbNLGy
0ubtIoI4cSIf7Rrow1iq8l4WsPoIZDRq2S0jJc3gLnAS6erlQoox/9A2ZWeCQPw9
iHixIVpQR/h6TKT6M4VQn+Ilw+Nj5o6yTzYEhq5nY64yH9zn0brhycANLhO/PnA1
rYaCorVRMFbr9UeysulqKBEk4TkEAWdUXdqSzM/Wdm2P0pQM7Y0vhMbqMSeYoGkX
o2lNrkxDioheGnwTsaFejtMCAwEAAQ==
-----END PUBLIC KEY-----

 

Compliance Monitoring Issues

General Information

In the world of website compliance, a lot of differnt compliance violotions can occour. Therefore we decided to make a clear separation of those violations and introduced different violation categories:

Each category includes different types of violations that will be described in the corresponding section. The main differences are that regulatory violatens based on GDPR context prescribed by law and business violations based on custom rules that can be individually defined to meet each customers individual requiremnts.

Regulatory Violations

This category includes all detected problems that relates to the acutal GDPR context prescribed by law. The following types can be detected by the Nimbusec compliance monitor in the context of regulatory violations:

Generally, the Nimbusec Complaince Scan simulates a standard website user that visits a website, but does not perform any kind of interaction with it (e.g. allowing cookies, ...). For this vioaltion type, we collect all cookie information that was set from the website (before any kind of user interaction). This results in a clear list of cookies that were initially set/provided by the website. In the default configuration, if our simulated website user gets any kind cookies, a 'Cookie Opt-In' violation will be triggerd and shown in the compliance monitor. With other words, cookies have been set without asking for consent in the cookie banner.

In the Nimbusec Compliance Monitor, this violation type can be seen in the compliance view of an asset:

image-1627892571901.png

By clicking on the "Details" button, all detected cookies can be seen.

image-1627892598969.png

In more detail, the Nimbusec compliance scan saves the following data:

example data:

Name Domain Secure HttpOnly LifeTime SameSite ThirdParty InServerResponse
cookie_name www.example.com false false -1 N/A true false

column description:

Column Description
Name Name of the detected Cookie
Domain Domain name where the described cookie was found
Secure The Secure flag is an option that can be set by the server when sending a new cookie to the user in an HTTP response. The purpose is to prevent cookies from being observed by unauthorized parties due to sending the cookie in clear text.
HttpOnly The HttpOnly flag is an additional security option for cookies. If this flag is set, the browser does not display the cookie through client-side scripts.
LifeTime This parameter shows the validity of a cookie.
SameSite The SameSite attribute shows if this cookie is restricted to a first-party or same-site context.
ThirdParty This attribute shows if this cookie was distributed from the own web ressource or from an external one. (domain name matching)
InServerResponse If the value of this attribute is true, this cookie was directly send from the server. If this value is false, the cookie was created and distributed via a JavaScript context.

The Nimbusec Compliance Scan checks websites for the presence of a standard cookie banner. For this case, we check for a default set of various cookie banner implementations. If a custom cookie banner is used, the scan configuration has to be adjusted to detect non default cookie banners.

Form: HTTP-Transmit

For this case, our scan checks all availabe input forms that handles sensitive data. If the content of the input form will be send unencrypted (via HTTP), the Nimbusec Compliance Scan throws a Form: HTTP-Transmit violation. Unencrypted data transmission may be intercepted and the data could be seen in plain text.

By clicking on the "Details" button in the compliance view, all detected cookies can be seen.

image-1627892770440.png

image-1627893146393.png

Form: Form-Sensitive

As mentioned above, the Nimbusec Complaince Scan checks all availabe input forms that handles sensitive data. If we detect such forms, a Form-Sensitive event will be triggered. This should help the users to identify those forms and may handle them in a different way.

image-1627893184908.png

Form: External-Transmit

This type of violation gets triggerd if form data will be send to an external processor (e.g. to an external company that may performs user analytics tasks)

image-1627893221406.png

Imprint Policy

The presence of an imprint is a mandaroty regulation in GDPR. Our imprint policy checks the presence of an imprint link on the corresponding website. To detect it, we use predefined search patterns and apply them on the websites source code.

By clicking on the "Details" button in the compliance view, all defined polices can be seen.

image-1627893270031.png

image-1627893285499.png

Privacy Policy

The presence of a privacy statement is a mandaroty regulation in GDPR. Our privacy policy checks the presence of a privacy statement link on the corresponding website. To detect it, we use predefined search patterns and apply them on the websites source code.

image-1627893315987.png

Tracker

From our point of view, a tracker is any kind of software that collects or transmits data to an external ressource. Therefore, our Nimbusec Compliance Scan analyses the whole network traffic that is active during our simulated website user visits the site. From the GDPR point of view, before the user accepts the defined privacy policy, any kind of data collection or data transmission to third party systems is a violation against the given law.

Business Violations

This category represents the adjustable part of the Nimbusec Compliance Monitor. For each issue type a customized ruleset can be defined to identify violations against corporate guidelines. These adjustments (ruleset definition) will be realized by the Nimbusec Serivce Team according to the customers needs.

The following types can be detected by the Nimbusec compliance monitor in the context of business violations:

Cookies

For this type, a list of allowed cookie names can be defined (Cookie Whitelisting). If a detected cookies matches an entriy of the predefined list, it does not ceate an issue and will be acknowledged automatically.

This setup is very useful to close already known cookies and keep the focus on cookie violations.

Here is an example: Assume three cookies were found

As a result, Cookie issues for CookieB and CookieC will be acknowledged automatically and only the Cookie issue for CookieA will remain.

In the Nimbusec Compliance Monitor, this violation type can be seen in the compliance view of an asset:

image-1627893394755.png

By clicking on the "Details" button, all detected cookie information can be seen.

image-1627893409813.png

The first table (COOKIE OPT-IN VIOLATION) shows all cookies of the domain that were detected during the complaince scan. The second table (COOKIE POLICY VIOLATION) contains all cookies that were not defined in the cookie Whitelist. All those cookies should be checked if they are really needed. If yes, move them behind the cookie banner and define them in the cookie policy. If not, remove them from the web application.

Additionally, we have a default Cookie Whitelist in place for all of our customers. This default list includes common technical neccesary cookie names that do not represent a violation in the GDPR context (not all technical necessary cookie names included).

Forms (TBD)

Trackers (TBD)

Policies

This type generally handles all content related checks. The customer has the possibility to define company related rules for all/parts of their own requirements.

For example, the management wants to see a specific privacy policy and imprint combination on all of their company websites. Those requirements will be converted in a customized rulset by the Nimbusec Service Team.

More examples:

By clicking on the "Details" button in the compliance view, all defined polices can be seen.

image-1627893594105.png

POLICY CONFIGURATION detail view (example):

image-1627893609819.png

 

Security Header Ratings

Explanation

Security Header Ratings allow an objective assessment about the website's condition in terms of the security of the HTTP response headers. By adding and configuring security headers according to best practices, another layer of security will strengthen a website's protection. In Nimbusec Discovery, a new column within the report overview - consisting of grade A-F - evaluates the scanned security headers of a website.

The implementation is based on Mozilla Observatory. The detailed scoring is described in their Github repo: Scoring.md. That means we stick to Mozillas rating and scoring method.

Important update

Right now, Mozilla appears to be not that keen about keeping the project up-to-date with the current Security Header landscape. Meanwhile, several vendor have introduced new headers, altered the meaning of existing ones and even deprecated the use of some older headers which makes their consideration, evaluation and assessment of them in the Observatory project kinda obsolete. To adhere to the changes and hold our standards to the highest level, some important changes that can be seen below, were made.

Latest Changes

X-XSS Protection

Action

Removed from domain check

Reasoning

X-XSS Protection allows the user to activate the internal XSS Auditor / Filter which on behalf of the user conducts XSS checks for the given webcontent that served or presented. Back in the good old days of Internet Explorer this check was considered important to add another protection to the user. Nowadays, most major browser vendors (Chrome, Edge, Safari) have either retired or deprecated their XSS Auditors / Filters. Firefox, ironically, have never ever implemented such a check in the first place 1. The prevailing opinion is that this header has been completely replace by the superior Content Security Policy 2. Even OWASP does not recommend activating or enabling this header and advices turning it off 3. Currently, we do not grant any bonus points for having this header but rather penalize wrong or non - existant implementations. Given the current state, of major browser vendors, this header does not pose any usefulness any longer.

Sources

HPKP = HTTP Public Key Pinning

Action

Removed from domain check

Reasoning

HPKP is an absolete header which is no longer supported by any web standards 1. It's original use was to pinpoint the public key of a website as a header when server via HTTPS. The reason was a protection against compromised CAs which would issue certificates for the same domain although it might belong to a completely different domain with malicious content behind. Although interesting when introduced in the 2010s, it became quickly a hot spot for misconfigurations and even counter-attacks. One immediate example is that browser were storing the pin of the public key for a pretty long time which meant that the certificate needn't to be changed. Which obviously contradicted short-lived certificates from Let's encrypt. As a result, many eager website maintainer found themselves very quickly in a position where the browsers stored and used primarily a pin for a certificate that had been obsolete. They were stuck. Other interesting examples are listed in 2. As of now, our implementation does not grant any bonus points while penalizing wrong configurations. It is listed as an active (but hardly addressed) issue in the Mozilla Github repository 3. Given the complete(!) deprecation of this header, it does not serve any purpose any longer.

Sources

Feature Policy / Permissions Policy

Action

Consider implementing this feature with only bonus points (+5 points) for correctly set headers (regardless of the actual feature that is restricted / allowed).

Reasoning

Feature Policy / Permission Policy is a header that was implemented around 2015 which allows the restriction of certain web features on a given page. Features include such things as notifications (like e.g.: when a website asks the user for permission to send notifications), camera, microphone, access to Payment Request API and the ability to make synchronous XML HTTP Requests among others. Crucially for the origin of this header is that the restriction can be extended to embedded pages as well, such as iFrames. This gives another layer of protection to the webpage developer as well as the visitor as malicious scripts that unintentionally happen to be embedded into the web page and attempt to access certain features are gonna be shut. Additionally, the web page developer can ensure that only those features are available that are truly needed. Given the current state-of-the-art browser landspace however, it is yet to be supported by Firefox and Safari. Chrome, Edge and Opera offer full support although the range of web features vary (please keep in mind that there are currently around 25ish web features that can be configured). Therefore, it is to be considered that we implemented bonus points (+5 points) for correctly setting this header, nothing more and nothing less.

Sources

Server

Action

Consider penalizing 5 points (-5) if the Server header in a HTTP response shows the version number.

Reasoning

The version number grants attackers that desire to hack the website additional information about the Server that is in use (e.g.: Nginx or Apache). Vulnerabilites targeted for specific version numbers can be search for directly on platforms like ExploitDB (not to mention that NIST or Mitre list the specific numbers for CVEs as well). Even the RFC describing the Server header mentions that web page revealing that version number are more likely to be targeted by attackers. As a result, it might be helpful to discourage the usage of the version number by penalizing such configurations.

Sources

Other Changes

Action

Consider penalizing 5 points (-5) if the Server header in a HTTP response shows the version number.

Sources

Scoring

Every scanned domain starts with a base score of 100. According to Mozilla's scoring method points are added for special configurations or subtracted if they are missing or insecure.

This generates a score which then can be mapped to a grade according to the following table:

Scoring Range Grade
100+ A+
90-99 A
85-89 A-
80-84 B+
70-79 B
65-69 B-
60-64 C+
50-59 C
45-49 C-
40-44 D+
30-39 D
25-29 D-
0-24 F

Looks in Discovery

The new column in Discovery shows the Grade from A+ to F for every discovered domain, where a rating was possible.

image-1627895251115.pngClicking on the grade will show the details how we measured the rating. On the details page you will see the reached score and all factors used to calculate it.

image-1627895272679.png

On the new analysis page you can filter for websites passing and/or failing specific tests. That will help you to focus on the most important websites first.

 

Two factor authentication

  1. First you have to click on your username in the top right corner and select the "Change password" function.

    image.png

  2. Here you have the option to choose between 3 possibilities to activate the two-factor authentication.

    image.png



  3. If you want to choose option 3 “Text Message”, you have to deposit your phone number:
    1. Select Profile

      image.png


 

    1. Add your phone number to your profile

      image.png


 

  1. Now you can choose the button “Security” and choose option 3 “Text Message”.

    image.png


  2. After you selected the option “Text message” there is going to appear the following pop up. You are receiving a text message with a verification code.

    image.png


  3. Now you can see, that the status of the two- factor authentication is green and “On”.

    image.png


  4. The other two options are self-explanatory.