Cross-site scripting (XSS), is found in Web applications that fail to escape user-submitted content properly before rendering it into HTML. This allows an attacker to insert arbitrary HTML into your Web page, usually in the form of <script> tags. Attackers often use XSS attacks to steal cookie and session information, or to trick users into giving private information to the wrong person (aka phishing). This type of attack can take a number of different forms and has almost infinite permutations, so we\u2019ll just look at a typical example. Consider this extremely simple \u201cHello, World\u201d view:<\/p>\n
def say_hello(request):
\nname = request.GET.get(‘name’, ‘world’)
\nreturn render_to_response(“hello.html”, {“name” : name})<\/p>\n
This view simply reads a name from a GET parameter and passes that name to the hello.html template. We might write a template for this view as follows:<\/p>\n
<h1>Hello, {{ name }}!<\/h1><\/p>\n
So if we accessed http:\/\/example.com\/hello\/name=Jacob, the rendered page would contain this:<\/p>\n
<h1>Hello, Jacob!<\/h1><\/p>\n
But wait \u2014 what happens if we access http:\/\/example.com\/hello\/name=<i>Jacob<\/i>? Then we get this:<\/p>\n
<h1>Hello, <i>Jacob<\/i>!<\/h1><\/p>\n
Of course, an attacker wouldn\u2019t use something as benign as <i> tags; he could include a whole set of HTML that hijacked your page with arbitrary content. This type of attack has been used to trick users into entering data into what looks like their bank\u2019s Web site, but in fact is an XSS-hijacked form that submits their back account information to an attacker.<\/p>\n
The problem gets worse if you store this data in the database and later display it it on your site. For example, MySpace was once found to be vulnerable to an XSS attack of this nature. A user inserted JavaScript into his profile that automatically added him as your friend when you visited his profile page. Within a few days, he had millions of friends. Now, this may sound relatively benign, but keep in mind that this attacker managed to get his code \u2014 not MySpace\u2019s \u2014 running on your computer. This violates the assumed trust that all the code on MySpace is actually written by MySpace. MySpace was extremely lucky that this malicious code didn\u2019t automatically delete viewers\u2019 accounts, change their passwords, flood the site with spam, or any of the other nightmare scenarios this vulnerability unleashes.<\/p>\n
The Solution<\/strong> – The solution is simple: always escape any content that might have come from a user. If we simply rewrite our template as follows:<\/p>\n <h1>Hello, {{ name|escape }}!<\/h1><\/p>\n then we\u2019re no longer vulnerable. You should always use the escape tag (or something equivalent) when displaying user-submitted content on your site.<\/p>\n Why Doesn\u2019t Django Just Do This for You?<\/strong> – Modifying Django to automatically escape all variables displayed in templates is a frequent topic of discussion on the Django developer mailing list.So far, Django\u2019s templates have avoided this behavior because it subtly changes what should be relatively straightforward behavior (displaying variables). It\u2019s a tricky issue and a difficult tradeoff to evaluate. Adding hidden implicit behavior is against Django\u2019s core ideals (and Python\u2019s, for that matter), but security is equally important.<\/p>\n All this is to say, then, that there\u2019s a fair chance Django will grow some form of auto-escaping (or nearly auto-escaping) behavior in the future. It\u2019s a good idea to check the official Django documentation for the latest in Django features; it will always be more up to date than this book, especially the print edition. Even if Django does add this feature, however, you should still be in the habit of asking yourself, at all times, \u201cWhere does this data come from?\u201d No automatic solution will ever protect your site from XSS attacks 100% of the time.<\/p>\n\n\n