Gain insights into enforcing web app security best practices, such as HTTPS, defending against XSS and clickjacking, managing HTTP cookies, and warding off DDoS attacks.

new.tar.gz

node

cookies

hsts

hsts-https

cookies-https

clickjacking

cors

There are more vulnerabilities than ever when creating applications for the web, so it is extremely important that software developers enforce security best practices such as, how to add protection through HTTP headers.

In this course, you will start off by learning how to prevent fraudulent SSL certificates from being served to clients, before moving on to how to defend against XSS attacks and clickjacking. 

In the latter half of the course, you’ll learn security practices related to HTTP cookies, and tips around security tradeoffs that you’ll make in your day-to-day work. Towards the end, you’ll learn how to ward off DDoS attacks, which is crucial when your application scales.

This course will demystify web security, and help you stay on top of important security-related concerns in your web apps.

Web Application Security for the Everyday Software Engineer

## Stateful web architectures are more efficient

If you've ever built a web architecture, chances are that you've heard how stateless architectures scale better due to the fact that they do not have to keep track of state. This is true and represents a security risk, especially in the context of authentication state.

In a typical stateful architecture, a client is issued a session ID which is stored on the server and linked to the user ID. When the client requests information from the server, it includes the session ID, so that the server knows a particular request was made on behalf of a user with a particular ID. This requires the server to store a list of all the session IDs it generated with a link to the user ID, and it can be a costly operation.

JWTs, which we spoke about earlier in this chapter, rose to prominence due to the fact that they easily allow stateless authentication between the client and the server so that the server doesn't have to store additional information about the session. A JWT can include a user ID, and the server can simply verify its signature on-the-fly, without having to store a mapping between a session ID and a user ID.

## True stateless architectures are difficult to secure

The issue with stateless authentication tokens (and not just JWTs) lies in a simple security aspect, it is hard to invalidate tokens, as the server has no knowledge of each one generated since they're not stored anywhere. If I logged in on a service yesterday and my laptop gets stolen today, an attacker could simply use my browser and would still be logged in on the stateless service, as there is no way for me to invalidate the previously-issued token. 

## Solution: take the middle ground

This can be easily circumvented, but it requires us to drop the notion of running a completely stateless architecture, as there will be some state-tracking required if we want to be able to invalidate JWTs. The key here is to find a sweet spot between stateful and stateless, taking advantage of both the pros of statelessness (performance) and statefulness (more control).

Let's suppose we want to use JWTs for authentication, we could issue a token containing a few pieces of information for the user
```text
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkxlYnJvbiBKYW1lcyIsImlhdCI6MTUxNjIzOTAyMn0.UJNHBHIBipS_agfTfTpqBmyOFaAR4mNz7eOwLOKUdLk
```

```console
$ cut -d'.' -f1 <<< $TOKEN | base64 -d
{"alg":"HS256","typ":"JWT"}%                                                            

$ cut -d'.' -f2 <<< $TOKEN | base64 -d
{"sub":"1234567890","name":"Lebron James","iat":1516239022}
```

As you can see, we included an *issued at* (`iat`) field in the token, which can help us invalidate expired tokens. You could then implement a mechanism whereby the user can revoke all previously issued tokens by simply clicking a button that saves a timestamp in a `last_valid_token_date` field in the database.

The authentication logic you would then need to implement for verifying the validity of the token would look like this:


```go
function authenticate(token):
  if !validate(token):
    return false
  
  payload = get_payload(token)
  user_data = get_user_from_db(payload.name)

  if payload.iat < user_data.last_valid_token_date:
    return false

  return true
```

## Minimizing database hits

Easy-peasy! Unfortunately, this requires you to hit the database every time the user logs in, which might go against your goal of scaling more easily through being state less. An ideal solution to this problem would be to use two tokens, a long-lived one and a short-lived one (e.g., one to five minutes).

When your servers receive a request:

* If it has the long-lived one only, validate it and do a database check as well. If the process is successful, issue a new short-lived one to go with the long-lived one
* If it carries both tokens, simply validate the short-lived one. If it's expired, repeat the process on the previous point. If it's valid instead, there's no need to check the long-lived one as well

This allows you to keep a session active for a very long time (the validity of the long-lived token) but only check for its validity on the database every N minutes depending on the validity of the short-lived token. Every time the short-lived token expires, you can go ahead and re-validate the long-lived one, hitting the database.

Other major companies, such as Facebook, keep track of all of your sessions in order to offer an increased level of security.


# Stateful web architectures are more efficient

If you've ever built a web architecture, chances are that you've heard how stateless architectures scale better due to the fact that they do not have to keep track of state. This is true and represents a security risk, especially in the context of authentication state.

In a typical stateful architecture, a client is issued a session ID which is stored on the server and linked to the user ID. When the client requests information from the server, it includes the session ID, so that the server knows a particular request was made on behalf of a user with a particular ID. This requires the server to store a list of all the session IDs it generated with a link to the user ID, and it can be a costly operation.

JWTs, which we spoke about earlier in this chapter, rose to prominence due to the fact that they easily allow stateless authentication between the client and the server so that the server doesn't have to store additional information about the session. A JWT can include a user ID, and the server can simply verify its signature on-the-fly, without having to store a mapping between a session ID and a user ID.

# True stateless architectures are difficult to secure

The issue with stateless authentication tokens (and not just JWTs) lies in a simple security aspect, it is hard to invalidate tokens, as the server has no knowledge of each one generated since they're not stored anywhere. If I logged in on a service yesterday and my laptop gets stolen today, an attacker could simply use my browser and would still be logged in on the stateless service, as there is no way for me to invalidate the previously-issued token. 

# Solution: take the middle ground

This can be easily circumvented, but it requires us to drop the notion of running a completely stateless architecture, as there will be some state-tracking required if we want to be able to invalidate JWTs. The key here is to find a sweet spot between stateful and stateless, taking advantage of both the pros of statelessness (performance) and statefulness (more control).

Let's suppose we want to use JWTs for authentication, we could issue a token containing a few pieces of information for the user
```text
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkxlYnJvbiBKYW1lcyIsImlhdCI6MTUxNjIzOTAyMn0.UJNHBHIBipS_agfTfTpqBmyOFaAR4mNz7eOwLOKUdLk
```

```console
$ cut -d'.' -f1 <<< $TOKEN | base64 -d
{"alg":"HS256","typ":"JWT"}%                                                            

$ cut -d'.' -f2 <<< $TOKEN | base64 -d
{"sub":"1234567890","name":"Lebron James","iat":1516239022}
```

As you can see, we included an *issued at* (`iat`) field in the token, which can help us invalidate expired tokens. You could then implement a mechanism whereby the user can revoke all previously issued tokens by simply clicking a button that saves a timestamp in a `last_valid_token_date` field in the database.

The authentication logic you would then need to implement for verifying the validity of the token would look like this:


```go
function authenticate(token):
  if !validate(token):
    return false
  
  payload = get_payload(token)
  user_data = get_user_from_db(payload.name)

  if payload.iat < user_data.last_valid_token_date:
    return false

  return true
```

# Minimizing database hits

Easy-peasy! Unfortunately, this requires you to hit the database every time the user logs in, which might go against your goal of scaling more easily through being state less. An ideal solution to this problem would be to use two tokens, a long-lived one and a short-lived one (e.g., one to five minutes).

When your servers receive a request:

* If it has the long-lived one only, validate it and do a database check as well. If the process is successful, issue a new short-lived one to go with the long-lived one
* If it carries both tokens, simply validate the short-lived one. If it's expired, repeat the process on the previous point. If it's valid instead, there's no need to check the long-lived one as well

This allows you to keep a session active for a very long time (the validity of the long-lived token) but only check for its validity on the database every N minutes depending on the validity of the short-lived token. Every time the short-lived token expires, you can go ahead and re-validate the long-lived one, hitting the database.

Other major companies, such as Facebook, keep track of all of your sessions in order to offer an increased level of security.


In this lesson, we'll study some session invalidation strategies and how to choose one that's best for your goals.

Introduction

Understanding The Browser

HTTP

Protection through HTTP Headers

HTTP Cookies

Situationals

DDoS Attacks

Bug Bounty Programs

Conclusion

Deploy an API to Production Using Nginx

Session Invalidation in a Stateless Architecture

Stateful web architectures are more efficient