Cross-site Scripting Prevention

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."

hey! cool!

[Anonymous Coward]

slashcode developers could learn from this, given their track record with XSS vulns:

http://www.securityfocus.com/archive/1/280218/2002 -06-28/2002-07-04/0 [securityfocus.com]

(also provides a good example for people asking "what's an XSS?")

site redirects

[stonebeat.org]

hehe.. this reminds of the time, when people used to embed redirects tags like:

<meta HTTP-EQUIV="Refresh" CONTENT="0;URL=http://www.xml-dev.com">

in messages on the online forums. I know Hypernews was vulnerable to this attack.

Extremely common

[msuzio]

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...)

Re:Extremely common

[DukeyToo]

Its not so hard, and the sanitizing/encoding cpu cycles are well worth the trouble - far better than trying to second guess how much you trust data.

From the article "...can occur when:

1. A Web server does not take adequate steps to ensure that the properly encoded pages are generated.
2. An input is not suitably validated."

So, validate/sanitize your inputs, and properly encode your outputs. Its not rocket science.

Re:Extremely common

[Anonymous Coward]

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

Re:Extremely common

[philci52]

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...

Couldn't you just have looked in your web-browser's cache for the most recently modified files?

Re:Extremely common

[LordLucless]

It's easy enough to disable Javascript in Mozilla - just tick-a-box on the Tools->Options screen. Useful for stupid sites that use Javscript for "ultra-secure hi-tech right-click prevention technology".

for cryin out

[Anonymous Coward]

Cross-site scripting (XSS)

Not everything needs a three-letter acronym, guys. Particularly when that acronym is not actually shorter than the thing it's short for. ("Cross-site scripting" and "XSS" have the same number of syllables. One of them carries meaning. The other doesn't.)

It reminds me of "www." Remember "www?" It's the only known acronym in the world to have more syllables than the phrase it's supposed to be short for. ("World wide web." Three syllables. "Doubleyou doubleyou doubleyou." Nine syllables. It's anti-compression.)

Re:for cryin out

[DukeyToo]

<modrequest who="me" direction="up" reason="funnywierd">

ah, but thats why those in the know say it "w-w-w" (sort of a stuttered w).

Of course, most people look at me a bit strange for the second or two it takes them to comprehend. And then there are those that never get it.

</modrequest>

Re:for cryin out

[bellings]

If you're so concerned about time that you can't be bothered to say "dub-dub-dub" (or "weh-weh-weh", or however you think "w-w-w" is stuttered), why don't you just not say "www" at all?

I mean, are there any sites out there configured badly enough to required the www anymore?

Re:for cryin out

[UCRowerG]

yup. you'd be surprised. i've found my share that require it... and a few that require it not be there.

Re:for cryin out

[chris_mahan]

Do it "Eighty-Seven Cube"

It's shorter, doesn't make you sound retarded, and is geekish as hell ;)

Isn't that what we all aspire for?

Re:for cryin out

[agm]

XSS = three syllables. "Cross-site scripting" = four.

I agree with your sentiment of www. It is becoming a fad in the media (at least where I live) to say "dub dub dub", which is strangely annoying.

Re:for cryin out

[__past__]

You do realize that this a written medium? Or is this your way to brag about the leet voice-recognition software you use for /. postings, web articles and e-mail?

By the way, even when you actually pronounce it, XSS has three syllables, cross-site scripting has four.

It could be worse.

[devphil]

When the web was all new and shiny, even to us geeks, we would pronounce the leading part of the URL as "huh-tuppa-wuh-wuh", referring to "http://www."

Fantastic article

[GoRK]

This is a very good article on the subject that does a good job of explaining it from both ends, though it's a little perl heavy for no really good reason -- plus it ignores a lot of better and easier techniques to prevent cross-site scripting problems if you actually are using perl or mod_perl.

There is a problem in Listing 5, though. The article says the script is vulnerable because it blindly prints an input value back to the user; however, it only prints the word "parameter" back to the user and is thus not really vulnerable to anything. Looks like they left out a "$".

Re:Fantastic article

[bill_mcgonigle]

plus it ignores a lot of better and easier techniques to prevent cross-site scripting problems if you actually are using perl or mod_perl.

Well, don't just tease!

While we're making corrections, this bit of the article is incorrect as well, AFAICT:

• He first enters the following into the ID text box: alert('Test').
• He submits the form and then sees this JavaScript alert message: "TO BE DONE."

Now he knows that the site is prone to an XSS-style attack.

One would expect to see the JavaScript alert message "Tes

I'm confused

[El]

Can't you do all the same things via a man-in-the-middle attack, in which case there is NO way for the web site developer to guard against it?

Re:I'm confused

[Carnildo]

Can't you do all the same things via a man-in-the-middle attack, in which case there is NO way for the web site developer to guard against it?

You can, but it's a hell of a lot easier to sneak tainted data into a form than it is to set up a man-in-the-middle attack. Further, XSS can guarantee you information on everyone who views the tainted page, while a MITM attack can't.

Another article

[BeatdownGeek]

Funny, I just happened to come across another article on the same topic here [issadvisor.com].

PHP

[LordLucless]

Now, maybe I don't know enough about XSS vulnerabilites, but PHP provides a function that strips all HTML tags from an incoming string (You can provide an array of exceptions if you like), and I remember having seen somewhere an extension that also strips naughty attributes, like onMouse*.

If you simply pass all form text through these filters, wouldn't that totally get rid of XSS vulns?

Re:PHP

[momokatte]

XSS exploits don't always have to be launched from within the targeted site. There have been XSS vulnerabilities in browsers that enable a script on one domain to trick the visitor's browser into giving privileges for another domain. So a malicious site author could grab login cookies for other sites from its visitors without their knowledge, and use them to compromise user accounts if the cookies don't contain extra security checks (IPs, session IDs, etc.).

More audits of XSS

[ftide]

Hmm from the lack of posts (25 in 24 hours) it seems not enough people are doing their part to shine the light on frequent use of cross site scripting and its abuses. Perhaps that's because still too many coders employ privacy invasive methods in their server-side scripting.

Security is a parallel, interlocking issue if asking, "where does the data come from and where does the data go to?" (props to an old school EE guru and physicist for this saying) because you can have very secure client- and server-side apps but if the methodology of data retention is flawed you could have a password-less system and the privacy would still be just as bad.

I've always disliked heavy use of ECMAScript and cookies while debatable as to whether they're XSS or no they're easy to make as gateways to such things.