Authentication Continued

This week we will continue with Authentication, starting with cookie vulnerabilities in the form of Cross-Site Forgery Requests.

Cross-Site Forgery Request (CSRF)

[OWASP CSRF Page](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF%29)

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

CSRF attacks leverage the fact that a user is authenticated in the current browser and perform the attack from a completely different website or domain. For example, I could create a blog post which, when visited, transfers money from the user's bank. See the first example below for how that could work.

Examples of a CSRF attack:

CSRF Prevention

[OWASP CSRF Prevention Cheatsheet](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF%29_Prevention_Cheat_Sheet)

Verify Same Origin

Verifying that the Source, Referer, and Target origins are the same is an important part of protecting against CSRF. We will look into this topic when we cover CORS.

Synchronizer (CSRF) Tokens (Nonce)

Synchronizer Tokens (also called Nonces) are a cryptographically secure random number that is added as part of a web form or request. The nonce should be unique per user session, and the server should reject the requested action if the CSRF token fails validation. Any state-changing operation should require a nonce to prevent CSRF attacks.

There is a [Synchronizer Token Pattern](http://www.corej2eepatterns.com/Design/PresoDesign.htm) you can use to guide in the development of a secure CSRF solution.

Here's an example of what an embedded CSRF token field could look like:

Assignment: Implement Synchronizer Tokens

Implement synchronizer tokens to protect the `/post` endpoints.

We can use the following npm module to simplify our code: [ExpressJS CSURF](https://github.com/expressjs/csurf)

Request Headers

We've talked about how HTTP requests can be of different types (GET, POST) and contain different types of data (url query strings and body content). We will now investigate another way requests can contain data: [HTTP Headers](https://en.wikipedia.org/wiki/List_of_HTTP_header_fields)

Example [HTTP Request](https://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html):

We can use telnet to view the raw HTTP protocol by requesting Google's home page.

In Class: Let's use Request Headers in Node

Here's where we can find request headers in our node app:

console.log(JSON.stringify(req.headers));

Let's use the Web API [Request Object](https://developer.mozilla.org/en-US/docs/Web/API/Request) to make a request with [Headers](https://developer.mozilla.org/en-US/docs/Web/API/Request/headers)

To test this, we can add headers in Postman request.

JWT Tokens

JWT Tokens are a compact and secure way to transmit information between services using JSON objects. Read more here: [JWT Tokens Introduction](https://jwt.io/introduction/)

We can use the [jwt.io Debugger](http://jwt.io/) to play around with this example token:

In Class/ Homework: Let's use JWT in our App

[JWT Express](https://www.npmjs.com/package/jwt-express) is a module that makes it easy to use JWT Tokens to secure our API.

Use JWT to accomplish the following goals:

When the user log's in, generate a JWT Token and return that to the client.
Send the JWT Token in the header of all following API requests.
Verify the JWT Token in your API requests. If the token is missing or invalid, the server should return a 401: Forbidden