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."
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.)
Funny, I just happened to come across another article on the same topic here.
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
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.