Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cross-site Scripting Prevention

Posted by michael on from the do-your-part dept.

An anonymous reader writes "Cross-site scripting (XSS) occurs when an attacker introduces malicious scripts to a dynamic form that allows the attacker to capture the private session information. This article casts light on the areas vulnerable to XSS exploitation, explains how the user can protect himself, and details what the webmaster can do to secure a site from this type of malicious intrusion."

2 of 27 comments (clear)

  1. Extremely common by msuzio · · Score: 4, Insightful

    This sort of attack is so common, I think part of any interview for a technical job involving web content (or just plain any sort of system using HTML, including things reusing the IE or Mozilla renderers) should be to analyze a chunk of code and point out where the XSS vulnerability lies...

    I'm what I consider a well-seasoned (and spicy!) web developer, and I've been bitten by this more than once in recent memory myself. It is hard to catch all possible avenues in which data you do not directly control might get interpolated into a web page you render. The latest bug I ran into was is displaying content from a security audit, when I did not realize the content included snippets of Javascript inside it... content that then became part of the page I rendered. Oops, that call to window.close() just got included into the text! It took quite a while to debug this one, because everytime someone went to the page in question, their browser just closed! I thought I had somehow segfaulted both Mozilla and IE until I was able to capture the page using Lynx and look at the content...

    So... the name of the game is to audit,audit,audit. Always ask yourself "Do I know where this data came from? Could it contain markup or scripting? Have I escaped those characters so I know they cannot be interpreted as HTML?". Then I usually turn things over to a colleague and ask him to actively try to subvert the application... that usually catches a few "gotchas" I missed.

    Some people advocate "sanitizing" all data before it is displayed. That is certainly possible, but can be a waste of cycles when it certainly is possible to rule out some data sources as being vulnerable. If I know I sanitize data going *into* my database, then I can probably trust data coming out... but even in that case, only if I know no other malevolent entity can attack that data (and we all know how often hacks occur from the inside...)

    --
    It's a strange world -- let's keep it that way
    1. Re:Extremely common by Anonymous Coward · · Score: 1, Insightful

      Some people advocate "sanitizing" all data before it is displayed. That is certainly possible, but can be a waste of cycles when it certainly is possible to rule out some data sources as being vulnerable.

      So sanitize the untrusted data sources, and don't sanitise the ones you don't need to. The vast majority of web applications are simple enough for their developers to know straight away which ones are untrusted. Unfortunately, the vast majority of web applications are written by people who don't know the first thing about the content model of HTML. Even Orkut was bitten by XSS, you'd expect Google people to have a better grip on things than that.