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

# Introduction
Last but not least, let's look at the `SameSite` flag, one of the latest entries in the cookie world.

Introduced by Google Chrome v51, this flag effectively eliminates *Cross-Site Request Forgery* (CSRF) from the web, `SameSite` is a simple yet groundbreaking innovation as previous solutions to CSRF attacks were either incomplete or too much of a burden to site owners.

In order to understand `SameSite`, we first need to have a look at the vulnerability it neutralizes. A CSRF is an unwanted request made by site A to site B while the user is authenticated on site B.

Sounds complicated? Let me rephrase, suppose that you are logged in on your banking website, which has a mechanism to transfer money based on an HTML `<form>` and a few additional parameters like destination account and amount. When the website receives a `POST` request with those parameters and your session cookie, it will process the transfer. Now, suppose a malicious third party website sets up an HTML form as such.

```html
<form action="https://bank.com/transfer" method="POST">
<input type="hidden" name="destination" value="attacker@email.com" />
<input type="hidden" name="amount" value="1000" />
<input type="submit" value="CLICK HERE TO WIN A HUMMER" />
</form>
```

See where this is getting? If you click on the submit button, cleverly disguised as an attractive prize, $1000 is going to be transferred from your account. This is a cross-site request forgery, nothing more, nothing less.

Traditionally, there have been two ways to get rid of CSRF:

# Origin and Referrer headers

The server could verify that these headers come from trusted sources (ie. `https://bank.com`). The downside to this approach is that, as we've seen in previous chapters, neither the `Origin` nor `Referrer` are very reliable and could be turned off by the client in order to protect the user's privacy.

# CSRF tokens

The server could include a signed token in the form and verify its validity once the form is submitted. This is a generally solid approach and it's been the recommended best practice for years. The drawback of CSRF tokens is that they're a technical burden for the backend, as you'd have to integrate token generation and validation in your web application: this might not seem like a complicated task, but a simpler solution would be more than welcome.

`SameSite` cookies aim to supersede the solutions mentioned above once and for all. When you tag a cookie with this flag, you tell the browser not to include the cookie in requests that were generated by different origins. When the browser initiates a request to your server and a cookie is tagged as `SameSite`, the browser will first check whether the origin of the request is the same origin that issued the cookie. If it's not, the browser will not include the cookie in the request.

We can have a practical look at `SameSite` with the example at [github.com/odino/wasec/tree/master/cookies](https://github.com/odino/wasec/tree/master/cookies). When you browse to [wasec.local:7888/?samesite=on](http://wasec.local:7888/?samesite=on) the server will set a `SameSite` cookie and a regular one.




In this lesson, we'll look at the SameSite flag.

Introduction

Understanding The Browser

HTTP

Protection through HTTP Headers

HTTP Cookies

Situationals

DDoS Attacks

Bug Bounty Programs

Conclusion

SameSite: The CSRF Killer

Introduction