Check out a free preview of the full The Good Parts of JavaScript and the Web course

The "A Simple Attack" Lesson is part of the full, The Good Parts of JavaScript and the Web course featured in this preview video. Here's what you'd learn in this lesson:

Doug walks through a very simple example of a cross site scripting attack. He also stresses the importance of properly encoding all non-literal elements during concatenation. Doug wraps up his coverage on security with a few final thought and recommendations.


Transcript from the "A Simple Attack" Lesson

>> [MUSIC]

>> Douglas Crockford: This is the simplest XSS attack, and just to show you what the beast actually looks like. So, in this attack, the attacker tricks your user into clicking on a URL that looks like that. It's a really weird looking URL with angle brackets and crazy stuff in it, and you might think, no user would ever click on that, and unfortunately, no, they will.

And, if they're smart enough not to click on a URL that looks like that, they'll probably click on a URL. It'll probably accept a QR code, so yeah, they're gonna go there. And so, it used to be that Web servers, by default, would simply take the file name and stick it in the body of a 404 Page and send it back.

In this case, now in the HTML context, that becomes a script tag, which will then execute a load script from the world's most dangerous server. They get access to everything that you've got on the browser. They've got your cookies, they've got your local storage, they've got the Chrome saying this is a valid thing.

So, when they ask for your password, everything's good, and there are thousands, maybe millions, of variations on this, and a security expert can get some theme by discovering another one. They can always do that because there is an endless supply of these things, but the solution to all of these is exactly the same.

Everything has to be filtered correctly, everything has to be encoded correctly. So, if you encode this and turn those into entities before putting it on, then it becomes inert, and it becomes really important to do that everywhere. If you do that correctly everywhere, then these sorts of injection attacks cannot happen.

>> Speaker 2: All right, okay, I think I'm missing the first part of this, so you go to, all this nonsense, this script that's in there.
>> Douglas Crockford: Yeah.
>> Speaker 2: And the server responds with 404, but it sticks that content in it?
>> Douglas Crockford: Yeah, it takes the filename, puts it in, says this is the file we couldn't find.

>> Speaker 2: I see, so okay, and now this script runs a form that says, please submit your password, and they send it their password, whatever.
>> Douglas Crockford: Yep.
>> Speaker 2: Whatever it is.
>> Douglas Crockford: Whatever it is.
>> Speaker 2: In fact, this script can now talk to both sides.
>> Douglas Crockford: Yep.
>> Speaker 3: And you're saying the mitigation is done in the 404 Page you have on your server.

>> Douglas Crockford: Right, so in fact, every page your server can construct needs to do this coding correctly for all cases for all inputs.
>> Speaker 2: You should never tell them what they submitted, it should just say that page isn't found.
>> Douglas Crockford: Right, like another example, this is one that doesn't require a second site on Yahoo.

They used to have profile pages, and on your profile page, there's a box for gender. Being very nice people, they allowed you to type anything you wanted into that box, so it wasn't like you have to pick M or F. They said, whatever you want, that's okay. There were a lot of people who figured out, it starts with an angle bracket, and it's, type a script tag in there.

And so, it means every time anybody looked at your profile page, they can steal your account. There was a similar thing that happened in MySpace. There was a guy named Sammy who figured out MySpace, at that time, was a little bit smarter and had some filters. But, this guy named Sammy figured out how to get around them, and so he injected a script that, whenever anybody looked at his profile page, the script would run and then add him to their Heroes list.

Which is the best spot on the friends list and put that script onto their page as well, and so the number of people who had looked at one of these pages doubled every minute, or, no, every hour or so. In 20 hours, he had control of two million accounts and about that time MySpace went, whoa, what's going on?

And they shut it down, but you can still search out on the Web for Sammy Is My Hero, and you'll probably still find some of these out there.
>> Douglas Crockford: So that's a version of this attack, and Sammy turns out to be a nice guy. I don't know if he's a nice guy, but he recognized, whoops, I didn't expect I'd take over too many accounts in a day, so he'd turn himself in and was charged with a crime.

>> Speaker 2: Probably got a sweet job working in the somewhere White House.
>> Douglas Crockford: Yeah, I'm sure Sammy, I assume he did okay. He could have been a bad guy, right? He could have just kept it to himself and figured out how to exploit these two million people. You also need to worry about concatenation, so the plus sign operator in JavaScript is dangerous.

Depending on how you're using it, because you can be taking bits of string and putting them together, and in some cases, if you're just putting together text, it's not a problem. But, if you're doing something like assembling JSON or assembling HTML, there is a potential for that to go bad.

So, whenever possible, you should be using good encoders and writers and not just trying to plus things together. So, I'm very happy to report that this is no longer apparently a source of insecurity. A manager, when being warned that we need to protect against this would ask, why would anybody do that?

>> Speaker 2: No.
>> Douglas Crockford: We now know why he'll do that.
>> Speaker 2: We still hear that.
>> Douglas Crockford: Do you really? [CROSSTALK] Well, that's a problem.
>> Speaker 2: Yeah.
>> Douglas Crockford: Yeah, we now know why they will do that, they will do that because we can prevent them from doing that. In the case of some companies, those companies will unintentionally pay them to do that, in some cases, maybe pay them really well to do that.

These are things which are not security, which are sometimes thought of as being security. For example, inconvenience, we can't stop them, but we can slow them down. It will put speed bumps on the information superhighway where will stop them. That doesn't work, those things tend to inconvenience you more than them.

It's just, again, if it's not effective, it's not effective and don't waste time on it. Identity is not security. Finding out who someone is doesn't answer the question of, what should they be allowed to do to you? Tainting is sometimes cited as a model of security that doesn't work.

It's a model where you try to track the source of data and how it's transformed over time, and try to determine at what point it becomes tainted or corrupted, but it doesn't work. And then, finally, intrusion detection is not security. There are some system administrators who are so tired of being hacked, and they've given up all hope of stopping it.

They just want to know when it's happening, but that's that's not security. The biggest avoidable source of security, and we'll end here, is mismanagement. It's when a manager says, we're going to get this past the security guys because we've got a deadline. We've got to meet it, we've got to get out there.

I got a bonus on the line. We're going to go, don't let that happen, you gotta kick it up cuz no company can afford to have this kind of stuff going on in their sites, for any possible short-term gain.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now