Gain insights into effective security techniques including patching, cryptography, and phishing prevention. Explore practices to make systems resistant and vulnerabilities more detectable, enhancing defense against attacks.

docker.tar.gz

network-commands

node

It seems like hardly a week goes by without a high-profile computer breach. Why do these happen? How can you prevent them? This course doesn’t have all the answers, but it does outline practices that make life harder for attackers and that will help tide you over until you get a full-time security team in place.

In this course, you will learn 5 simple, yet effective, techniques for preventing attackers from getting into your system. These techniques are related to: patching, software vulnerabilities, cryptography, windows security, and phishing. Within each chapter you will learn the best practices for preventing vulnerabilities and how to make them more detectable. 

This course is based on the Pragmatic Programmers’ book, Practical Security, and is aimed at developers, admins, team leads, architects, technology generalists, and all others who stand guard against the things that disrupt the network.

Practical Security: Simple Practices for Defending Your Systems

# Introduction to `SameSite`
We now have a very strong defense against XSRF—using an anti-XSRF hidden form input on all state-modifying requests. But that defense requires ongoing diligence. We’re never done applying it. We need to reapply this defense every time we add a new state-modifying request to our web application (which will happen pretty often during active development of a web application).

It would be nice if we could layer on a one-time effort to help lessen the impact if we ever forget to be diligent in the future. That is the idea behind [`SameSite` cookies](https://tools.ietf.org/html/draft-west-first-party-cookies-07). Let’s take a look at this defense, how it helps, and what its limitations are.

Suppose we are building a web application that uses a cookie called SessionId to authenticate logged-in users. Normally, this cookie would be created by an HTTP response that includes a Set-Cookie header like this:
```
Set-Cookie: SessionId=sfVZ1yx68LD51I;
```
As we saw in the previous section on XSRF, if this cookie is the session cookie for our web application, it would then be sent on every request to our application, regardless of what site originated the request. Wouldn’t it be nice if we could tell browsers to only send that cookie for requests that originated from our site? That’s the idea behind `SameSite`.

With `SameSite`, the part of the response that sets the cookie would look like:
```
Set-Cookie: SessionId=sfVZ1yx68LD51I; `SameSite`=Strict;
```
or
```
Set-Cookie: SessionId=sfVZ1yx68LD51I; `SameSite`=Lax;
```
To understand this defense, we first need to understand a little bit of HTTP trivia. The HTTP specification defines “safe” and “unsafe” requests in [Section 4.2.1 of RFC7231](https://tools.ietf.org/html/rfc7231#section-4.2.1). Safe requests use the GET, HEAD, OPTIONS, or TRACE methods. Unsafe requests use any of the other HTTP methods, including, most notably, POST requests. This distinction is there because the safe methods shouldn’t change state on the server; only the unsafe ones should be used to modify state. It’s the unsafe ones that we’re concerned with when preventing XSRF.


Adding `SameSite=Strict` to a cookie definition tells a browser to never send that cookie for any request to our site unless the request originated from our site. That sounds good in practice, but it’s often not what we want. With `SameSite=Strict`, other sites won’t be able to link successfully to our web application because the initial request to our web application won’t include the SessionId cookie since it originated from another site. If a user clicks on a link from another website to our web application, that first request would not include the SessionId cookie, so the user would probably be prompted to log in, even if they had already logged in. If you know that you don’t need to support other sites linking to your web application, this would be an appropriate choice.

More often, what you want is to set `SameSite=Lax`. By doing this, all safe requests will send the cookie, even if the request originates from another site. This way, the initial link from an external site to our web application will send the SessionId cookie since clicking on the link will result in a GET request. But a malicious site that wants to exploit XSRF by constructing a form and getting a user to submit a POST request would fail because the `SameSite` attribute on the SessionId cookie wouldn’t get sent because the request originated on another site.

So the addition of the `SameSite` attribute on our session cookie raises the bar for attackers in the event that we forget to implement XSRF defense in a new page in the future. Instead of being able to exploit the vulnerability by merely getting a logged-in user to browse to a website that the attacker controls, the attacker would need to find a DOM injection or XSS vulnerability in our web application in order to exploit the lack of XSRF defense.
Pretty cool. Now what are the limitations of this defense?
In describing the benefits of SameSite, we touched on the first limitation. `SameSite` doesn’t protect you if your site is vulnerable to DOM injection or XSS. Put another way, if your site is dynamic enough to allow an attacker to submit HTML to be viewed by other users, then `SameSite` won’t defend against XSRF attacks launched from within your own web application because all of the HTML and JavaScript is coming from the same site. It would still stop XSRF attacks initiated from other sites.

A second limitation is that the `SameSite` session cookie defense is dependent on support in the browser. Fortunately, it is [widely supported](https://caniuse.com/#search=samesite).

Finally, `SameSite` doesn’t protect you if you allow safe methods to modify state. So if your website creates, updates, or deletes objects in your web application via safe methods, then `SameSite` will not protect you if you forget XSRF defenses.

---
In the next lesson, we'll study some ways that misconfiguration can leave your system vulnerable. 

The SameSite directive can be used to prevent XSRF attacks. Let's see how.

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

XSRF Prevention with SameSite

Introduction to `SameSite` #

XSRF Prevention with SameSite

Introduction to SameSite #

Introduction to `SameSite` #