Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

XSS Vulnerabilities Reviewed and Re-Classified

CowboyNeal posted about 8 years ago | from the breaking-and-entering dept.

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?

cancel ×

142 comments

First post! (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#15586754)

WOOT!

How about some XSS abuse at interpol (-1, Troll)

Anonymous Coward | about 8 years ago | (#15586759)

Re:How about some XSS abuse at interpol (1)

brenddie (897982) | about 8 years ago | (#15586789)

curiosity killed the cat. dont click that link.

Re:How about some XSS abuse at interpol (1)

Bob54321 (911744) | about 8 years ago | (#15586981)

curiosity killed the cat. dont click that link.

Does that include the one in your signature?

Re:How about some XSS abuse at interpol (1)

m00j (801234) | about 8 years ago | (#15587265)

well I did anyway, it somehow managed to overload outlook and a copy of outlook express opened as well (the outlook express setup dialogue at least). Seemed to be trying to run some irc and edonkey scripts as well. Had to kill process on firefox.

Re:How about some XSS abuse at interpol (0)

Anonymous Coward | about 8 years ago | (#15588180)

Sure i *had* to click that link too - I'm glad I'm using a normal browser (Opera) - would not like to think about what could have happened with IE or other crap - Opera just blocked that PopUps and that was it...

Re:How about some XSS abuse at interpol (0)

Anonymous Coward | about 8 years ago | (#15588282)

curiosity killed the cat.

For the curious, it's a fake Interpol message submission page. There's a GNAA linky pic next to the submit fields, which I suspect Interpol would be unlikely to include on their real site.

Well (5, Funny)

twalicek (984403) | about 8 years ago | (#15586765)

Samy is still my hero.

Re:Well (1)

chiskop (926270) | about 8 years ago | (#15588853)

Samy is still my friend.

A hole is a hole (5, Insightful)

Watson Ladd (955755) | about 8 years ago | (#15586769)

Saying that these holes don't matter because websites can't avoid them with the standard method of doing things is just plain wrong from a security standpoint. If you are dealing with sensitive data, secure it. If the standard way won't let you, don't do it the standard way.

Re:A hole is a hole (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#15586856)

For those who don't know what parent means by "the standard way," this handy reference [columbia.edu] may help.

Re:A hole is a hole (1)

dnoyeb (547705) | about 8 years ago | (#15586942)

Your still young. It takes a few years to appreciate the difference between a quality hole and a not so quality hole...

Re:A hole is a hole (1)

kv9 (697238) | about 8 years ago | (#15587270)

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 (1)

IndigoZenith (791590) | about 8 years ago | (#15588495)

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?

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 (1)

baadger (764884) | about 8 years ago | (#15588672)

how many years does it take to learn properly using your/you're?

Correction:

how many years does it take to learn proper use of your/you're?

User Content (5, Insightful)

agnokapathetic (982555) | about 8 years ago | (#15586771)

As buzzwordy as Web 2.0 is, end-user content is rapidly becoming the majority of the visible end-user internet experience (e.g. Digg, MySpace, Facebook, etc.) With thousands/millions of users posting content, XSS filters start to become an arms race against the latest techniques. With Internet Explorer even rendering code with <scr\x00ipt></s\x00cript> as valid code. Even when filters are put into place, all it takes is one XSS virus [bindshell.net] to take down an entire website.

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 (3, Insightful)

Vexorian (959249) | about 8 years ago | (#15587171)

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 &gt;&lt;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 (4, Informative)

Mark Round (211258) | about 8 years ago | (#15587752)

"By simply turning > into ><before displaying content that was influenced by user input you get rid of every single XSS risk"

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 (2, Informative)

dk-software-engineer (980441) | about 8 years ago | (#15587803)

That is why you also turn " into &quot; when it's inside double-quotes. This is the right solution, you just have to finetune it. It's not that hard, you just need to remember it every single time it should be done. It's the "remember" stuff that's hard.

Include turning & into &amp;. Finally there's ' (&#039;) 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 (4, Informative)

jani (4530) | about 8 years ago | (#15588141)

Yet even this can be too simplistic, since there may be other things that's happening in the background.

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 (4, Informative)

piranha(jpl) (229201) | about 8 years ago | (#15588602)

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.

Pardon Me? (0, Offtopic)

drpimp (900837) | about 8 years ago | (#15586774)

If it was only Javascript that would be one thing. But when some one can "include" say a remote PHP file, I believe this is still considered XSS, maybe just another class of XSS. This is when it becomes an issue. It can allow a user to run arbitrary commands as the web server user, or what ever user that PHP is running as. Next thing you know, if your system is not harded properly, you have remote IRC pipes or shells sending data to/from your server to some remote host. It's a much bigger problem than expressed in the article. Buzzword maybe, but buzzword or not, still has potentially vulnerable security implications.

Re:Pardon Me? (3, Informative)

jmcguire81 (917481) | about 8 years ago | (#15586985)

Sorry, but its not the same thing. XSS is strictly dealing with injecting JavaScript into a page so that it will be run in a visiting users browser. What you describe is known as RFI, Remote File Inclusion. This requires some very specific kinds of flaws in program logic to allow it to happen, while XSS can generally be found from any unfiltered content being echoed back in a web page.

Crazy (5, Insightful)

Bogtha (906264) | about 8 years ago | (#15586778)

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

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 is of the utmost importance to note that a page that has an "XSS vulnerablity" is no more dangerous than visiting a random result generated by a Google search

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 (1)

masklinn (823351) | about 8 years ago | (#15587816)

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 destroyed the whole forum.

Re:Crazy (1)

Crayon Kid (700279) | about 8 years ago | (#15588740)

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.

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 up. Because that's what XSS is: JavaScript injection, plain and simple.

Don't want JavaScript injection? Cut to the root of the problem. Deny the means of propagation: raw HTML. If your users need to format text and you don't trust them, then use something else: BB code or wiki syntax. End of story.

XSS - a bug... sometimes (4, Insightful)

madsheep (984404) | about 8 years ago | (#15586784)

I think someone would be pretty hard pressed to convince me that XSS cannot be considered the earmark of bad or insecure coding in all or most cases. If anyone reads full disclosure we all know that any given moron can spend 24 hours a day looking on every website to find some XSS bug in the page. Now just because XSS exists in a site does not make it insecure or poorly coded (the later is arguable). However, when these XSS bugs exist on websites that use session cookies or have a login of some sort that allows users to take actions, post, edit things, etc. then it is a product of insecure and poor coding. The risks exists when something can be gained by a threat source by conducting an XSS attack. If a user can post something on slashdot that slaps over my slashdot username and password or my session cookie (allowing them to jump in on slashdot right now and post as me) then it is a security risk. Finding a XSS issue on a webpage such as one that www.arin.net (see Full Disclosure) really doesn't do anything or represent a risk. It is more about what can be gained or done from the XSS attack. As a quick side not to this dicussion.. XSS is *VERY* easy to prevent. Much more so than SQL injection. Who knows maybe these people will try and reclassify SQL injection as not being a problem either. Sanitizing user input by not allowing it or for example converting to < and > respectively is pretty easy and will stop almost all of these attacks. There is no excuse for not being able to secure a page with such coding practices to protect your site and users.

Re:XSS - a bug... sometimes (1)

DavidWide (978087) | about 8 years ago | (#15586846)

Finding a XSS issue on a webpage such as one that www.arin.net (see Full Disclosure) really doesn't do anything or represent a risk.
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 (1)

Watson Ladd (955755) | about 8 years ago | (#15586864)

or looking at where user input enters the page and restricting html to a limited number of tags. It's hard to think of all evil sequences. Thinking of what's good is simple.

Re:XSS - a bug... sometimes (1)

KPU (118762) | about 8 years ago | (#15586887)

XSS is *VERY* easy to prevent. Much more so than SQL injection.
SQL injection is easy to prevent. Pass input though an escaping function or use parametrized queries.

Re:XSS - a bug... sometimes (1, Informative)

Anonymous Coward | about 8 years ago | (#15587049)

XSS is *much* harder to prevent than SQL injection. Why? If you're a competent coder, you can secure the code on the server end properly. In order to prevent XSS, you need to know about parsing bugs in the *browser*.

Re:XSS - a bug... sometimes (1)

baadger (764884) | about 8 years ago | (#15588703)

The solution to this problem would appear to be to whitelist what is *allowed*, rather than filtering out what is not. If you only need a simple commenting system then only allow plain text, convert double line breaks to </p><p> and wrap the whole thing in <p> ... </p>

This is made alot more difficult with unicode/multibyte input however.

Re:XSS - a bug... sometimes (3, Interesting)

masklinn (823351) | about 8 years ago | (#15587840)

XSS is *VERY* easy to prevent. Much more so than SQL injection.

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 (1)

Fuzzie Viking (746210) | about 8 years ago | (#15588857)

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 (1)

masklinn (823351) | about 8 years ago | (#15588879)

Have you noticed that it's not, in fact, older than mysqli_ or PDO?

Yes, unavoidable. (3, Informative)

Spazmania (174582) | about 8 years ago | (#15586795)

Back in the 1980s' BBS days, I wrote a terminal emulator for the commodore 64 that would allow a BBS to enhance the user's experience by downloading and running short assembly programs. Users of any standard BBS software could even post such programs to the message boards for other users to enjoy.

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. (3, Informative)

LordLucless (582312) | about 8 years ago | (#15587033)

There's a difference between that example and XSS attacks on a website.

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. (3, Interesting)

Spazmania (174582) | about 8 years ago | (#15587143)

I should hope there are differences between my situation and XSS attacks. They're seperated by the better part of two decades of advances in computing.

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. (1)

LordLucless (582312) | about 8 years ago | (#15587247)

I think you're missing what I'm saying.

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 regexp on all user-supplied data to convert to &gt;, and the content will be treated as text.

It only gets to be a security issue when you try and do what you did; allow distribution of arbitrary code. That's not what most of these sites do, but since the primary langauge of the web is a human-readable, ascii-text based language, it's possible to sneak executable code on to them disguised as content.

Re:Yes, unavoidable. (2, Informative)

Spazmania (174582) | about 8 years ago | (#15587343)

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 regexp on all user-supplied data to convert to >, and the content will be treated as text.

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 that would trigger my software and eliminate them. Problem is, they were (as you say) bog-standard BBSes. They weren't expecting to receive any sort of text that some wacky guy's terminal emulator would render as machine code.

Did that make the BBSes insecure? I say baloney. The BBSes weren't the problem. The problem was that my software would accept such text and render it as machine code.

Browsers that run Javascript could be rigged so that some kind of activator has to be present in the main <head> section or no later code will be recognized. They aren't so suddenly its the fault of every individual web form author who doesn't account for the possibility that someone might enter some code in to the form. No way. Put the fault where it belongs: the architecture of the Javascript language.

Re:Yes, unavoidable. (1)

LordLucless (582312) | about 8 years ago | (#15587671)

Did that make the BBSes insecure? I say baloney. The BBSes weren't the problem. The problem was that my software would accept such text and render it as machine code.

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 what you expect, verify everything, and develop secure solutions.

Re:Yes, unavoidable. (1)

psmears (629712) | about 8 years ago | (#15588201)

In terms of HTML, that's easy. Just run a regexp on all user-supplied data to convert < to &gt;, and the content will be treated as text.

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. (1)

LordLucless (582312) | about 8 years ago | (#15588681)

Yep, particularly when people start using javascript event handlers in otherwise harmless tags. Thats why I think a lot of sites use bbCode type stuff - [b] instead of <b. Just filter out all HTML tags, then convert bbCodes to HTML.

Re:Yes, unavoidable. (1)

masklinn (823351) | about 8 years ago | (#15587845)

As long as you escape all user input properly, there's no chance of an XSS vulnerability.

Define "escape all user input properly"

Re:Yes, unavoidable. (1)

LordLucless (582312) | about 8 years ago | (#15587876)

Take anything that can be interpreted as browser-executable code, and transform it into something that ain't.

Re:Yes, unavoidable. (1)

petermgreen (876956) | about 8 years ago | (#15588518)

Define "escape all user input properly"

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 &lt;, & becomes &amp;

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 from input to output.

if you wan't to offer users the ability to have custom javascript given back to them or for admins to edit such script you must take extra steps to ensure the information really was intentionally submitted by the user (or thier machine is so comprimised it doesn't matter anymore)

My take on this sort of thing (5, Interesting)

dkleinsc (563838) | about 8 years ago | (#15586805)

XSS is not the problem. JavaScript is (just for the record, at NeoSmart we feel JavaScript is more of a headache than it is a life-saver..), and XSS is but a result of the (many) inherent security holes in JavaScript and not in the package itself!

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 (0)

Anonymous Coward | about 8 years ago | (#15587037)

That's about as accurate as saying that if Chewbacca lives on Endor, you must acquit.

The Chewbacca defense. I'm glad someone took the time to put that in perspective!

Re:My take on this sort of thing (0)

Anonymous Coward | about 8 years ago | (#15588409)

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.

Actually, over time and many users, yes, they are.

Javascript is a loosely-typed language designed without security considerations in mind. Like the legions of programmers who insist on using C to create large end-user applications, those who use Javascript ultimately contribute to a culture of "fixing" leaks and vulnerabilities.

Ironically, true Java applets prevent the very problems that Javascript/AJAX engender. The current generation of Java applet technology is very nice indeed. It is a tried and tested technology that can accomplish anything that you can accomplish with AJAX and more, EXCEPT for compromising security in the ways that Javascript-enabled sites can.

But because applets have the reputation (not the reality) of being "slow" or "too big", even in this age of big Internet pipes into most homes, they aren't usually considered as an option. Too bad, really.

Re:My take on this sort of thing (1)

Itchy Rich (818896) | about 8 years ago | (#15588702)

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 jobs.

Personally I find Java applets to be painfully slow because our corporate anti-virus setup makes Java run at glacial speed... which makes me laugh because we're a software company that develops almost entirely in Java.

Re:My take on this sort of thing (1)

baadger (764884) | about 8 years ago | (#15588816)

Maybe i'm completely wrong, but aren't Java applets just Java programs thrown into a browser window in a secure context? I agree with you, in my opinion it *is* rather disturbing that people are trying to make Javascript do just that, as AJAX, without any standard mechanism for doing so in place (Hence all these AJAX frameworks popping up).

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 all that juicy browser functionality. What people want from AJAX is the best of both worlds. Java can't do that (yet?) but, although it's distusting and ugly, Javascript can to a degree at the moment

This is why standards like XSLT [w3.org] , 'Web Applications 1.0 [whatwg.org] ' and new versions of Javascript are coming into existance, there is now an apparent need for smoother and more standardised integration between a user's interaction with a client side document, client side data or state, and the server side (database backend).

Of course the side effect of doing more work on the client side is you have less and less data hitting the server you cannot trust and XSS, SQL injection attacks and God knows what other vulnerabilities are going to play and larger and larger role in 'Web 2.0'

Re:My take on this sort of thing (1)

Itchy Rich (818896) | about 8 years ago | (#15588649)

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.

XSS Vulnerabilities are caused by improperly escaped HTML tags, which are absolutely an implementation issue. HTML tags have to be escaped regardless of XSS because otherwise users can accidentally or otherwise paste a </div> tag into your page and screw the whole thing.

Why shouldn't you have Javascript in an HTML email? It's just a document like any other. Surely that's the same argument as saying that we shouldn't have Javascript in web pages... or is it the implementation of permissions in the email application that are the problem?

First language (5, Insightful)

ptaff (165113) | about 8 years ago | (#15586874)

Are they unavoidable, or just a symptom of lazy coding, or both?

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 (1)

HeroreV (869368) | about 8 years ago | (#15587994)

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.
You didn't open source your programs?! And you consider that to be good?! What are you doing at Slashdot?!

Let your work free! I even publish all my grocery lists under a Creative Commons license for all to enjoy! Because /. tells me too!

This guy doesn't know what he is talking about! (4, Informative)

NerdENerd (660369) | about 8 years ago | (#15586883)

I work for a bank. A hacker found one page in the Internet banking system that echoed a value from a form into an error message. They then used this to inject some JavaScript which gathered user logons. They managed to acumulate about $70,000 of fools money into a holding account before they were caught. I don't feel particulay sorry for fools who fall for phishing scams but it was still a security hole in the web application that could simply be avoided by an echoding of values before echoing to the page. Since then all code is audited for SQL injection and XSS by an external company before being relesed to production.
XSS is a real security threat.

Re:This guy doesn't know what he is talking about! (1)

Pink Tinkletini (978889) | about 8 years ago | (#15586935)

"Which bank do you work for?"

"...A major one."

Re:This guy doesn't know what he is talking about! (0)

Anonymous Coward | about 8 years ago | (#15587773)

Fuck the banks. It doesn't take a computer for a bank to put a major fucking security hole in your account or your identity. Someone posted a link to this a while back:

http://wamublamesgrandma.blogspot.com/ [blogspot.com]

Check out this check the bank cashed:

http://wamublamesgrandma.blogspot.com/2006/03/chec k-1.html [blogspot.com]

The biggest security liability in bank applications are their god-damned lobbyists.

Re:This guy doesn't know what he is talking about! (2, Insightful)

jrumney (197329) | about 8 years ago | (#15588196)

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 (4, Insightful)

Snowhare (263311) | about 8 years ago | (#15586899)

XSS is not unavoidable and it is a security vulnerability. Slashdot has a cookie based login system. This means that if there is an XSS vulnerability in Slashdot I can cause any action a logged in user (maybe, Commander Taco?) can cause by doing something as simple as tricking them into loading a web page with an 'invisible' 1 pixel tall frame exploiting the XSS. Saying XSS isn't a security vulnerability is like claiming that leaving your house keys under the doormat isn't a security vulnerability.

Re:They are flat wrong (1)

Pink Tinkletini (978889) | about 8 years ago | (#15587152)

...if there is an XSS vulnerability in Slashdot I can cause any action a logged in user...
You don't need XSS [tinyurl.com] for that. :-)

Re:They are flat wrong (0)

Anonymous Coward | about 8 years ago | (#15587553)

Depends on.

You can force a logout on slashdot, but if a site is coded properly actions with side effects (especially side effects that need to be secured) will only be allowed by POST. Your tinyURL, or 1x1 pixel hacks aren't going to work.

Re:They are flat wrong (1)

HeroreV (869368) | about 8 years ago | (#15588022)

...loading a web page with an 'invisible' 1 pixel tall frame exploiting the XSS...
Firefox and IE both evaluate scripting in hidden iframes. Just set the CSS to "display:none" and not a single pixel of the frame will be visible anywhere on the page. Although I really don't see why you would want to hide the frame very badly anyway.

Is it just me (1, Interesting)

Anonymous Coward | about 8 years ago | (#15586904)

Is it just me or did this article not make sense. The information is not presented logically, and it seems to contradict itself. It is vague about details. Is Javascript the problem, or is it XSS, or is it bad users, or is it site owners, or hackers exploiting XSS? I still don't know.

Not me! (3, Funny)

fuzzyfozzie (978329) | about 8 years ago | (#15586913)

I use VBScript, so I guess I'm safe.

XSS is made of people! (2, Interesting)

Ant P. (974313) | about 8 years ago | (#15586972)

Are they unavoidable, or just a symptom of lazy coding, or both?

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! (0)

Anonymous Coward | about 8 years ago | (#15587268)

>It's impossible to write perfect software - not even NASA can do that.

This has to be one of the most often repeated idiocies around. Depending on the scope of the problem, it may be extremely difficult, yes, but not impossible, assuming the specification has a solution (I'll agree that writing software which decides if an arbitrary program terminates is impossible :-))

That said, not many people are even trying to write perfect software, i.e. software with a proof: typically people just try for software that is informally/experimentally determined to be good enough, or at least rely on other software like compilers and interpreters for which they have no proof.

Re:XSS is made of people! (1)

CTachyon (412849) | about 8 years ago | (#15587954)

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? (3, Informative)

radical_dementia (922403) | about 8 years ago | (#15587010)

Perhaps the author is unaware of the PHP function strip_tags. Or in a more general sense, a simple regular expression can be used to remove script tags or all HTML tags from a string. That's seriously all you need to do to eliminate XSS. The only times when XSS holes exist are when lazy or oblivious coders forget to call the function on any input passed to a script.

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. (3, Interesting)

The MAZZTer (911996) | about 8 years ago | (#15587087)

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. (3, Informative)

radical_dementia (922403) | about 8 years ago | (#15587308)

Yes, you are absolutely right! However it seems the possible damage is very limited. I just tried this out and it works in both Firefox 1.5 and IE6, but surprisingly NOT in IE7. Here is what I did:

First I made a css class called test in a seperate .css file in which the background-image property had the following text:

background-image: url('javascript:window.location=\'http://www.googl e.com\'')

Then I just made a simple html page with a div tag of that class. When I navigated to the page, it almost instantly redirected to google. It also worked with putting the same text in the style attribute of a tag. However, I tried doing some other things, such as calling alert() and document.write(), and appending document.cookie to the url, but these all did not work. In firefox, the javascript console reported "Uncaught Exception: Permission Denied" on those scripts. IE6 and 7 simply did nothing. So while you can use this to screw up a page, it doesn't seem like you can do more serious things like session hijacking. But I agree with you that the best solution is just to strip all HTML.

Re:Script tags isn't enough. (2, Informative)

masklinn (823351) | about 8 years ago | (#15587863)

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. (1)

timbrown (578202) | about 8 years ago | (#15588852)

Not just in CSS URL attributes tags actually, see Misunderstanding Javascript injection [nth-dimension.org.uk] . Interesting to note that this appears to have been fixed in IE 7, although I haven't carried out any detailed testing yet.

People being what they are... (-1, Flamebait)

Pink Tinkletini (978889) | about 8 years ago | (#15587046)

Sometimes, you don't even need XSS to be annoying. [tinyurl.com] (Worksafe.)

Re:People being what they are... (0)

Anonymous Coward | about 8 years ago | (#15587184)

XD True. Why is there no referrer validation or anything for logout?

Obiously... (0)

Anonymous Coward | about 8 years ago | (#15587073)

Obviously CowboyNeal is drunk or his clock incorrectly displays 4/1/2006. No sane programmer with a clue would post or link to such utter nonsense.

XSS has always been bullshit (3, Insightful)

neuroxmurf (314717) | about 8 years ago | (#15587078)

If you allow local execution of code provided by untrusted remote sites, you have no security and never have, no matter how much the vendor assures you their "sandbox" is safe. XSS is not the security hole, it's just the latest batch of holes in the entire concept of client-side scripting.

Huh? (2, Insightful)

GT_Alias (551463) | about 8 years ago | (#15587212)

Buffer overflows are an unescapable symptom, C is the real problem. Car accidents aren't the problem...steering wheels are.

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? (5, Interesting)

NerdENerd (660369) | about 8 years ago | (#15587226)

Click on this link for an example against CitiBank
CitiBank Exploit [citibank.com]

Re:Really? (1)

limegreen (516173) | about 8 years ago | (#15588167)

That's good. Better looking than most phishing emails I get. Even Slashdot reports the domain as [citibank.com]

Can make it work with https?

Most at risk (2, Insightful)

Joebert (946227) | about 8 years ago | (#15587242)

Advertisers are the ones who are effected the worst by this.

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. (1)

Telastyn (206146) | about 8 years ago | (#15587317)

That's like saying buffer overflows are a nasty unavoidable side effect of using C. They're exploits in the practical world, plain and simple. Caused by poor coding? Yes. Likely due to language difficiencies? Absolutely. Unavoidable? No, not really.

Complete Twit (1, Insightful)

Anonymous Coward | about 8 years ago | (#15587345)

Read some of the other guy's articles, he's a complete twit. The best is the one on how javascript should be dead and replaced with VBScript, and how Firefox is "against" Javascript, and how javascript was "almost dead" until Gmail came around.

Probably a 15 year old kid. Its a fucking wordpress site w/ the default theme. I mean, come on, seriously.

Silly and obnoxious (1)

Lost+Found (844289) | about 8 years ago | (#15587359)

It's perfectly possible using simple hashing techniques to totally avoid XSS attacks.

This guy is asking for Bruce Schneier's liability (1)

Schraegstrichpunkt (931443) | about 8 years ago | (#15587417)

As many of you know, Bruce Schneier has been pushing for new law to make software developers liable for defects, regardless of warranty disclaimers. While I don't dispute his analysis of the situation from a short-term security standpoint, I think such the liability he wants would be a disaster for self-employed software developers and the free/open-source software movement in general, and I think such law is unnecessary in the long run (remember that the software industry is still in its infancy).

That said, if we, as software developers and vendors, start taking arbitrary classes of security holes and declare them "non-vulnerabilities" for the sake of convenience, we are just begging to be regulated!

Whether or not we should care about certain vulnerabilities is another question (for example, executing arbitrary ActiveX code on a tightly-controlled private network is not necessarily something to worry about), but claiming that such vulnerabilities aren't security issues is lying.

The Cross Site Scripting Faq (2, Informative)

mrkitty (584915) | about 8 years ago | (#15587473)

Once again if you're curious what XSS is check out

The Cross Site Scripting FAQ [cgisecurity.com]

Idiots (1)

twistah (194990) | about 8 years ago | (#15587531)

I won't even comment on the security risk issue; though it takes a bit of social engineering, XSS can easily be leveraged for everything from session hijacking to plain old phishing.

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 doesn't even have a basic understanding of programming or security.

Neowin: Lazy or Naive? (3, Interesting)

humanaut (650434) | about 8 years ago | (#15587557)

Re:Neowin: Lazy or Naive? (1)

aymanh (892834) | about 8 years ago | (#15588504)

When I came across the parent comment, I was curious to see how it actually worked. Unlike the common XSS attacks, this one doesn't require JavaScript to be enabled, when searching the vulnerable site, it outputs the search query back to the browser, the query is stored in the $s variable, apparently the variable isn't sanitized before being output, so one can inject whatever HTML code they like into the page. The vulnerability is mentioned here on the WP support forums [wordpress.org] , sadly posters assumed that such code wasn't vulnerable.

What the hell is Cross Site Scripting? (1)

vtcodger (957785) | about 8 years ago | (#15587573)

Feeling a bit lost? No damn wonder.

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 Javascript.

y@uo 7ail it. (-1, Flamebait)

Anonymous Coward | about 8 years ago | (#15587791)

"XSS is another one of those buzzwords (4, Funny)

damburger (981828) | about 8 years ago | (#15587812)

...we prefer to call it an 'unrequested Javascript surplus'"

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? (2, Informative)

IzEBaLL (977974) | about 8 years ago | (#15587900)

In my master thesis I implemented a solution in the mozilla firefox web browser that protects the surfing user. It analyzes the data access and data flow in the JavaScript engine of the web browser.

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.

XSS isn't a problem. Javascript, cookies are (0)

Anonymous Coward | about 8 years ago | (#15587965)

Don't use javascript, don't enable cookies. No problem.
It really gets my why people don't use HTTP auth (plain or digest) for authentication, as it was intended, instead of rolling their own crap. Sensible people should not escape stuff beyond the normal - XSS problems after than are a problem of the browser.

Our Tools Suck (1)

Dom2 (838) | about 8 years ago | (#15587968)

Part of the problem with XSS is that pretty much every single web development tool out there has the wrong defaults. When you build a page in a templating system, anything that you insert into that template should be HTML escaped by default. Of course, you need an easy way to turn that off. But that simple act would probably fix 99% of holes out there. For example, in HTML::Mason [masonhq.com] , I've set it up so that this:
<% $foo %>
gets escaped, whilst this does not.
<% $foo |n %>
The question remains -- why are we putting up with such poor behaviour from our tools? The SQL people fixed this sort of issue years ago by introducing placeholders into their APIs. The result is that SQL insertion became a rarer vulnerability. Why not for web templating systems too?

another TLA starting with X? (0, Offtopic)

m4c north (816240) | about 8 years ago | (#15588006)

Taking the liberty to change T to trendy, sounds like XSS would fit in nicely with XHTML, XML, Xbox, Xmen, X11, Xray, and heaps of others [stands4.com] as "X Something Something". Maybe we should ask Homer?

A Clarification (0)

Anonymous Coward | about 8 years ago | (#15588395)

A lot of what has been said here really doesn't go against what the article was about - it wasn't about XSS not being a vulnerability, just about it being taken out of proportion... There's a clarification/follow-up posted now: http://neosmart.net/blog/archives/194#comment-2299 [neosmart.net]

Can we mod the article (1)

danskal (878841) | about 8 years ago | (#15588433)

Can we mod the article -1 troll?

I like JavaScript! (2, Funny)

supersnail (106701) | about 8 years ago | (#15588437)

Much of the article seems to be a diatribe against JavaScript more properly called ECMA script.
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.

A Clarificiation.. (0)

Anonymous Coward | about 8 years ago | (#15588741)

NeoSmart Technologies has posted a clarification on this article:
The Clarification.. [neosmart.net]
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...