-
Notifications
You must be signed in to change notification settings - Fork 36
Configuration
OWASP – A6:2017
Scan for network services and alternate endpoints using nmap. No extraneous services should be externally accessible on the server.
Scan for TLS misconfigurations using a tool like sslyze or testssl.sh.
All web applications should be deployed with a valid TLS certificate signed by a globally-trusted or corporate Certificate Authority (CA). Wildcard certificates should be avoided (see Wildcard Certs, Not Quite The Star by Sean Wright).
If the application uses TLS client certificates for authentication, review this functionality for the possibility of bypasses via untrusted certificates. Attempt to bypass authentication by supplying untrusted certificates which have matching identifiers to a valid certificate but are signed by unexpected parties (e.g. publicly-trusted S/MIME certificates, self-signed certificates, or certificates signed by an untrusted CA created by an attacker which matches the identifiers of the application's CA).
A common architecture for mutual TLS involves using a TLS-terminating proxy to authenticate and strip the client certificate, then add the client's identifier in an HTTP header sent to the backend application. In this scenario, ensure that the user cannot supply a malicious header to bypass authentication or impersonate other users.
OWASP – A9:2017
Enumerate software versions for all dependencies. Check for known vulnerabilities in third-party software using databases such as CVE Details, or with automatic checkers like nsp for Node or bundle-audit for Ruby.
Check whether supporting systems such as databases are exposed to the Internet by scanning the relevant IP addresses, hostnames, or ports from an unprivileged network. Any such services should be firewalled.
Attempt to browse to and login to administrative endpoints from an unprivileged network. Best practice for administrative functionality is to restrict public access, for example by only being accessible over a secure VPN. If standard administrative functionality is discovered (e.g. Apache Tomcat's Manager), check that default credentials are not in use.
If the application is intended to be accessed through a load-balancer, security service, or other proxy, it should not be directly accessible. Attempt to navigate directly to the application to verify that this functionality cannot be bypassed.
Verify that cookies are flagged Secure. The HttpOnly attribute provides minor
protections, and is optional but preferred.
Cookies should also make use of the SameSite
attribute, which provides
significant protections against CSRF attacks. As of 2020,
recent versions of all major browsers have set the SameSite attribute to
lax by default (see https://caniuse.com/#feat=same-site-cookie-attribute).
Verify that the following HTTP headers are returned on all responses:
Strict-Transport-Security-
X-Frame-Options: SAMEORIGINor CSPframe-ancestors X-Content-Type-Options: nosniff
The Content Security Policy and Referrer Policy headers should also be audited.
Every HTTP response should contain a Content-Type header specifying the correct, valid MIME type. Serving an incorrect Content-Type for a response that includes user input can often result in XSS.
Additionally, the browser security feature CORB
is significantly strengthened when an application specifies X-Content-Type-Options: nosniff
and serves the correct Content-Type. As a consequence of this, JavaScript should generally not be dynamically generated,
and sensitive data such as cookies or tokens should never be returned directly in the body of a script.
Continue to Design.