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 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.
The main reason Cross Site Scripting is abbreviated XSS (instead of CSS) is to avoid confusing it with Cascading Style Sheets (this confusion is likely to happen since both of these things are related to web pages).
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.
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.
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 completely disagree. XSS is as dangerous if not more so than a buffer overflow, im many cases. Take this for example:
Your target is one or more users of a community web site. The site itself isn't the target, only the means to your own ends. Remember, it's the users you are after, not the site itself. So you smash the stack on the server, grap the mySQL database, and open it up. Bummber, all the passwords are md5'd and basically useless. With XSS you could conceivably alter the login for that they get, and before md5($password) is executed you export $password (still in plain text) off to your little database.
Cracking isn't about what is the most "exciting and leet" way to do it, it's about using the tools you have at your disposal to get what you want done, done. Sometimes this is a buffer overflow, sometimes it a XSS attack, sometimes an emailed trojan, and sometimes even social engineering to gain physical access (even via an unwitting human proxy).
Everyone is entitled to their own opinion. It's just that yours is stupid.
You're sure bananas aren't vulnerable?
Now he tells me. Oh, oh, the time I have wasted.
Opinions on the Twiddler2 hand-held keyboard?
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.
An accurate judgement, no doubt, but the point is this:
Is there any value in moderating the post as redundant - redundant it may be, but useful, and arguably more useful than its moderation as redundant
blog.sam.liddicott.com
*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