Security Scan
To help secure your dbFront installation, dbFront 1.4.2 and higher allow you to run a quick security scan to look for common issues with your dbFront installation. This scan is not intended to replace a professional penetration test.
Security Scan
You can find the results of the security scan in the last tab of the System Monitor. The specific items in the security scan will link back to the specific topics below, where you can find more details, including a fix if required.
Each item includes a Common Vulnerability Scoring System (CVSS) score noted as Risk.
Severity Rating Scale (First.org)
| No Threat | Low | Medium | High | Critical |
|---|---|---|---|---|
| 0.0 | 0.1 - 3.9 | 4.0 - 6.9 | 7.0 - 8.9 | 9.0 - 10.0 |
NOTE: Many of the issues are Low Risk by themselves, but hackers will often combine low-risk attack vectors to either distract or advance their attacks.
Prevent site takeover with a CAA DNS Record
Check the DNS entries for the application domain and verify that a CAA record is present. This check does not validate the CAA record itself.
A CAA record decreases the risk that another Certificate Authority will issue an alternate SSL certificate, which could be used to perform an MTM attack or create a phishing site.
To fix this issue, you should update the DNS at your specific registrar.
Further Reading:
| Version | Vector | Risk |
|---|---|---|
| 3.1 | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N | 3.9 |
Server Binding Check
Check if the site accepts invalid Host headers by submitting a request with an invalid but legal domain name. If the server rejects the request with a status code between 400 and 499, then it is considered successful, and the server is secure.
To secure your server, you need to set up explicit named binding in IIS for each website listed in your sites. It is possible to set up multiple bindings for the same IP and Port.
You likely need to include a binding for your primary domain (e.g. demo.dbFront.com), and for "localhost" to enable testing and configuration from the local server.
Further reading:
| Version | Vector | Risk |
|---|---|---|
| 3.0 | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N | 5.4 |
Force SSL for Cookies
Depending on the Cookie contents, an insecure Cookie can represent a serious risk. dbFront will automatically force the use of Secure cookies on SSL connections, but this can be forced by specifying the following web.config setting.
Further Reading:
| Version | Vector | Risk |
|---|---|---|
| 3.0 | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N | 3.1 |
Prevent Header Injection Attacks (Default: True)
Block Header Injection Attacks by encoding any newline characters in response headers.
Further Reading:
| Version | Vector | Risk |
|---|---|---|
| 3.1 | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N | 5.3 |
Prevent Clickjacking Attacks by Restricting Page Embedding
Blocks the ability to host your web application in an iframe in order to ensure that a malicious host/user can't trick users into clicking on specific buttons without being aware.
Further Reading:
| Version | Vector | Risk |
|---|---|---|
| 3.1 | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N | 4.4 |
Prevent MIME-sniffing attacks
Although dbFront makes a concerted effort to ensure that users can't upload / download invalid content where the MimeType does not match with internal file information (file signature / magic number), it is always possible that preexisting content or polyglot files can allow a dangerous file to be stored. Browsers can scan attachments and come to their own conclusion about how to display or execute a file that could result in attacks. By preventing MIME sniffing, this attack vector is closed.
Further Reading:
- Tenable - Missing 'X-Content-Type-Options' Header
- CompassITC - Mime sniffing - What is it, what are the security implications
| Version | Vector | Risk |
|---|---|---|
| 3.1 | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N | 3.1 |
Disallow cross-domain policy files
Block the use of possibly overly permissive policy files, which could be used to gain unexpected access to local resources.
Further Reading:
| Version | Vector | Risk |
|---|---|---|
| 3.1 | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N | 3.7 |
Limit the Referrer information included with redirect requests
Ensure that the browser won't send sensitive information to third-party sites via the referrer header.
Further Reading:
| Version | Vector | Risk |
|---|---|---|
| 3.0 | AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N | 3.1 |
Force HTTPS usage
Force your website to always communicate via SSL or TLS to ensure that no sensitive information is leaked.
Further Reading:
| Version | Vector | Risk |
|---|---|---|
| 3.0 | AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N | 6.5 |
Require a Content-Security-Policy to Limit the Attack Surface
dbFront will simply require the presence of a Content-Security-Policy. Content security policies can be quite complex and depend heavily on your website's dependencies. The example below is from our Demo site, which uses some Google fonts and allows for the option of using a CDN for the jQuery UI themes.
The Content-Security-Policy also includes "frame-src https://dbFront.com" to allow access to the embedded help.
If you review the Response Headers for dbFront 1.4.2++, you will also notice that dbFront dynamically specifies a Content-Security-Policy fragment that requires that all script tags have a NONCE. This is inserted to block any attempts to insert malicious code.
As you design your content security policy, you can use the following tool to evaluate your work. CSP Evaluator
Further Reading:
| Version | Vector | Risk |
|---|---|---|
| 3.0 | AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N | 3.7 |
Manage access to browser features to enhance security and privacy
The HTTP Permissions-Policy response header allows websites to deny the use of browser features in a document or within any