Slashdot Mirror
The Anatomy of Cross Site Scripting
LogError writes "Many documents discuss the actual insertion of HTML into a vulnerable script, but stop short of explaining the full ramifications of what can be done with a successful XSS attack. While this is adequate for prevention, the exact impact of cross site scripting attacks has not been fully appreciated. This paper will explore those possibilities."
Cross-site scripting vulnerabilities are just not as exciting as your standard buffer overflow. There are no crashes, no worms, etc. Unfortunately people are just not going to pay attention.
Life in Orange County
Asp.Net protects users from XSS by default since version 1.1 by parsing the parameters of a page and looking for javascript/html code in the query. :)
Of course I was bitten by this feature when upgrading from 1.0 to 1.1, but that's just because I didn't bother reading the readme.txt
Automatic protection bundled with any application server is good, especially if you can turn it off [you can in asp.net , validateRequest=false et voila].
The generall tecnhique described above is with
volnerable scripts which display text which came
from URL encoded data, This is one of many methods
to display the attackers HTML in an unsuspecting
users browser.
It is very common for the 404 message on a website to contain the URL which was entered, In the past this was done mostly by copying it as is. This would allow an attack.
In order to hide the attack hex encoding is used in the URL so the victim would not notice the script in the URL.
Still the attacker needs to minimize the length of the URL this causes him to use HTML options
such as iframe in order to insert a lot of HTML
taken from a diffrent site.
The main point of intrest is that the page appears to be comming from the (probably trusted) server, this can convince the user to do stuff he may not do on the attackers web site, say for example enter credit card info.
Also one could collect cookies this way, the cookies are likely to contain passwords or equivelent informations for sites with user login.
In some forums a user can put scripts in his signature or profile, this allows similar results,
but with out sending funny URLs.
DO NOT TRUST USER INPUT, it may harm not only you
but also the user, they must be protected.
Me.
Take note of escapeHTML() in the CGI module. Use that on the form input that you save into a database, and that should cut down on most of the XSS problem. It's quite humiliating for a webmaster to have a guestbook get trashed by a load of img tags and evil links to offending sites (although I see a lot of Slashdotters abusing the the URL feature this way).
--
hecubas
Hecubas
Going back a good few years I remember finding one of the first sites to allow online shopping. Unbelievable as it might now seem they actually passed the id and the PRICE of the item you were attempting to purchase via the GET method in a query string! I remember having fun changing all the prices to negative numbers, and seeing the total come to around - $1,000,000. Of course I never had the balls to enter my credit card number and see if they would bill it for a negative amount :)
The English letter X has the same shape as the Greek letter chi, which has the English sound "kh" or "ch". Chi is also the first letter of the Greek word Khristos, meaning Christ. So "X" became an abbreviation for "Christ".
The fish thing is from the Greek word "Ikhthus" {iota, chi, theta, upsilon, sigma} meaning "fish" but also forming an acronym of the Greek words which translate as "Jesus Christ, Son of God, Saviour". The early Christians, forced to meet in secrecy, identified themselves to one another by the sign of the fish <><. This is still used today by Christians, and can be seen outside businesses, homes and on the bumpers of cars - so the rest of us know who to avoid.
Je fume. Tu fumes. Nous fûmes!
I always type too fast and leave important things out, so here's a little more:
1) I meant "HTML Encode anything that will end up in HTML output again."
2) I didn't bother talking about SQL insertion, that's a different gremlin from XSS.
3) I didn't implement the things I said were stupid to do... I avoided them for that particular reason. I'm saying that there are traps to avoid, such as evaluating the contents of inputted variables. Some ways of implementing template toolkits will have you build a large string to create a page, and use variable substitution on that by eval-ing it at run time. If you concatenate user text before the eval, bad things could happen.
Design for Use, not Construction!