Slashdot Mirror
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."
slashcode developers could learn from this, given their track record with XSS vulns:
2 -06-28/2002-07-04/0
http://www.securityfocus.com/archive/1/280218/200
(also provides a good example for people asking "what's an XSS?")
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.
Consensus is good, but informed dictatorship is better
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
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.)
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 "$".
Funny, I just happened to come across another article on the same topic here.
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.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
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?
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
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."
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.