Slashdot Mirror
Cross-Site Scripting Hits Major Sites
An anonymous reader writes "Dark Reading and SC Magazine covered a story about hackers posting cross-site scripting (XSS) vulnerabilies en mass on dozens of high profile websites including Dell, MSN, HP, Apple, Myspace, YouTube, MSN, Cingular, etc. The media coverage drew the hacker's attention to the publication's websites where they got a taste first-hand. On message board wall-of-shame is PC World, MacWorld, Fox News, the Independent, and ZDNet UK. "...not only did we get the "scoop" on the XSS site problems, but we also got the message loud and clear: Don't assume you're immune to XSS vulnerabilities. They're everywhere." The news comes shortly after Mitre (CVE) released statistics showing XSS has become the most popular exploit. Unfortunately new XSS attacks are growing increasingly severe and scanners are unable to find many of the issues on modern websites."
Which is why I'm so happy that the currently-in-demonstration phase of the new Slashdot discussion system presumes/requires that Javascript be active.
Have you ever read poorly-written, newbish code?
For anything non-trivial, it would probably be quicker and cheaper to have the "pro" write the code in the first place than to pay him for his time to read, understand, and correct a steaming pile of turd spaghetti.
I've taught programming on and off for about 30 years at one of the best schools in the country, and I have never heard anyone even mention checking user input for something malicious. I have never seen it in a text book. This sort of thing isn't addressed by Knuth. It never comes up since in the recent past all development was done for trusted users. For example, you wouldn't care if a user on an isolated computer running Microsoft Word attempted an exploit. You don't need to check user input when teaching algorithms.
That simply isn't CS 101. It isn't CS anything. It's only covered if you have a low-level web development class at a pitiful tech school.
"Draw you own conclusions from there..."
You're using logic, while security software marketers are using damage control.
Oh You POS
Web 1.0: Simple fishing scam
Web 2.0: Cross-Site Scripting
Before web designers blame themselves for this, the existence of XSS is really a fundamental design flaw in the way JavaScript and browsers work. It should have been obvious as soon as JavaScript came out that these kinds of attacks would become a major issue over time, but the "ooh shiny" attitude of the computer industry meant that people adopted JavaScript without knowing what the implications were. In fact, the other big security hole and productivity drain of the industry, C/C++, got adopted in a similar way.
Writing any substantial piece of software in C, C++, or JavaScript without creating safety or security issues is extremely expensive and beyond the ability or resources of most developers. For C and C++, there are alternatives you can choose today. For JavaScript, you just have to minimize its use or simply not worry about it and let the client fix it with tools like NoScript.
"Web design" is for aesthetics and graphics people, like "interior design". Of course you run into problems when you have a web designer doing development work!
As for "No web developer has written XSS vulnerable code since 2002", I refer you to The Daily WTF.
http://outcampaign.org/
but it's probably pointless. Not enough developers care about their craft.
There's a prominent "popular science" website out there (no, it's not this one that I'm thinking of) that has ENORMOUS XSS vulnerabilities in its image gallery. They pass captions and img src in URL encoded query string parameters. Yuck.
I noticed this about a year ago and reported it to the development team, with a demonstration link that put in a (sorta not nice) image and caption. No response, and when I checked six months ago the vulnerability was still there. So much for being a nice guy.
- Always use parameterized queries and never construct your own queries by concatenating strings. This will not only speed up the application, it will make sql injection attacks a non-issue
- Always verity the users input. You never know what the user is going to try to do with bad input.
- When programming in languages like C, always check to ensure that the user can't perform a buffer overflow attack.
I'm sure there's a lot of other things that people could add to this list. There's a lot of mistakes that happen over and over again. And I don't think that it's because people don't care, or aren't smart enough, but simply because they don't know the problem exists.Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
The biggest problem is farming everything in the world out to $8/hr guys in some foreign country. If you pay $8/hr, you're going to get an $8/hr guy. Keep in mind that Wal-Mart starts at $9/hr. Given these two statements, I fail to see why it's surprising that such simply fixed vulnerabilities continue to plague software.
2 cents,
QueenB
HDGary secures my bank
I've taught programming on and off for about 30 years at one of the best schools in the country, and I have never heard anyone even mention checking user input for something malicious. I have never seen it in a text book. This sort of thing isn't addressed by Knuth. It never comes up since in the recent past all development was done for trusted users. For example, you wouldn't care if a user on an isolated computer running Microsoft Word attempted an exploit. You don't need to check user input when teaching algorithms.
That simply isn't CS 101. It isn't CS anything. It's only covered if you have a low-level web development class at a pitiful tech school.
Best.... Troll... Evah!
A) It's just as simple to prevent an SQL injection attack. Failing to clean your input is just a stupid mistake, regardless of the input method. Mistakes happen, but let's not pretend that input validation is complicated.
B) The reason people like to build web interfaces is that the client, server, and transfer mechanism already exist. Writing a new one for each project is much, much more work.
I'm a web developer and I've said this dozens of times.
VALIDATE ALL INPUT EVERYWHERE.
Validate on the client. (For bandwidth reduction)
Validate at the APP Tier (For security)
Validate at the Data Tier(For security and integrity)
If you accept input from a web page, scrub it, and that doesn't mean stripping brackets or quotes, it means putting in a list of valid characters and tossing or replacing absolutely everything else.
Yes, you might wind up validating something that doesn't need to be validated or scrubbing something that doesn't need to be, the performance hit is worth it.
Also, Stored Procedures are a great resource, if you design them properly you add an extra layer of security that can actually improve your application performance. (All my recent projects have Stored Procedure execute only rights.
If your db code has select * from table in it, you're doing it wrong.
Ok, enough ranting from me.
How many "web" templating systems do you know that automatically escape HTML unless told otherwise? I know of one that can be made to do so: Mason. Even then, you have to enable it, as it's not turned on by default.
What about PHP, ASP, JSP and so on? Will they ever grow up and automatically escape HTML by default? I doubt it very much.
In the meantime, there's always mod_security if you're willing to invest the time configuring it. But it's no guarantee...
-Dom
The problem isn't that they didn't validate the user input, so much as that validating user input is really, really hard. RSS aggregators are discovering the problems with validating that HTML is safe. See http://www.feedparser.org/docs/html-sanitization.h tmlt yles-as-part-of-sanitation/
The trouble is that an approach like that limits what you can do too much: http://www.symphonious.net/2006/09/10/stripping-s
Any site that wants to support formatted comments, like Slashdot, has to deal with this. The plus side when it's just comments is that you can have very draconian limitations to what's accepted without it getting in the way (like Slashdot does).