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

If XSS is a case of a browser trusting JavaScript from the server too much, XSRF is a case of a server trusting a browser too much.

Let’s go back to our example of a blogging site. Somehow there must be a browser request that saves a blog post to the server. Suppose the blog posting request looks something like this:

```
POST /blog/create HTTP/1.1
Host: www.romansjournalingsite.com
Accept-Encoding: gzip, deflate
Accept: */*
Cookie: sessionid=Re9ljf4uObKk9mSFqBlusxamUKw
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 57
body=It+was+the+best+of+posts.+It+was+the+worst+of+posts.&submit=Publish
```

In a naive web application, that could be all it takes to publish to a hosted blog—a POST request with a logged-in `sessionid` cookie. Let’s see how an attacker or an administrator of an evil website could use this for nefarious purposes.

Suppose I run a malicious website. I ostensibly serve up pictures of adorable kittens playing with yarn. But surreptitiously, I also serve up malicious content like this:

<html lang="en"> 
<head>
  <h1> Malicious site </h1>
</head>
<body>
  <form action="http://romansjournalingsite.com/post/create" method="POST">
    <input
      name=body
      value="Arbitrary Attacker-Controlled Content. I love evilxsrf.com"/> 
    <input type=submit id=submit name=submit value=Publish />');
  </form>
  <script>
    document.getElementById('submit').click();
  </script>
</body>

What does this do? It creates a form with the action we just saw when we looked at the romansjournalingsite.com request that creates a new blog post. Additionally, the form is prepopulated with content that will create a blog post that says Arbitrary Attacker-Controlled Content. I love evilxsrf.com. Finally, it has JavaScript that automatically submits this form as soon as the page is loaded. This payload will cause a modern browser to make a POST request that looks like this:

```
POST /post/create HTTP/1.1
Host: romansjournalingsite.com
Content-Length: 74
Cache-Control: max-age=0
Origin: http://evilxsrf.com
Content-Type: application/x-www-form-urlencoded
Referer: http://evilxsrf.com/kittens.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: sessionid=1234567890abcdef
Connection: close
body=Arbitrary+Attacker-Controlled+Content.+I+love+evilxsrf.com&submit=Publish
```

This looks just like the legitimate request! As far as romansjournalingsite.com is concerned, it is a legitimate request: it has a valid `sessionid` cookie. The admins of evilxsrf.com can use this to control the romansjournalingsite.com account of anyone who’s logged in to romansjournalingsite.com and visits evilxsrf.com.

Just like we saw with XSS requests, this attack forges legitimate requests. They have a legitimate session ID, so the server will treat it as a legitimate request. The POST request wasn’t generated because the user wanted to make that post, but the blog site can’t tell that. The browser’s same-origin policy (SOP) won’t help here either. SOP only says that JavaScript from one site can’t see responses sent back from other sites. But this attack doesn’t require the JavaScript from the malicious site to see a response from the blogging site. This attack only requires that the JavaScript from the malicious site be able to POST a request to the blog site, which it can.

Romansjournalingsite.com needs to differentiate valid requests intentionally made by legitimite users from those that were made by malicious websites. Romansjournalingsite.com can’t rely on session IDs or cookies, as we’ve seen. Romansjournalingsite.com needs to submit a little bit of secret data with every state-modifying request that only romansjournalingsite.com knows. This secret can’t be stored in a cookie, though, because cookie values will be sent regardless of whether the request was initiated by a logged-in user or a malicious site operator. This leaves the form itself.

The defense against this is the XSRF hidden form input. When a user logs into the blog site, the blog site should set a large (say 128 bits, base64–encoded) cookie valid only for the duration of the session. Every page that contains a form that will POST back to the blog server needs to put that same value into a hidden form input. Only the blog site and the browser have this value. So when the user submits a valid POST to the blog site, this request will contain the anti-XSRF value, like this:
```
POST / HTTP/1.1
Host: localhost:1234
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Cookie: antixsrf=XKRYopsd8jXj5DqgfNpHmA
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 94
body=It+was+the+best+of+posts.+It+was+the+worst+of+posts.&submit=Publish&
antixsrf=XKRYopsd8jXj5DqgfNpHmA
```
So the form contains a hidden input whose value matches the xsrf cookie. If this form had been constructed by a malicious third-party website, the request would have looked like this:
```
POST / HTTP/1.1
Host: localhost:1234
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Cookie: antixsrf=XKRYopsd8jXj5DqgfNpHmA
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 72
body=It+was+the+best+of+posts.+It+was+the+worst+of+posts.&submit=Publish
```
That is, the POST request would have had the anti-XSRF cookie, because all requests to the blog site will contain the cookie. But the malicious website wouldn’t be able to guess the value of the anti-XSRF cookie, and so it would not be able to replicate that value in the body of the request. If the server doesn’t see the value in both places, the server can reject the request as a fake. At a minimum, requests like this should be denied and logged for later review.

Most modern web frameworks have defenses against XSRF. They may require additional development effort, however. So be sure to learn what your web development framework provides and use it on all state-modifying requests in your application. For example, there is good documentation on built-in XSRF defenses for [ASP.NET](https://docs.microsoft.com/en-us/aspnet/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages), [Django](https://docs.djangoproject.com/en/2.0/ref/csrf/), and [Ruby on Rails](http://guides.rubyonrails.org/security.html).

There’s an important caveat to XSRF defense. If the page is vulnerable to cross-site scripting (XSS), then the XSRF defenses will be bypassable. So it’s important to make sure that our web applications are not vulnerable to XSS. To see why XSS can bypass XSRF defenses, let’s think back to how XSRF defenses work. They add a little bit of secret information that wouldn’t be exposed or sendable from other websites. Typically, this is done with a hidden form input. If there’s XSS on a page with a hidden form input, malicious JavaScript can be injected into the page to send a request with the XSRF defense value.

In this chapter, you will be introduced to cross-site request forgery.

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

Introduction to Cross-Site Request Forgery (XSRF)