Web

Web Security

Based heavily on Feross Aboukhadijeh's CS 253 Stanford course.

Quiz

## <i class="fas fa-question-circle"></i> Retry Promise
                            
                            Implémenter une fonction qui tente d'executer une Promise un certain nombre de fois avant d'abandonner et de rejeter.

Plus précisément, la fonction retryUntil doit retourner une Promise et prendre en arguments
                            
                            - Une fonction retournant une Promise
                            - Une error représentant ce avec quoi la Promise retournée doit échouer si celle passée en argument a dépassé le nombre d'essais autorisés
                            - Un nombre trials représentant le nombre d'essais à faire avant d'échouer
                            
                            Cette fonction doit donc retourner une Promise qui
                            
                            - réussit comme la Promise donnée en argument si celle-ci réussit en moins de trials essais,
                            - échoue avec error si la Promise donnée en argument a échoué trials fois d'affilée.

Disclaimer

Same Origin Policy

Cross-Origin Resource Sharing

(CORS)

## <i class="fas fa-globe-europe"></i> Allowing specific origins

The `Origin` and `Access-Control-Allow-Origin` headers combined enable whitelisting specific origins.
                            
                            In a request from `domain-a.com`, the `Origin` header tells `domain-b.com` where the request comes from.

```http
                            GET / HTTP/1.1
                            Host: domain-b.com
                            Origin: http://domain-a.com
                            ```

In a response from `domain-b.com`, the `Access-Control-Allow-Origin` header tells the browser if it is allowed to include the resource.
                            Here, the `*` wildcard means that the resource can be accessed by any domain.

```http
                            HTTP/1.1 200 OK
                            Access-Control-Allow-Origin: *
                            ```

The `domain-b.com` server can also restrict access to `domain-a.com` only as follow:

```http
                            HTTP/1.1 200 OK
                            Access-Control-Allow-Origin: http://domain-a.com
                            ```

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Note that the `Origin` header is sent to allow the server to make a more informed decision on its response.

# <i class="fas fa-globe-europe"></i> CORS credentialed requests

When making cross-origin requests, **CORS** does not send or receive cookies or HTTP authentication information by default.

`fetch` and `XMLHttpRequest` include an option to include those credentials in the request. We call it a "credentialed" request.
                            
                            ```js
                            fetch(url, {method: 'POST', credentials: 'include', body: JSON.stringify(data)});
                            ```

The server then responds with `Access-Control-Allow-Credentials: true` to allow the browser to include the response in the client's context. If missing, the response is discarded.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials

This can be useful, for example, in the case of a single sign-on (SSO) system, where the user is authenticated on a different domain than the one serving the content.

# <i class="fas fa-globe-europe"></i> CORS preflight request

For requests that can have an effect on the server (e.g. `POST`, `DELETE`, etc), the browser first needs to check if the server allows this kind of request.

It does so by sending a **preflight request**, which is an `OPTIONS` HTTP request that includes the HTTP method and headers that would be used in the actual request.

```http
                            OPTIONS / HTTP/1.1
                            Host: domain-b.com
                            Origin: http://domain-a.com
                            Access-Control-Request-Method: DELETE
                            Access-Control-Request-Headers: X-PINGOTHER, Content-Type
                            ```

If allowed, the server responds with the corresponding headers, allowing the browser to send the actual request.

```http
                            HTTP/1.1 200 OK
                            Access-Control-Allow-Origin: http://domain-a.com
                            Access-Control-Allow-Methods: DELETE
                            Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
                            ```

The browser can then send the actual request.

This mechanism ensures requests that were not intended by the user never get to the server. It does not prevent the server from ever receiving unwanted requests.

https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

Client-side security

Cookies and Sessions

## <i class="fas fa-cookie-bite"></i> Cookie Attributes

A cookies without `Expires` is called a session cookie, i.e., it is deleted when the client shuts down.

**Expires** and **Max-Age**: expiration date for the cookie. If omitted, it is called a *session cookie* and expires with the current session (browser-dependent).
                            
                            ```http
                            Set-Cookie: cookie=choco; Expires=Wed, 21 Oct 2020 07:28:00 GMT;
                            ```
                            
                            **HttpOnly**: the cookie should not be accessible to JavaScript.
                            ```http
                            Set-Cookie: cookie=choco; HttpOnly
                            ```

**Secure**: the cookie should only be transmitted over HTTPS.
                            ```http
                            Set-Cookie: cookie=choco; Secure
                            ```

**SameSite**: whether the cookie should be sent with cross-site requests.
                            ```http
                            Set-Cookie: cookie=choco; SameSite=[Strict|Lax|None]
                            ```

And more we will cover later...

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Client-side security

Cross-Site Request Forgery (CSRF)

## Cross-site Cookies

Cookies are sent with every request to their origin, **regardless of the source of the request**, unless CORS prevents it (e.g. cross-origin `fetch`).

If I make you click on `https://bank.com/transfer?to=me&amount=1000`, your browser will send your session cookie to `bank.com` with the request, which will succeed.

This also works with POST requests:
                            ```html
                            <form action="https://bank.com/transfer" method="POST">
                                <input type="hidden" name="to" value="me">
                                <input type="hidden" name="amount" value="1000">
                                <input type="submit" value="Click here to win a free iPad!">
                            </form>
                            ```
                            *(Such form could even be sent on load with JS: `document.forms[0].submit()`)*

## Mitigations

`Referer` and `Origin` may seem similar but differ in some important points
                            - `Origin` only contains the origin (domain, protocol and port), not the full URL.
                            - `Origin` is sent with all preflight requests and credentialed requests as part of CORS, while `Referer` has a different purpose.
                            - `Referer` is used to track where a user comes from, including when clicking on a link.
                            - `Referer` is mostly used for analytics, logging, cache control.

Example of `Origin` header:
                            ```http
                            Origin: https://web-classroom.github.io
                            ```

Example of `Referer` header:
                            ```http
                            Referer: https://web-classroom.github.io/lessons/cookies
                            ```

## Mitigations

#### CSRF tokens

Require the request to include an unforgeable secret token.

```html
                            <form action="https://bank.com/transfer" method="POST">
                                <input type="text" name="to" value="me">
                                <input type="number" name="amount" value="1000">
                                <input type="hidden" name="token" value="eyJ2IjoxLCJldSI6MCwic3QiOjB9">
                                <input type="submit" value="Validate payment">
                            </form>
                            ```
                            The token is generated by the server upon sending the form, and stored in the session.

##### How does that differ from a session ID?
                            
                            The CSRF token is different from a session ID in that it is not sent in the cookie, but rather in the form itself. This means that requests to that form's action need to be made from the form's page, and therefore cannot be made from a different origin.

</i>

## Mitigations

#### CSRF tokens

Require the request to include an unforgeable secret token.

The token is generated by the server upon sending the form, and stored in the session.

##### Why can an attacker not just use CSRF to get the form and then use the token to send the request?

Because of the Same-Origin Policy, an attacker cannot read the response from the server, and thus cannot read the token (unless the server allows it with CORS, which is highly unlikely).

Client-side security

Cross-Site Scripting (XSS)

## Variable injection

JavaScript creates a global variable for every HTML element with an `id` attribute.

```html
                            <div id="username">...</div>
                            <script>
                                alert(username.textContent)
                            </script>
                            ```

Although limited, allows impact on execution flow, if attacker can control an `id` attribute.

```html
                            <div id="ESCAPED_USER_DATA">...</div>
                            <script>
                                if (connected) {
                                    // Sensitive stuff
                                } else {
                                    // Whatever stuff
                                }
                            </script>
                            ```

Setting `ESCAPED_USER_DATA` to `connected` affects the execution flow.

## XSS mitigations

- Always escape on the way out. <span class="detail">Don't trust your stored data, someone could have managed to insert unescaped data into it.</span>
                            - Let built-in function do it (e.g. `htmlEscape`, ejs templates, etc).
                            - Don't put user data in stupid places (e.g. inside a `<script>` tag...).
                            - Stack defenses: assume the attacker is already in your JS environment.
                                - Ask password or 2FA for important actions (change password, delete account, etc).
                                - Send emails for audit logs.
                                - Defend user's cookies with `HttpOnly`.
                                - Use `Content-Security-Policy` to prevent loading of external scripts. <span class="detail">CSP prevents our site from making requests to other sites or executing inlined JS. Useful when you know you don't need cross-site references.</span>

Are CSRF tokens a mitigation against XSS?

Client-side security

Phishing

Server-side Security

Authentication

## Authentication Mechanisms

The `Authentication` header is a generic header that can be used to send authentication information to the server. It can hold authentication data of any form; the server is responsible for parsing it and verifying it.
                            
                            Its value can follow different [authentication schemes](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml).
                            - Basic: username and password are encoded in base64 and sent in the header. It is not secure, as it is sent in plaintext.
                            - Bearer: a token is sent in the header, used to describe the user. That token is generated by the server, and can be verified by the server. The protocol used to create and verify this token is freely chosen by the server. Some examples are
                                - HMAC: the token is a hash of the user's data, signed with a secret key.
                                - JWT: the token is a JSON object containing the user's data, signed with a secret key.
                            
                            Often times, JWT uses HMAC to sign its JSON.

## Authorization Mechanisms

In Web applications, authorization mechanisms often rely on the notions of:
                            - Roles (admin, editor, user)
                            - Ownership (does this resource, object or attribute belong to that user)

In practice, authorization mechanisms are often hard-coded, which gives a lot of flexibility.
                            However, it is also possible to rely on authorisation patterns, such as:

- [Access-Control List (ACL)](https://en.wikipedia.org/wiki/Access-control_list)
                            - [Role-based access control (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control)
                            - [Attribute-based access control (ABAC)](https://en.wikipedia.org/wiki/Attribute-based_access_control)

In ExpressJS, the [express-acl](https://www.npmjs.com/package/express-acl) and [express-rbac](https://www.npmjs.com/package/express-rbac) packages provides authorization middlewares.

## <i class="fas fa-hand-paper"></i> JSON Web Token (JWT)
                            
                            <!-- Try to answer the following questions:
                            - Can JWT be used for Authentication?
                            - Can JWT be used for Authorization?
                            - Why is JWT often refered to as a scalable method?
                            - Can a JWT token be easily revoked?
                            - Would you use JWT tokens for authenticating computers that perform API calls?

-->

Standardized method for representing claims in a self-contained and secure manner. It contains
                            - a header with metadata (algorithm, type)
                            - a payload with the claims
                            - a signature to verify the integrity of the token
                            
                            It is generally created by the server and given to a client. The client then sends it back to the server with each sensitive request, usually in the `Authorization` header:

```http
                            Authorization: Bearer <token>
                            ```

It can thus be used for both authentication and authorization (by including the user's roles in the payload).
                            
                            - **Scalability**: Because it is self-contained, it requires no server-side state.
                            - **No-secrecy**: The payload is **not** encrypted, so it should not contain sensitive data.
                            - **Revocation**: JWT tokens cannot be revoked by the server, unless through blacklisting.
                            - **REST API keys**: JWT tokens can be used to authenticate and authorize API callers statelessly.

## <i class="fas fa-hand-paper"></i> OAuth2

Standard for authorizing third-party applications to access a user's data without sharing their credentials. It handles relations between

- The **Resource Owner** that owns the data and can grant access to it
                            - The **Resource Server** that hosts the owner's data
                            - The **Client** that wants to access the owner's data
                            - The **Authorization Server** that issues access tokens upon request by the client, and authorization by the owner.

It uses an **Access Token** to represent the authorization granted by the user to the third-party application. That token is often a JWT token.
                            
                            https://auth0.com/docs/api-auth/which-oauth-flow-to-use