[{"id":"cG9zdDozOTc=","slug":"the-essential-no-excuses-security-checklist-for-modern-websites","title":"The essential no-excuses security checklist for modern websites.","content":"\n

The web and its security has come a long way. As always in security there are constantly ways to improve your defences agains bad actors. This is a list of quick and easy, yet powerful tools that all devs should be using.

\n\n\n\n

Update 18 Sep 2019 @ 16:02
As the reddit user zfa suggested I included the link to the Mozilla Observatory for automatic auditing.

\n\n\n\n

\n\n\n\n

1. HTTPS

\n\n\n\n

Let’s start with the most obvious. It’s almost 2020 and websites not using HTTPS are simply being irresponsible. There is no reason to run plaintext http in the era of Letsencrypt where getting a certificate is easy and free. I won’t go over how to configure that, there are tons of resources out there and generally its as simple as adding a line in your config file.
Also redirect all the http traffic to https automatically, basic stuff.

\n\n\n\n

2. TLS Versions

\n\n\n\n

97.65% of global users support TLS version 1.2, so go disable anything below that in your server as it has knows vulnerabilities!

\n\n\n\n

Configuration

\n\n\n\n

# Nginx\nssl_protocols TLSv1.2;

\n\n\n\n

# Apache\nSSLProtocol -all +TLSv1.2

\n\n\n\n

# Traefik\n[entryPoints]\n  [entryPoints.https]\n    [entryPoints.https.tls]\n      minVersion = \"VersionTLS12\"

\n\n\n\n

3. Ciphers

\n\n\n\n

Similar to the TLS version you should avoid using anything different than AES or ChaCha20. Limit the ciphers to something secure and modern.

\n\n\n\n

Configuration

\n\n\n\n

# Nginx\nssl_prefer_server_ciphers on;\nssl_ciphers \n'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

\n\n\n\n

# Apache\nSSLCipherSuite          \nECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256\nSSLHonorCipherOrder     on\nSSLCompression          off\nSSLSessionTickets       off

\n\n\n\n

# Traefik\n[entryPoints]\n  [entryPoints.https]\n    [entryPoints.https.tls]\n      cipherSuites = [\n        \"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256\",\n        \"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384\",\n        \"TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305\",\n        \"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256\",\n        \"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384\",\n        \"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305\",\n      ]

\n\n\n\n

4. HSTS

\n\n\n\n

Once your website runs on HTTPS it’s a good idea to tell the browser not to use HTTP anymore. Thats what the HTTP Strict Transport Security (HSTS) is designed for.

\n\n\n\n

Strict-Transport-Security: max-age=31536000; includeSubDomains

\n\n\n\n

This basically tells the browser to only talk to your domain via HTTPS for the next year. You can exclude the includeSubDomains if you want to just target your root.

\n\n\n\n

Configuration

\n\n\n\n

# Nginx\nadd_header Strict-Transport-Security \"max-age=31536000; includeSubDomains\" always;

\n\n\n\n

# Apache\nHeader always set Strict-Transport-Security \"max-age=31536000; includeSubDomains\"

\n\n\n\n

5. Content Security Policy (CSP)

\n\n\n\n

This awesome HTTP header is incredibly powerful! It allows you to specify the allowed origins for all kind of files that will be loaded into your website.

\n\n\n\n

The basic idea is: “Javascript can only be loaded from my domain, images only from the unsplash domain and fonts only are only allowed from google fonts”.

\n\n\n\n

Awesome right? The header for that example would look like this:

\n\n\n\n

Content-Security-Policy: \"default-src 'self'; img-src https://unsplash.com/; font-src https://fonts.googleapis.com\"

\n\n\n\n

This allows a dev to specify exactly what resources are allowed to load from what domains. Don’t worry, you don’t need to remember the exact syntax:
Use the generator: https://www.cspisawesome.com/

\n\n\n\n

6. X-Frame-Options

\n\n\n\n

This is a basic one, but it should not be forgotten. It prevents your website to be displayed inside another one. This prevents shit tons of possible attack vectors. Simply set the header and you’re done.

\n\n\n\n

x-frame-options: SAMEORIGIN

\n\n\n\n

Configuration

\n\n\n\n

# Nginx\nadd_header x-frame-options \"SAMEORIGIN\" always;

\n\n\n\n

# Apache\nheader always set x-frame-options \"SAMEORIGIN\"

\n\n\n\n

7. X-Content-Type-Options

\n\n\n\n

Again, a little header that prevents lots of damage. By setting the Content Type header you prevent the browser from guessing what file contents a downloaded resource is. Basically if /image.jpeg is actually a .js file the browser would still run it if you don’t set the header

\n\n\n\n

x-content-type-options: nosniff

\n\n\n\n

Configuration

\n\n\n\n

# Nginx\nadd_header x-content-type-options \"nosniff\" always;

\n\n\n\n

# Apache\nheader always set x-content-type-options \"nosniff\"

\n\n\n\n

Libraries & Tools

\n\n\n\n

Tools

\n\n\n\n

For some automatic auditing of your website you can use the excellent Mozilla Observatory tool. You can scan a domain and receive information on Header & TLS.

\n\n\n\n

Libraries

\n\n\n\n

For a lot of this headers there are some good libraries for automating this which already have good default values, so most of them are plug and play.

\n\n\n\n

Express (Node)	helmet
ASP.NET	NWebsec
Django (Python)	django-csp
Dropwizard (Java)	dropwizard-web-security
Flask (Python)	Talisman
Go	secure; secureheader
Hapi (Node)	blankie
Koa (Node)	koa-helmet
PHP	Secure Headers
Ruby (and Rails)	Secure Headers; rack-secure_headers

\n\n\n\n

Considerations

\n\n\n\n

I did not talk about the XSS header, since it’s not supported at all in Firefox and Chromium will remove it in the near future, so I think it gives a false sense of security to devs not being vulnerable to XSS if they set the header.

\n\n\n\n

Also I did not touch on the new Feature Policy header wich is currently being drafted. It’s very cool and will help a lot in the future. It allows websites to specify what features should be allowed to run, so e.g. if my site does not need the accelerometer just turn it off. That way no 3rd party code is able to access it. Very nice addition, but at the time of writing it’s still very alpha and basically not supported.

\n\n\n\n

Where to store JWTs?

\n\n\n\n

Most websites nowadays make use of JWTs for the authentication. A common question people have is: Where do I store my token? Cookies or LocalStorage? TLDR: LocalStorage.

\n\n\n\n

The general knowledge is that LocalStorage is not vulnerable to CRFS and Cookies not to XSS. However as the reddit user Devstackr described here if you have a XSS vulnerability also your authentication via cookie is compromised, as the injected code can do requests on behalf of the authenticated user.

\n\n\n\n

So while your token cannot be directly stolen from the victim, the attacker can still do everything, including changing the password for example. Additionally you don’t need to worry about CRFS at all, which is a huge bonus.

\n\n\n\n

Advanced Practices

\n\n\n\n

Large websites should additionally consider the following security features:

\n\n\n\n

Certificate Authority Authorization (CAA) DNS record which specifies what CA is allowed to sign certificates for the served domain.
HTTP Public Key Pinning (HPKP) provides the option to validate the certificate via DNS record. If misconfigured this can break you entire site, so use carefully!

\n\n\n\n

Sources / Further reading

\n\n\n\n

\n","status":"publish","date":"2019-09-16T14:34:10","modified":"2020-09-22T20:50:05","tags":{"nodes":[{"id":"dGVybToyNg==","slug":"headers","name":"headers","count":1},{"id":"dGVybTo1MQ==","slug":"security","name":"security","count":2}]},"post":{"featured":{"srcSet":"https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-300x169.jpg 300w, https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-1024x576.jpg 1024w, https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-150x84.jpg 150w, https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-768x432.jpg 768w, https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-1536x864.jpg 1536w, https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-2048x1152.jpg 2048w, https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-500x281.jpg 500w, https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-800x450.jpg 800w, https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-1200x675.jpg 1200w, https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-1500x844.jpg 1500w, https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-2000x1125.jpg 2000w","altText":"","sourceUrl":"https://api.nicco.io/wp-content/uploads/2019/09/milkovi-kYlYwQze5vI-unsplash-1-scaled.jpg"}}},{"id":"cG9zdDoyMzk=","slug":"step-up-oauth-security-with-pkce","title":"Step up OAuth security with PKCE","content":"\n

We all have used OAuth at some point. Whether with SSOs or a simple authorization server. While OAuth has multiple so called flows, the most commonly used are the code and the implicit flows. Today we will focus on the security aspect of the latter, pros/cons and solutions to make the implicit flow (more) secure.

\n\n\n\n

I am going to assume some basic OAuth knowledge. Here is a basic explanation. This is a quick more in depth article.

\n\n\n\n

\n\n\n\n

Quick refresher on implicit vs code flows

\n\n\n\n

As mentioned above there are multiple flows in the OAuth2 spec, but in reality only the code and implicit are really used. The big difference between the two ist that in the code flow the there is a pre-shared password. This requires a backend, so the code flow cannot be used in SPAs.

\n\n\n\n

This is where traditionally the implicit flow comes into play. It is basically a played down version of his code brother. Instead of generating a code which is then used in combination with the password on the server side to get the token, in the implicit flow the token is returned directly.

\n\n\n\n

Issues with security in implicit flows

\n\n\n\n

The implicit flow contains the state parameter. This is random value that the client sends to the authorization server. The server then redirects to the client including the token and state that was passed. This prevents CSRF and Replay attacks where an attacker could basically redirect some site to your callback path. The client should delete the state variable when getting the token. This is already pretty good, but we need to do more. You can read the details in the spec.

\n\n\n\n

The server has no way of verifying that the original client actually got the token.

\n\n\n\n

This is a big problem! Since the server cannot verify the identity of the original request it could end up giving the token to a 3rd party which did not make the request. Now an attacker has an access token. 😐

\n\n\n\n

PKCE to the saving 🎉

\n\n\n\n

So how can our app demonstrate that it is the one that made the request? Of course the smart folks at IETF have a solution.

\n\n\n\n

It’s called Proof Key for Code Exchange. In works in a similar way to the code flow, but instead of a password we use hashing. Confused? Let me explain:

\n\n\n\n

Your client wants to authenticate
1. On the client side you generate a random string verifier.
2. You then compute the SHA-256 hash of the verifier which gives you the challenge
3. Your app makes the classic /authorize?...&code_challenge=<string>&code_challenge_method=S256
The authorization server saves does the usual
1. Redirect to user promps.
2. User accepts.
3. Server redirect to your callback path with a code
The client exchanges the code for a token
In the exchange request the client includes the original verifier which was used to generate the challenge hash.
Server verifies the request
The server takes the verifier and generates the challenge on its own, then checks whether it matches with the original one associated with the code
Server send code and client is authenticated.

\n\n\n\n

In this way, using state and the PKCE extension both the client and server are secured. The server can be sure that the token was sent only to the client from which the request originally was created and the client is safe agains CSRF & Replay attacks. WIN WIN. 💪

\n\n\n\n

Below is a diagram by Auth0 which helped me understand the whole process more easily.

\n\n\n\n

\"\" — https://auth0.com/docs/flows/concepts/auth-code-pkce

\n\n\n\n

I hope you found this helpful. I was blown away by the simplicity of PKCE and how sometimes problems can be solved in very elegant ways thanks to smart people.

\n","status":"publish","date":"2019-07-10T20:51:56","modified":"2020-09-22T20:47:33","tags":{"nodes":[{"id":"dGVybTozMA==","slug":"ietf","name":"ietf","count":1},{"id":"dGVybTo0Mg==","slug":"oauth","name":"oauth","count":1},{"id":"dGVybTo1MQ==","slug":"security","name":"security","count":2}]},"post":{"featured":{"srcSet":"https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-300x142.jpg 300w, https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-1024x484.jpg 1024w, https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-150x71.jpg 150w, https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-768x363.jpg 768w, https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-1536x726.jpg 1536w, https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-2048x968.jpg 2048w, https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-500x236.jpg 500w, https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-800x378.jpg 800w, https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-1200x567.jpg 1200w, https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-1500x709.jpg 1500w, https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-2000x945.jpg 2000w","altText":"","sourceUrl":"https://api.nicco.io/wp-content/uploads/2019/07/jielin-chen-pKQIpxzq0ZQ-unsplash-e1562783699383-scaled.jpg"}}}]