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."
The Anatomy of Cross Site Scripting
Anatomy, Discovery, Attack, Exploitation
by Gavin Zuchlinski (gav@libox.net )
http://libox.net/
November 5, 2003
Introduction
Cross site scripting (XSS) flaws are a relatively common issue in web
application security, but they are still extremely lethal. They are
unique in that, rather than attacking a server directly, they use a
vulnerable server as a vector to attack a client. This can lead to
extreme difficulty in tracing attackers, especially when requests are
not fully logged (such as POST requests). 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.
Anatomy of a Cross Site Scripting Attack
A cross site scripting attack is typically done with a specially crafted
URI that an attacker provides to their victim. The XSS attack could be
considered analogous to a buffer overflow, where the injected script is
similar to overwriting an EIP. In both techniques, there are two options
once a successful attack has occurred: insert funny data or jump to
another location. Insertion of funny data during a buffer overflow
typically results in a denial of service attack. In the case of a XSS
attack, it allows the attacker to display arbitrary information, and
suppress the display of the original webpage. When jumping to
another location during a buffer overflow attack, the new location is
another location in memory where shellcode or other important data
resides - allowing the attacker to take control of the flow of the
program. Within the XSS context, the attacker instead jumps the
victim to another location on the Internet (typically under the
attacker's control), hijacking the victim's web browsing session.
Discovery
But how do cross site scripting attacks occur? XSS attacks are the
result of flaws in server- side web applications and are rooted in user
input which is not properly sanitized for HTML characters. If the
attacker can insert arbitrary HTML then they could control execution of
the page under permissions of the site. A simple page vulnerable to
cross site scripting looks like:
Once the page is accessed, the variable sent via the GET method is
placed directly on the rendered page. Since the input is not marked as
variable input , the user- supplied input is interpreted exactly as its
metacharacters command, very similar to SQL injection. Passing
"Gavin Zuchlinski" as an argument outputs the content in correct form:
Sending input with HTML metacharacters allows for unexpected output:
The input is not validated by the script before rendering by the victim's
web browser. This allows for user controlled HTML to be inserted on to
the vulnerable page. Occasionally user input not directly parsed by the
script it is sent to. Rather, the data is inserted into a file or database
and retrieved later to be reinserted on the page.
Common points where cross site scripting exists are confirmation
pages (such as search engines which echo back user input in the event
of a search) and error pages that help the user by filling in parts of the
form which were correct. Commonly in the latter case (and sometimes
the former) the containment of the form text box must be escaped
with a quote and a greater than sign ("> - the quote closes the value
property and the greater than closes the tag).
Attack
Once a vulnerable input is identified the valid HTTP methods must be
determined. The way in which the variables are sent to the target
script is an important consideration; are variables sent by GET, POST,
or will either work? Some scripts are specific, but several which use
canned methods (like PHP and Perl scr
Why is Cross Site Scripting XSS? Or have we reverted to referring to letters by the way they look?
Static webpages aren't vunerable to this kind of attack. Yay!
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
Cross Site Scripting attack protection is a standard feature of many network security products these days. Check Point NG with Application Intelligence (Feature Pack 4 in other words) includes XSS protection as part of its' so-called SmartDefense. I am curious if anyone has run into situations where SmartDefense is screwing up legitimate traffic, especially traffic that resembles an XSS attack.
BTW, does anybody have some good recommendations for cheaper alternatives with pretty comparable protection to Check Point? I would like something that is as defensive, but not as configurable or extensible.
In principio erat Verbum.
Post some personal information and I am sure someone will show you how it is done.
Do not have a blacklist for denying invalid input. It's hell/impossible to maintain such blacklists
Handle all user input as it was written by satan himself, and only allow input complying to your strict specification.
Supposing that the above hello.php was on the same domain as a message board, posting the link to the board would illicit many victims.
That's 'elicit', not 'illicit'.
I'm surprised this merited a news item.
Webmonkey had a similar article three and a half years ago, that provide some more solid examples of what happens.
I designed an e-commerce site over the last six years, and evaluated where there might be XSS vulnerabilities. Not having a bulletin board or guestbook removes many areas for exploitation.
So if someone types contaminated data into their address field when checking out, you'd think all it hoses is their own purchase, right?
Well, with PHP or Perl CGI, it's possible that the inputted variables could exploit server knowledge: if you know the variable names used in the PHP code for, say, the MySQL password, then embedding this in the input to be evaluated on output can open an avenue for hacking. The variable has to be evaluated in most cases, although code which generates new PHP pages could result in similar problems.
HTML encode EVERYTHING the user sends to you.
Design for Use, not Construction!
have we reverted to referring to letters by the way they look?
Why yes.
You ever notice that "C" stands for "Cookie"?
It's good enough for me.
Now find me some Crescent shaped cookies.
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
I was hoping for some enlightened progression into the interesting-for-some field of cross-siting, but am sorely disappointed at this basic-tut-in-PDF-clothing. Most people don't really discuss much when it comes to XSS as there isn't much to discuss. Well, maybe there is, but this paper doesn't highlight anything new or adventurous, just what any sentient techie could work out in 5 minutes of thought. Quite why it deserves so much attention (I've been meaning to check it out for a few days now...) is way beyond me. Pretty much everything in this "paper" was realised as soon as the first XSS attack was made. Ask Hotmail.
However, I suspect that there is some really interesting stuff that can be done involving cookies, plus I've also been trying to figure out site-wide ways to prevent cookie stealing (cookies across domains, progressive cookies, challenge-response methods...) but if anyone has any links to further research on this, I'd be grateful. There are some very interesting, more social, less technical ramifications as well as it begins to merge with ID theft and similar ilks.
If web services get big, really big, then such basic authentication for sessions may have to be addressed. At the moment, we're probably lucky to get away with just having our blogs taken over (though a few too many of them, and we may say differently...)
Although it is PHP-specific, this free article explains XSS and CSRF in quite a bit of detail and might be useful for Web developers using any language:
http://www.phparch.com/sample.php?mid=16
Enjoy
Cross site scripting (XSS) flaws are a relatively common issue in web application security, but they are still extremely lethal
You better believe it. Why only last week I had one of my web developers executed for writing code vunerable to a Cross Scripting Attack. I dont want any slackers on my team.
PS I now have an opening for an experienced web developer. Sent resumes to spareme@icodetolive.com
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
I have a hour long lunch break because it's Friday, so I'm desperately searching for some Jessica Lynch slash fiction. I don't care if it's patriotic "iraqi assrape" or the much more likely "West Virgina hillbilly hosemonster bivouaced in the desert for six weeks with eight black bucks". plz help!
I'm trying to figure out how to use cookies from others computers on mine to acccess sites they use that have a "save my password" feature.
Right now the copied cookie is ignored by the web site.
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].
this almost looks like a variation of a doss attack. in the sense that a set of clients repeatedly communicates to the 'attack site'.
one could do this by creating a simple thread that constantly loops and sending the same request over and over again. both client, and server would then shut down. this is also traceable from the server's request loggin software. an administrator that gets the same request more than lets say, 5 times? should label that i.p. address as 'hostile'. and ignore it for lets say 12 months? i say this because some sites use 3 monthes as a rule. on request 5, send back a reply that says 'give us a call'. because sometimes, users 'just don't get it'.
This site found out about the lesser known cross site script problem, the a href= tag, in particular, the a href tag that happens to be posted on slashdot! another victim to the effect.
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.
I think it would be possible to design a self-propagating exploit, that would "infect" user sessions and then use those sessions to "infect" more vulnerable pages, which leads to more infected sessions, and so on. If the attack script was be compatible with the browser the site administrator is running, you would gain root access at some point.
In a week we'll see their new paper, The Anatomy of Distributed Denial of Service.
Seriously, the only problem is that of control structures. Most tags don't change the flow, or make data modifications, they'll simply set the style (eg: the bold and italic tags) or inject characters (eg: the paragraph tag).
However, if you want to be safe, simply don't allow any HTML in a page, and require users to format in TeX.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
"That which is not explicitly permitted is denied." That is, whitelists rather than blacklists.
Of course, you should also familiarize yourself with the mechanisms your language of choice has to help defend against such attacks. In PHP, this means register_globals = off, and there are also freely available input validation functions designed with XSS in mind.
I like to maks sure that as many of my forms use POST as possible, and include code at the top to halt processing if anyone attempts to pass a PHP page more GET arguments than it is supposed to have (ideally zero, but sometimes GET is useful.)
WMBC freeform/independent online radio.
I've been working on a personal website for the last month and a half, and had this happen. Not to any degree of maliciousness, but it did screw with PHP.
My expirence with XSS was due to my lazy programming. I didn't filter user content before it was displayed. Someone posted guestbook content with malformed PHP commands. Luckly they didn't know PHP that well, and an error was returned.
As far as PHP goes, functions like str_replace(), and striptags() should be used to parse all user-inputed data before it is displayed. I'm sure other serverside scripting languages have similar functions.
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 :)
Anonymous Coward writes "Many websites discuss the actual insertion of a link to their site into Slashdot's homepage, but stop short of explaining the full ramifications of what can be done with a successful XS/. attack. While this is adequate for prevention, the exact impact of cross site scripting slashdotting has not been fully appreciated. This paper will explore those possibilities."
Can someone explain to me how this isn't like shooting yourself in the foot? Isn't the intent to harm a server with a client-injected script? I keep reading it and it seems like the point is to harm a client with a script submitted by a client - that is - yourself???
All your base are belong to us!
If you want to learn about cross-site scripting attacks, just click here!
You should never design your website when angry. Wait till you calm down, or you'll make mistakes. Cool, Calm Site Scripting (CCSS) is much better.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
http://www.cgisecurity.com/articles/xss-faq.shtml
This article somehow reminds me about the old VeriSign's ad campaign with naked women by which I was outrageously offended once.
Seriously, there was a huge cross site scripting vulnerability in Omniture's "award-winning web analytics solution for large, complex sites" (too complex for them, I guess) which was included in the famous VeriSign's Site Finder we all loved so much. It's not that VeriSign handles any sensitive data, fortunately...
(My link doesn't work any more, but the comment is still +5, Funny. :-P)
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
In high school for economics class we got to play a mock stock martket game (on the web). Well my stock market team consisted of myself and another CS student.
On the website you would enter in the amount of stock, stock symbol, and BUY or SELL in a form. That form would POST to a confirmation page and from there you would click "TRADE" and it would post to some server side page to execute the trade. The fools that designed the site thought it would be a good idea to validate all the data on the confirmation page and NOT on the server side page. We created a local version of the initial confirmation page, changed the action of the form to "http://www.tradingsite.com/cgi-bin/trade.pl". We then proceeded to buy -100000 shares of MSFT for about 40 bucks a pop.
The server had a formula of something like:
(STOCKPRICE * SHARES) + COMMISION = SUM
The sum was then checked against your accounts cash balance.
Something like:
IF (SUM > CASHBALANCE)
ERROR;
ELSE
EXECUTE TRADE;
Well we had a big negative number for our SUM so it passed.
The server then procceeded to:
CASHBALANCE = CASHBALANCE - SUM
Well anyone who has taken 5th grade math knows what happens when you subtract a negative number.
To make a long story short....we come into school about 2 weeks later and there is a big list of all the teams playing the stock market game in NY state. Our team is number 1 by about 2 million bucks, 2nd place is at about 105k. We confessed to whole the thing explained to the site what they did wrong and didn't get in any trouble.
The morale of this story:
Validate all user input before you perform ANY actions with it.
Slashdot - you provide some good security information and the next thing you know - 2.5 million hits later your server is a puddle of smoldering silicon and smells really bad. XSS isn't anything compared to the damage that slashdot's attention can get you.
Our next paper - how to survive a slashdotting.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
I'm a pint and three quarters .....
So I guess that makes me 1337er.
amen; that kid's fucking annoying. "OOOOOOOOOOH LOOK AT ME XSS VULN IN somesitenobodycaresabout.com NOW PLZ TO GIVE LEET SECURITY JOB THX." took me a solid 2 days to killfile that little shit.
*cough*
Its this kind of lack of understanding that makes the problem so prevelant.
First it doesn't make sense to htmlencode everything just as id doesn't make sense to addslashes everything (now turned off by default in all good php configurations).
Here's why: Not everything that comes in is to be displayed as html, just as not everything that comes in is destined for the database.
Unless you understand the risks, you can't guard against them though it appears some people are still able to be certain they have guarded against them.
If you do this,
sqlquery("select * from user where username='$user'") then you need to think what the problem is, its a well defined problem, it is that $user may contain a final ' mark and then some; maybe:
$user="jimjoe' or 1'"
so your preferences page now shows the first user in the db, or depending on your web page, all of them.
In php, htmlentities doesn't encode the '
If you are invoking system commands (and yes I one had to do a LOT of this from php) then be careful about shell meta characters like ` ' " and $ in certain cases.
The principle is that you need to make sure the system you are passing data on to interprets it in the literal sense that you require and you cannot do this unless you understand completely how each of the systems you will pass the data on to really does interpret data.
So if your user data is destined for the database, then escape it, something like:
sqlquery(sprintf("select * from user where username='%s'",addslashes($user)));
(yes there are other better was of doing it)
If you want to display on the web page inline:
echo htmlentities($user);
on the other hand if you want to display in an text area I think there is other encoding to use. If it is for a url you need to urlencode and htmlentities but I forget the order.
Understand the system you are communicating with.
Sam
blog.sam.liddicott.com
but thanks for saving me $8. what a shitty ending.
http://cgisecurity.com/lib/xss_anatomy.pdf
I'm developing a GPLed PHP application and was just wondering if anyone knew of an html sanititizing script that would allow for the input of a list of allowed tags.
:-)
I need something with a GPL-compatible license.
I guess I could just re-write Brad Choates's Sanitize Plugin in PHP, but it would be nice to not have to go through the trouble.
"When ideology and theology couple, their offspring are not always bad but they are always blind." -- Bill Moyers
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!
Enough said? And Cascading Style Sheets...
Where do you think the new improved networking stuff in XP came from? *cough* FreeBSD! *cough*
There is a conspiracy theory that it was Microsoft that bought the repeal of the infamous advertising clause - otherwise they would have had to put a public admission on every XP box that they had lifted other people's code.
mod parent up
Oh, I forgot you wouldn't want to hear the common sense reasoning.
It doesn't allow html either... so that probably wasn't ASP.NET
"Perl contains a set of built-in security checks know as taint mode. These checks protect you by insuring that tainted data that comes from somewhere outside your program is not used directly or indirectly to alter files, processes, or directories. "
What? PHP has no taint mode?-P