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

The "Cross Site Scripting" 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:

Cross site scripting attacks (XSS) were invented in 1995. Doug looks at some of the security steps that have been put in place to protect against XSS but stresses browsers are still insecure by default. He also analyzes what causes XSS vulnerabilities and why they still exist.


Transcript from the "Cross Site Scripting" Lesson

>> [MUSIC]

>> Douglas Crockford: So this attack which I just outlined is called the XSS attack, which stands for cross site scripting. Now it should be called CSS. But there was another abomination called CSS. So they call it XSS but the name is a problem. The name says that there's something wrong with cross-sitescripting but in fact that is a highly desirable thing.

We want to be able to have sites cooperate with each other and businesses and services cooperate with each other which might be located on different sites. That's a desirable thing, it's not a bad thing. And there are forms of this attack which do not require the use of a second site.

So the name is just completely wrong but the security experts who first identified this attack did not understand what this attack was. They gave an incorrect name but the security industry is still operating on that name, and they're expecting you as practitioners to understand what they're meaning when their language is incorrect.

Cross site scripting attacks were invented in 1995 when JavaScript was first released and they've been going on ever since. We're just now on the 20th anniversary of cross site scripting attacks. So, we have made some baby steps. For example, there's a content security policy thing that's in browsers now.

It took a long time to get it out but it's out there. Unfortunately most sites aren't using it. So it's still unsafe by default. And in fact, in order to use it, it means that a lot of common practices now become illegal, as they should. But because they're common practices, it's not gonna get used.

A mashup is a self-inflicted XSS attack, and it turns out advertising is a mashup, and the most reliable cost effective method to inject evil code is to buy an ad.
>> Douglas Crockford: So why is there XSS? So when things go wrong at an architectural level, it's never just one thing.

You need a lot of things to go wrong simultaneously. And that happened on the Web. The first one is that the web stack is too complicated. There are too many languages, each with its own encoding, quoting, commenting and escapement conventions that can all be nested inside of each other.

I've called this the turducken problem. It's very difficult to look at a piece of code and determine that it's going to be benign in all contexts. That's a very hard analysis to do.. And it's made even worse because browsers do heroic things to try to make sense out of malformed content.

In fact HTML5 began as an attempt to standardize the terrible stupid things that browsers do to try to make sense of invalid HTML. Then that's compounded with the popularity of template-based web frameworks that are optimized for XSS injection. I hate templating, we'll talk more about those later. And then finally the JavaScript global object gives every scrap of script the same powerful capabilities.

And yet as bad as it is at security, the browser is still a vast improvement over everything else. So the problem is not a cross site scripting attack. It is a confusion of interests. The browser distinguishes between the interests of the user and of the site, but it did not anticipate that there might be other interests involved.

And that's where it fails. So within a page interests are confused. So an ad, a widget, an AJAX library, an analytics library, anything that gets loaded from a third party, all of that code gets exactly the same rights as you do. It means you are trusting everybody in all of those other institutions.

Now JavaScript gets close to getting it right and I think JavaScript can be repaired and become an object capability language, we'll talk more about what that means. HTML, I don't have any hope that we're ever gonna fix HTML and the DOM which is that hideous API that HTML uses, is horribly insecure.

I don't see that going away either. So this stuff is not gonna get fixed in a hurry. So it's up to web developers to create secure applications on an insecure platform and that is really, really hard. It shouldn't have to be that hard but it is that hard.

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