XSS Vulnerabilities Reviewed and Re-Classified 142
An anonymous reader writes "Security Analysts at NeoSmart Technologies have revisited the now-famous XSS-type security vulnerabilities and attempted to re-classify their status as a security vulnerability. The argument is that XSS vulnerabilities are not a mark of bad or insecure code but rather a nasty but unavoidable risk that's a part of JavaScript - and that even then, XSS 'vulnerable' sites are no less dangerous or vulnerable at heart." Are they unavoidable, or just a symptom of lazy coding, or both?
Well (Score:5, Funny)
Re:Well (Score:1)
A hole is a hole (Score:5, Insightful)
Re:A hole is a hole (Score:2)
Re:A hole is a hole (Score:2)
Your still young. It takes a few years to appreciate the difference between a quality hole and a not so quality hole...
how many years does it take to learn properly using your/you're?
Re:A hole is a hole (Score:1)
Something about this reminds me of glass houses and stone throwing, but I just can't put my finger on it.
Re:A hole is a hole (Score:2)
Correction:
how many years does it take to learn proper use of your/you're?
Re:A hole is a hole (Score:1)
New correction (including capitalization):
How many years does it take to learn the proper use of "your" and "you're"?
or even:
How many years of learning does it take to properly use "your" and "you're"?
User Content (Score:5, Insightful)
Even disabling Javascript content all together in websites, with user content, other methods can be used to steal cookies/sessions/user credentials. Flash attacks [cgisecurity.com] are becoming more and more common, and are near impossible to protect against. Users demand dynamic user-driven content, the companies comply, I'm just surprised this hasn't been more prevalent.
--Joel
Ajax Translator [parish.ath.cx]
Can't understand (Score:3, Insightful)
Bulletin Boards have been effective against these issues for ages with bbcodes that use [] instead of > < . Also wikipedia has excellent formatting features without letting users ever use an html tag by themselves.
By simply turning >< into ><before displaying content that was influenced by user input you get rid of every single XSS risk. If users complaint about it being too limited they should get their own site instead of depenging on blog/forum/ whatever other thing.
Re:Can't understand (Score:5, Informative)
Rubbish. That's one of the most basic errors made when people start trying to filter out XSS. Suppose you have a form that takes a user's name and then uses it in a hidden field on the next page ? You could quide easily do something like :
UserName" style="background:url(javascript:alert('Getting rid of angled brackets won't help you here'))
Not an angled bracket in there, yet on most systems that'll work and display a popup. Hence the reason it's really not that simple, and the parent post referrs to "an arms race against the latest techniques"
Re:Can't understand (Score:2, Informative)
Include turning & into &. Finally there's ' (') and you're done.
Some languages has functions to do this for you [php.net], you just need to call them.
Re:Can't understand (Score:5, Informative)
The first book to deal with this properly that I ever saw was Innocent Code [thathost.com] by Sverre H. Huseby (ISBN 0-470-85744-7, Wiley).
I recommend this not only to people new to web programming, but also to seasoned programmers. There's more than one time that I've heard people say "pfah, I know the pit traps, I don't need this book", and a few weeks later tell me that there were things there they hadn't thought about.
The book is concise and to the point.
Note: I'm not neutral about this book; I was one of the people who read through the book and commented on it before publishing time, and Sverre is one of my friends.
Re:Can't understand (Score:2)
It's so large that it's best covered in a full-day class at a bare minimum.
I cannot recite the contents of the book, for obvious reasons.
That is why I provided a book recommendation -- a small, reasonably priced book -- and a link to the book's home page, where you can find part of the introduction and an incredibly useful excerpt to the intelligent reader and experienced programmer.
Why am I even bothering with spending time with comments like these o
Re:Can't understand (Score:2)
That you can't be bothered with it, and instead keep repeating your request here, is a waste of my time and yours. Get on with it already.
Re:Can't understand (Score:2)
"Seasoned programmers" have different ideas about what they think is obvious and not. I think many of the rules are relevant, but it depends on the programmer's personality, background and experience battling security issues.
Here's one that's caught a few, and which definitely is something other than y
Re:Avoiding XSS: Escape and... ? (Score:2)
No, I don't think so. You fouled it up at the start.
Yes, you got me riled enough to post that previous entry -- including my ad hominem -- but that's what you got for coming across as an idiot. I don't see anything in your attitude to change that impression, and I expect that this post won't help your impression of me.
Well, I guess that teaches me for trying to be helpful on Slashdot.
Re:Avoiding XSS: Escape and... ? (Score:2)
I don't dislike you personally. I dislike your style, I dislike your methods for "discussion" -- which clearly shows that you have no practical people experience, I dislike your attitude, and I dislike your self-satisfaction at "succeeding" with your low tactics. And still, after complaining that I don't add anything even after I did, you're not contributing yourself; just repeating earlier points. That's what's ticking me off, and that's why you're not getting any further technical res
Re:Avoiding XSS: Escape and... ? (Score:2)
Well, in my experience* with online communication mediums, I've found the opposite to be far less problematic and inflammatory. Usually, experienced communicators will ignore outbursts like yours (and followups like mine), while some people do indeed feel provoked to answer. However, those are hardly representative for the constructive responses.
What arms race? (Score:2)
Basically if there's an "arms race", then escaping quotes isn't much of a part of it. The problem was know
Re:Can't understand (Score:5, Informative)
As someone else has pointed out, that's a naïve and incorrect approach.
HTML is a standard. BBcode is a whim. HTML wins for its ubiquity. BBcode gives you nothing.
People that don't think they can effectively and safely include HTML content from untrusted sources are not viewing the problem in a formal way. Address the cause, not the symptom.
The cause is not thinking of and treating your HTML input as structured data. Rather, you're thinking of it as a character stream. Textual substitutions are a sign of that line of thought.
Your user's HTML content is a tree structure. Parse it. Then filter out all elements that are not in your allowed-elements list. Filter out all element attributes that are not in your allowed-attributes lists. Construct these lists by examining the HTML specification and considering the risks of each element or attribute.
Take it a step further. For each attribute value that contains a URI, parse that URI using a formal grammar. Filter out all URI schemes ("http", "ftp", etc) that are not in your allowed-schemes list. Certain characters, like non-printables, should never occur in a URI directly—signal an exception to the user to inform them of their error. Don't just stop if you don't find anything wrong! Reconstruct the URI from its constituent parts and replace the original with your sanitized version.
Likewise, formally parse all CSS code: in referenced external stylesheets, embedded stylesheets, and in style attributes. Filter out anything not explicitly allowed. Replace any URIs with the output of the same URI-sanitization function above. Reserialize the content. (This is hard; drop all CSS as a short-cut.)
When you're done, you'll serialize the HTML document and transmit that to your clients. I guarantee that this will eliminate XSS problems stemming from Internet Explorer incorrectly interpreting malformed HTML, CSS, or URIs. There are other attack vectors; be careful of what you allow to be included inline with documents, or linked to. (Think Flash.)
This is the correct solution, and most flexible to your users. It's not another idiosyncratic language to learn. It's the world standard for rich textual documents on the World Wide Web.
Unfortunately, it requires work.
Crazy (Score:5, Insightful)
Er, no. XSS attacks are caused by sloppy web application developers that fail to encode user-supplied data for output in the appropriate way, and by sloppy web developers that trust that whatever was submitted by a user was submitted by the user intentionally.
Both of these factors have technical solutions that are 100% effective and have been well-known for years. The former has nothing specifically to do with JavaScript anyway, it's just that the holes are most often used to sneak JavaScript onto a page.
This article is a total crock of shit. For instance when it says:
It's no more dangerous in terms of security for the client machine. If Hotmail has a security hole, it doesn't make it more likely that somebody will get onto your computer. But they can still read and delete your email, and send email from your account.
Actually, I take that back, it is more dangerous in terms of security for the client machine. With tools like the NoScript Firefox extension, and the similar mechanisms other browsers have, many people disable JavaScript for the random websites found with Google, but enable them for websites they trust, like Hotmail. So if Hotmail has an XSS vulnerability, they will be executing malicious JavaScript even though they only intended to allow trusted JavaScript to be executed.
This author seems to have no real clue about web security. I guess this is why Slashdot shouldn't link to random weblog entries.
Re:Crazy (Score:2)
I'd second this post, a forum I lurk on had a major XSS issue a few years ago: flash uploads were allowed and a user found a way for his scripts to call home: he had the ability to embed flash on a page, then every time the flash'd display it'd phone home and send him the login informations/cookies of the user who'd displayed the flash.
Long story short, he gave himself supadmin rights as a proof of concept and then told of the vulnerability to the dev of the forum software.
He could just as well have destr
Re:Crazy (Score:2)
That's how XSS happens. But why does it happen?
Because the website accepts raw HTML of some kind. And with raw HTML comes JavaScript. Forget about filtering it perfectly. Yahoo has tried for years on end and still the occasional JavaScript injection issue pops
Re:Crazy (Score:2)
Re:Crazy (Score:2)
Nobody said it was perfect. The first rule is to be paranoid. And yes, issues may always appear, but it would be with something you control. Not with something controlled by anybody out there, which expands the possibilities for mischief 1000-fold.
XSS - a bug... sometimes (Score:4, Insightful)
Re:XSS - a bug... sometimes (Score:1)
So if someone visits a link to www.arin.net in good faith that it is a trusted website that wouldn't try to break into your machine, what happens when an XSS vulnerability on www.arin.net allows an attacker to redirect to a malicious site that harbours a remote exploit for Firefox, for example? I wouldn't call that "doesn't do anything or represent a risk".
Re:XSS - a bug... sometimes (Score:1)
Re:XSS - a bug... sometimes (Score:2)
SQL injection is easy to prevent. Pass input though an escaping function or use parametrized queries.
Re:XSS - a bug... sometimes (Score:1, Informative)
Re:XSS - a bug... sometimes (Score:2)
This is made alot more difficult with unicode/multibyte input however.
Re:XSS - a bug... sometimes (Score:4, Interesting)
Uh? SQL Injection is trivial to prevent, just escape your user-provided content (most languages do it automagically for you if you use prepared statements btw, and by "most languages" I mean to say "just about every language but PHP before mysqli_ and PDO")
XSS, on the other hand, relies as much in your lack of escaping as in browser-specific "features" such as the ability of MSIE to execute arbitrary Javascript code embedded in CSS.
XSS is much harder to prevent than SQL Injection.
Which does not mean that it should ever be classified as "unavoidable" (it's not) or less dangerous than SQLI (it can, in fact, be much worse)
Re:XSS - a bug... sometimes (Score:1)
Not to stop your PHP bashing, but I use http://www.php.net/manual/en/function.pg-query-par ams.php/ [php.net] also.
Re:XSS - a bug... sometimes (Score:2)
Re:XSS - a bug... sometimes (Score:2)
So is XSS. Just escape all HTML in user-provided content. Ah, but you don't want that, do you? You want your bold and italic tags. Would SQL injection still be trivial to prevent if you didn't escape it altogether and wanted for "some" SQL to pass through and some not?
Re:XSS - a bug... sometimes (Score:2)
I'm sorry, but if a developer is aware of this IE bug^H^H^Hfeature, then why can't he properly validate and encode tainted input in much the same way? Any arbitrary text will not execute from CSS, only JavaScript code will execute. And not only any JavaScript code, but code that is properly embedded for it to be recogniz
Re:XSS - a bug... sometimes (Score:2)
There's no reason to allow a user to inject their own CSS code into site content.
Filter out all style definitions from user-provided content before sending it to the client for rendering.
Better yet, use a whitelist approach. If you're going to display the user's name, don't accept anything other than letters and whitespace. If yo
Yes, unavoidable. (Score:4, Informative)
JMP 64738 (system reset) was the unavoidable result. The next version of the software recognized that the functionality could not be secured and removed it.
Re:Yes, unavoidable. (Score:4, Informative)
In your example, the BBS was expecting code. It couldn't verify which code was good, and which code was bad, so it created an insecurity. On a website, the site expects textual content. It doesn't expect code. As long as you escape all user input properly, there's no chance of an XSS vulnerability. If you setup a website that allowed random users to upload javascript to be run on the site (rather than simply display the code as content) then that would be analogous to your BBS situation.
Re:Yes, unavoidable. (Score:4, Interesting)
Nevertheless, many of the fundamentals were similar:
1. The client (terminal emulator) allowed the server (BBS) to download and run code.
2. A BBS expecting a post (text message) received machine code from a user instead.
3. The BBS sent that code to the next viewer expecting a text message.
4. The viewer performed undesired and unauthorized actions as a result.
The biggest difference is that today's crop of programmers keep insisting they'll find a way to secure the scripting functionality while I gave it up for bad right away.
Re:Yes, unavoidable. (Score:2)
With the BBS situation, you created a tool that allowed people to distribute executable code via BBS. The BBS was designed for content, not executable code. Allowing it to distribute code made it insecure.
These websites are designed for distributing content, the same as your bog-standard BBS. People upload content, website displays it. All that is needed to secure it, is to get it to treat code as text, rather than as code. In terms of HTML, that's easy. Just run a
Re:Yes, unavoidable. (Score:3, Informative)
Yeah, I got that. The same argument could have been made about my software: all BBSes could have been programmed to recognize the text escape sequences th
Re:Yes, unavoidable. (Score:2)
I'd say it did make the BBSes insecure. The BBSes were vulnerable to an attack made by a malicious user. That attack may not have been in sufficiently common usage to make it a concern, but it is a flaw. Writing an online application, and expecting users to "just behave" is naieve to the extreme today. Never trust that the user will give you
Re:Yes, unavoidable. (Score:2)
Ho ho ho. And where did your software live? On the BBS. The problem was that your software had a classical security flaw: code injection. No matter what the code was. The software had a hole and in my book that makes the server it runs on "bad", as in "does bad things to users". So while the server itself wouldn't be compromised, was it desirab
Re:Yes, unavoidable. (Score:2)
Incorrect. I believe I made it very clear that my software was the client-side terminal emulator. It required and used no special software on the server/BBS side. Like Javascript, it was intentionally designed to do all its work on the client-side so that no change was needed on the BBS.
Browsers are meant to run JavaScript.
And my terminal emulator was meant to run machine code. So what? Since when is it the server's responsibility to accomodate client-side featu
Re:Yes, unavoidable. (Score:2)
The article's point (and its a good one) is that a web server's failure to implement an optional feature should never be able to open a security hole in a web browser. If it does, that's the browser's fault.
Re:Yes, unavoidable. (Score:1)
That’s true, but unfortunately it’s not as simple as that—most web-based bulletin-board software wants to allow the user to use lots of emphasis . I agree that it’s still not very hard to secure—but it’s easy to see how people get it wrong...
Re:Yes, unavoidable. (Score:2)
Re:Yes, unavoidable. (Score:2)
Define "escape all user input properly"
Re:Yes, unavoidable. (Score:2)
Re:Yes, unavoidable. (Score:2)
only allow generation of html that you know is sane, DO NOT let anything unrecognised go through.
if your just interested in text you can do this as a simple replace operation, < becomes <, & becomes &
if you wan't to offer formatting you have to parse the input and generate known safe html from it. You must also use appropriate sanitisation methods (e.g. make sure users can't embed extra quotes in a quote deliminated string) for anything you pass f
My take on this sort of thing (Score:5, Interesting)
That quote really says it all. The basic argument seems to be very simple: Javascript Sucks, Ergo XSS Vulnerabilities are inevitable. That's about as accurate as saying that if Chewbacca lives on Endor, you must acquit.
As someone who's had to wrangle plenty of Javascript, I agree that it sucks, but I disagree with any argument that security vulnerabilities are inevitable. These days, they seem to be more a product of adding features without thinking about the security implications (Hey, let's allow email viewed in Outlook to run scripts!) than poor implementations of those ideas. Although implementation problems play a part: You're busy coding the nifty new feature, you get to a point where it works, and you happily go and check it into CVS oblivious to the buffer overflow you've introduced.
Fundamentally, there's no such thing as a computer error, only a series of human errors buried deeply enough that they appear to be a computer error (with one exception, that of the expected hardware failure).
Re:My take on this sort of thing (Score:2)
As someone who's had to wrangle plenty of Javascript, I agree that it sucks, but I disagree with any argument that security vulnerabilities are inevitable. These days, they seem to be more a product of adding features without thinking about the security implications (Hey, let's allow email viewed in Outlook to run scripts!) than poor implementations of those ideas. Although implementation problems play a part: You're busy coding the nifty new feature, you get to a point where it works, and you happily go a
Re:My take on this sort of thing (Score:2)
Javascript is a loosely-typed language designed without security considerations in mind.
There are clear security considerations in the design of Javascript, eg. domain restrictions, file system restrictions and DOM restrictions.
Ironically, true Java applets prevent the very problems that Javascript/AJAX engender.
While I do have a high opinion of "true" Java, I find "true" Javascript acting on the HTML DOM is a far more suitable tool to develop web applications with. Different tools for different
Re:My take on this sort of thing (Score:2)
The problem with Java applets (as far as I'm aware) is they don't integrate smoothly into the DOM, play nicely with stylesheets and can't be extended as easily to access
First language (Score:5, Insightful)
I wouldn't say lazy, but naive. Lots of people now cut their teeth at programming with HTML/Javascript and a simple server-side scripting language, like PHP or ASP. For a reason unknown, these simple languages (PHP especially [develix.com]) try to create a blanket so thick around the coder that most of them don't even think about validating input.
Crap like auto-string escaping, crap like automagic global variables, crap like easy access to eval(), auto variable casting, these help when learning to program so you can concentrate on the task at hand, but become a big fat no-no when deploying stuff in a networked environment.
Going back to my first programs in BASIC/C/C++, they were probably filled with holes; but for sure they weren't available for the world to hack.
Re:First language (Score:1)
Let your work free! I even publish all my grocery lists under a Creative Commons license for all to enjoy! Because
Re:First language (Score:2)
This guy doesn't know what he is talking about! (Score:4, Informative)
XSS is a real security threat.
Re:This guy doesn't know what he is talking about! (Score:2)
"...A major one."
Re:This guy doesn't know what he is talking about! (Score:3, Insightful)
I don't feel particulay sorry for fools who fall for phishing scams
I sure wouldn't want to bank with a company that called its customers fools when the phishing scam was being run from the bank's own website.
They are flat wrong (Score:5, Insightful)
Re:They are flat wrong (Score:2)
Re:They are flat wrong (Score:1)
Is it just me (Score:1, Interesting)
Not me! (Score:2, Funny)
XSS is made of people! (Score:3, Interesting)
Both, in different amounts depending on which scripting language you use.
It's impossible to write perfect software - not even NASA can do that.
On the other hand the languages aren't much help. PHP for instance allows you do to stupid things with user input variables. Depending on how your scripts work, you can see no errors for months and then all of a sudden half your database or site gets deleted. Great fun, that.
Re:XSS is made of people! (Score:2)
While it's not impossible to write a given piece of software that's bug-free, it is impossible to know that it's bug-free. You may suspect it, or perhaps even believe it, but you can never know it. Formal software provers can demonstrate that a piece of software obeys a theorem, but it doesn't demonstrate that the theorem is correct (i.e. that it proves what you think it proves). It just moves the task of bughunting one abstraction higher.
Unavoidable? (Score:3, Informative)
As far as the seriousness of XSS, I think the author is heavily downplaying the issue. With the xmlhttprequest it is easier than ever to use XSS to hijack users' sessions. For example, in a messageboard post or something I could put a simple script that uses an xmlhttprequest object to send the user's cookies with the session id to a remote script. The script can then immediatly hijack the user's session and steal information or whatnot, before the user even navigates to a different page.
Script tags isn't enough. (Score:4, Interesting)
If I recall correctly, samy exploited MySpace (there's a link somewhere above if you never heard about it) by taking advantage of the fact that IE6 will execute Javascript: urls in CSS url() attributes (IE something like this:
background-image: url(javascript:codehere
Something like that at least. And of couse if you allow HTML tags with attributes anyone could stick a style="" on it and inject some javascript... in theory anyways.
I read somewhere, and I agree, that the best solution is to strip ALL HTML and use your own tag set (most web forums are way ahead in this department). If you do insist on allowing a subset of HTML, use whitelists to define allowed tags and attributes etc, instead of blacklists... because with a whitelist, if you leave something out, oh well someone can't use a tag they should be able to, it's more restrictive than it should be, they file a bug report and it's fixed. With a blacklist if you leave something out, it's a potential security hole.
Re:Script tags isn't enough. (Score:3, Informative)
First I made a css class called test in a seperate
background-image: url('javascript:window.location=\'http://www.goog l e.com\'')
Then I just made a simple html page with a div tag of that class. When I navigated to the page, it al
Re:Script tags isn't enough. (Score:3, Informative)
you may want to check Samy's hack of Myspace [namb.la]
While he didn't use it for anything really detrimental, he more than likely could have, especially when you see the bunch of code he managed to cram in.
Re:Script tags isn't enough. (Score:1)
XSS has always been bullshit (Score:3, Insightful)
Huh? (Score:3, Insightful)
Maybe the people writing web apps need better training? No matter how safe you make the language, there will be people using it who are inexperienced, unfamiliar, or otherwise uneducated about the nuances of paranoid programming. It's very narrow-sighted to blame the tool.
Really? (Score:5, Interesting)
CitiBank Exploit [citibank.com]
Re:Really? (Score:1)
Can make it work with https?
Most at risk (Score:2, Insightful)
Banks & things like that are insured against loss, Federally in the case of banks.
Advertisers who pay for people to click things on the other hand, are not.
I'd bet CowboyNeals left nut there's thousands of dollars a day being scammed from advertisers through the use of XSS clicking adverts in the background, or changing the target address of an add banner.
I don't think so. (Score:1)
Complete Twit (Score:1, Insightful)
Probably a 15 year old kid. Its a fucking wordpress site w/ the default theme. I mean, come on, seriously.
Silly and obnoxious (Score:2)
This guy is asking for Bruce Schneier's liability (Score:2)
That s
The Cross Site Scripting Faq (Score:3, Informative)
The Cross Site Scripting FAQ [cgisecurity.com]
Idiots (Score:1)
Unavoidable? I don't know ASP, for example, and when I was using it for the first time and had a user variable which was displayed as HTML, 2 minutes of Googling led me to HTMLEncode(). Problem solved, for the most part. A real programmer can accomplish this in any language, with a regex or whatever.
Whoever wrote this obviously
Neowin: Lazy or Naive? (Score:3, Interesting)
http://neosmart.net/blog/index.php?s=%3Cbr+%2F%3E
Note: if you are actually a member, please do not input your password. This is merely an XSS trick demonstrating a total lack of vulberability, sloppy coding or naivety on the part of neosmart.
Re:Neowin: Lazy or Naive? (Score:1)
What the hell is Cross Site Scripting? (Score:1)
After reading the linked article, you probably don't know what XSS is unless you knew going in. Here's a link to a FAQ on XSS. http://www.cgisecurity.com/articles/xss-faq.shtml [cgisecurity.com].
As for the article. My impression is that it is not very well written. I don't know enough about XSS to be sure, but for the most part I don't think it is a very accurate assessment. It appears to me that XSS attacks most certainly are a security issue and are by no means limited to Javas
"XSS is another one of those buzzwords (Score:5, Funny)
But that isn't the best bit:
"Sites with XSS "vulnerabilities" aren't insecure. They're absoloutely no different than any other site - except that a user can manipulate the way content displays on an "insecure" page"
Thats like saying 'Pearl Harbour wasn't "vunerable". It was absolutely no different than any other naval base - except that the Japanese could drop bombs on it'
XSS prevention in web browser? (Score:2, Informative)
NoMoXSS (no more XSS)
http://www.seclab.tuwien.ac.at/projects/jstaint/ [tuwien.ac.at]
Although it is only a prototype of an implementation (in a rather old version of firefox), it shows the potential of this solution to stop XSS attacks.
Our Tools Suck (Score:2)
gets escaped, whilst this does not.
The question remains
Can we mod the article (Score:1)
I like JavaScript! (Score:3, Funny)
I was always prejudiced against JavaScript but a couple of years ago I was stuck with a problem which could only be done in JavaScript (The selections in the second emnu depended on you choice in the first menu, all other checkboxes and menus depended on the second menu selection) or with about 50 static pages.
I actually came to like it its actually a very clean and consistent programing language albeit with very few builtin features. After a couple of days the only times I ever felt the need to RTFM was for the exact names of the various bits of the web browsers DOM structure.
How anyone could recomend VB over javascript is beyond me, and, I note no one has suggested the return of the Java Applet!
As for buggy, well there are javascripts with bugs in but there are very, very few bugs in the ECMAscript implementations I have dealt with.
horror (Score:2)
When I pointed out that users could enter javascript as a user name to be displayed to other users, they didn't care, the response was "Why would anyone want to hack a website?".
The last website this company produced before then was for a major gaming company that produced a VERY popular collectable card game and had bought out another company that made a paper RPG game fea
Re:How about some XSS abuse at interpol (Score:1)
Re:How about some XSS abuse at interpol (Score:1)
Does that include the one in your signature?
Re:How about some XSS abuse at interpol (Score:1)
Re:Pardon Me? (Score:3, Informative)
Re:Don't allow the GET method except for index... (Score:3, Insightful)
Re:another TLA starting with X? (Score:3, Funny)