The prevalence of online attacks against websites has accelerated quickly in recent years and the same risks continue to be readily exploited. However, these are very often easily identified directly within the browser; it's just a matter of understanding the vulnerable patterns to look for. This course comes at security from the view of the attacker in that their entry point is typically the browser. They have a website they want to probe for security risks â€“ this is how they go about it. This approach is more reflective of the real online threat than reviewing source code is and it empowers developers to begin immediately assessing their applications even when they're running in a live environment without access to the source. After all, that's what online attackers are doing.
Troy Hunt is a Microsoft Regional Director and MVP for Developer Security. He's a regular conference speaker, frequent blogger at troyhunt.com and is the creator of the data breach notification service known as “Have I Been Pwned”.
Introduction Hi, my name is Troy Hunt and I'd like to welcome you to my course on Hack Yourself First, which is all about how web developers can go on the offense before online attackers do. Let me give you a bit of an overview of some of the things we're going to cover in this course. The first thing I'd like to make really clear is that this course is for web developers. It's not aimed at security professionals such as penetration testers. This is for developers that want to understand how to increase the security position of their own code. So everything we're going to look at in this course is going to use tools and environments that are very familiar to many developers. After all once you learn how to hack yourself first, you're the guys who then need to go back and improve the security position. Now one thing that I really wanted to focus on in this course is to make it platform agnostic. And what I mean by that is that it doesn't matter what service side web framework you're developing on, this course is relevant across all of them. If your web application loads over HTTP and returns angle brackets, this course is for you. Now of course how you mitigate the specific risks that we find throughout this course will depend on your technology stack. So I'm going to talk about the sort of behaviors that you can observe that have security risks, and then I'm going to show you how the website should behave once those security risks are rectified, but the execution of how you do that may differ between technology stacks. If you are an ASP. NET developer, I do have another course on Pluralsight called the OWASP Top 10 for. NET developers. And that comes at security from the other angles, so it actually starts at the development side and looks at secure coding practices. So if you're a. NET developer, go and check out that course. And in fact, if you work with any other technology stack, there's still a lot of relevance in that course for you, but the semantics of the implementation may differ slightly in your chosen framework.
Transport Layer Protection Hi. This is Troy Hunt, and welcome to the first module of the course on Transport Layer Protection. In this module, we're going to start out by looking at the three objectives of transport layer protection, or as we'll often refer to it HTTPS, SSL or TLS. We're then going to take a look at what it means to mount a man in the middle attack because this is really the risk that we're trying to protect against when we use transport layer protection. We'll move on to taking a look at protecting sensitive data in transit, which is what most people think of SSL as being all about. And then we'll move on to looking at the risk of sending cookies over insecure connections because a lot of people don't realize how important it is to protect things like AuthCookies. From there, we'll take a look at some risky practices such as loading a login form over HTTP. Many people think that if you post to HTTPS, it doesn't matter that the login form is loaded over HTTP, but that's not the case, and we'll have a look at how we can attack that pattern. Another pattern we'll attack is mixed mode content, which is when we load a page over HTTPS, but then we embed content over HTTP. And finally, we'll finish up with the HTTP strict transport security header, which is also often referred to as HSTS. So, let's jump into understanding those three objectives.
Cross Site Scripting (XSS) Hi. This is Troy Hunt, and in this module we are going to look at the risk of cross site scripting, which we'll also often refer to as XSS. In this module, we're going to begin by understanding the concept of untrusted data and sanitization. So, we'll define what untrusted data is, look at some of the places it comes from, and then look at some of the typical practices used to sanitize potentially malicious content originating from outside the system. We'll then go and take a look at our vulnerable app and try and draw some conclusions about what sanitization practices are being used, and we're going to need this information in order to then go and exploit risks in the application. Once we understand that, we can start looking at what XSS itself is and delve into the concept of output encoding, and particularly output encoding for different contexts, which is something that people often get wrong when mitigating against the risk of XSS. With that knowledge in hand, we'll then move on to actually identifying how output encoding is used in the vulnerable app, and we'll find there are a couple of different contexts where our untrusted data is reflected. Now that we understand all that, we can move on to actually creating a malicious payload and delivering it via reflected XSS, and then also looking at where a risk of persistent XSS might exist. And finally, we'll round out the module by looking at the X-XSS-Protection header used by Internet Explorer and talk a little bit about native browser defenses. So, that's what's coming up. Let's jump into understanding the concepts of untrusted data and sanitization.
Cookies Hi. This is Troy Hunt, and in this module we are going to look at the security of our cookies. We're going to start out with a little bit of cookies 101, or, in other words, the fundamentals of how HTTP cookies are handled by browsers and websites. We'll then take a look at HttpOnly cookies because there's a very fundamental security difference about cookies that have this flag. After that, we'll take a look at secure cookies. And as all encompassing as a securer cookies sounds, it is about one attribute in particular, which helps us mitigate some of the risks we've seen earlier on in this course. We'll then take a look at how we can restrict a cookie by path and how that changes the behavior and consequently the risk profile of a cookie. After that, we'll take a look at also further reducing the risk by setting a cookie expiration, and this is going to be one of those discussions about usability versus security and finding an appropriate tradeoff between the two. And finally, we'll take a look at the concept of a session cookie, which is closely related to cookie exploration, but is a discrete topic that's important to understand in the context of security. So, let's jump into it and start with that cookies 101.
Cross Site Attacks Hi this is Troy Hunt and in this module we'll going to take a look at Cross Site Attacks. We're going to take a look at a few different attack vectors for a cross site attack. But before we do that, I want to start by understanding the nature of these attacks and what it is about website design that makes them successful. We'll then move on to specifically looking at cross site request forgery risks, and you'll often see this sort of attack referred to as CSIF. We'll then move on and take a look at the role of anti-forgery tokens, because they're really the only solid defense we have against a CSIF attack. But as we'll see in our vulnerable website, anti-forgery tokens are very frequently not present in web applications. After that we'll also take a look at the risk of CSIF against APIs. Very commonly we'll find CSIF risks mitigated in normal HTML pages, but then the API is left vulnerable. So, we're going to take a look at that attack vector as well. And finally we're going to take a look at clickjacking, and this is an attack vector that many developers are not aware of, and you very very frequently see websites at risk of this. So what we'll do is mount a clickjack attack on the vulnerable web application and then we'll review what a secure implementation of a website looks like, and how it stops a clickjack attack dead in its tracks. So let's move on to understanding what makes a cross site attack possible.