The Almost Hopeless Challenge Of Web Security

0

Today we are trusting the web with our most personal and important data, from private photos and social graphs to finances and key work documents. Our hesitation to share such information has dropped over the years as our trust in our favorite services grows. Yet all the while, the web is actually growing less secure, as sites are left open to new attacks that can spread easily and leave users totally unaware when they’ve been compromised.

Looking back on the history of the web, classic security protection involved patching servers to assure latest versions were running, monitoring advisories from vendors, and maintaining some level of filtering and firewall to keep basic attacks out. Simple moves on the part of an admin or developer could protect sites from 99% of automated scripts. But a few years ago, a new security can-of-worms was opened, as new exploits that took advantage of simple oversights within web applications were being used to steal large amounts of user data. This new class of vulnerabilities took advantage of attack vectors within custom built web applications, using techniques like passing Javascript calls into web forms which would then be published back to an unsuspecting user. This new breed of attack was referred to as Cross-Site Scripting (XSS) — in short, the ability to manipulate a trusted website to run untrusted scripting code on a victim’s browser.

Cross-Site Scripting, and its related cousin, Cross-Site Request Forgery (XSRF), have led to attacks and exploits such as MySpace being taken down (via a worm, Sammy), data being stolen from 18 Million users of a Korean auction site, a Gmail weakness used to blackmail a domain owner and even an exploit targeted at changing the settings on a user’s local broadband router. All of these exploits were accomplished by convincing the user to click a link, an email (where an embedded image containing an exploit payload was displayed) or by simply visiting a site they trusted and had previously visited.

Various statistics claim that up to 80% of security vulnerabilities (pdf link) in the past 2 years have been the result of XSS and XSRF. There are claims that at various points, over 70% of websites were vulnerable to either one or the other. Anybody who understand how these attacks work, and who understands how to conduct a simple test (i.e. feed something like '<script>alert('y0');' into a web app and see if it pops back out somewhere unfiltered), would tend to agree that a large number of sites were, and still are, vulnerable.

Complicating the XSRF and XSS problem is the fact that not only does it take time to inform and educate developers, but that new ways of conducting such attacks against the most modern web apps and browsers are still being discovered. While application developers are busy cleaning up their code to protect against simple vectors discovered years ago (eg. escaping simple input text with addslashes()), security researchers are discovering new ways of exploiting the trust relationship between a user, a website and the web browser. These ‘new ways’ are being discovered all the time, and often fall outside of the box of previous thinking on what it takes to secure a web app.

For instance, today I read about (via dalmaer of Ajaxian) a newly discovered potential means for XSS and XSRF exploits by forcing a browser to talk HTTP to a non-HTTP service and have the code response interpreted, bounced-back and executed by the browser (that is my single-sentence attempt at condensing this brilliant description, which should be required reading for every app developer). It seems that every few weeks I stumble on yet another description of how to manipulate the trust relationship to exploit a user.

What is worrying is that these attacks exploit the foundation of the web — a network that was built with an implicit level of trust assumed between users and servers. To keep up with security requires a key re-think of how data is transported on the web and destroying the assumption that most data is safe data. Also worrying is that in all likelihood, most successful attacks exploiting these methods are likely to go unreported, as they can be used to silently attack a targeted individual who would usually have no way of knowing what is occurring underneath the hood of their browser. The black-hats have no incentive to share new methods they discover, forever locking developers and corporate security researchers (or those working on the ‘good’ side) in a race to stay in front.

Having performed bare-bones testing of new web applications I see, as well as monitoring the security announcement lists of web applications I use myself, I can safely say that most web application developers today are at least a year or more behind on the latest security vulnerability methods being discovered. Complicating this is that browser manufacturers themselves do not completely understand the issues involved, and in some cases are moving backwards (ie. the new IE8 is now allowing XmlHttpRequest across-ports). Scary? Yes. What to do about it? I have no idea, other than to get educated and attempt to stay on top of it.

Update: A somewhat ironic twist to this story. When I included the code example above (ie. how to test for XSS) it actually passed through the CMS running this blog and kept triggering when I would attempt to preview or publish this post.

Great post, but you might want to fix the word developer in the sixth paragraph from the top (at the moment it says develoep)

Matt

It’s ok the cybersecurity bill will make it all better.

http://fudge.org Jay Cuthrell

You could almost replace the word “web” with “Microsoft” and that’s not a slam against Microsoft in any sense. It just shows that the foundations have to change before the scaffolding will become more trustworthy.

The web is overdue for a rewrite.

I just want to fast forward past Web Vista.

Jeff

We aren’t even at Web 3.0 and you want to skip straight to Web 7? Psh, children these days are so impatient!

http://josephscott.org/ Joseph Scott

About your last paragraph:

Update: A somewhat ironic twist to this story. When I included the code example above (ie. how to test for XSS) it actually passed through the CMS running this blog and kept triggering when I would attempt to preview or publish this post.

actually i read shit online recently, and have that article open now and haven’t read it yet. my daily is ~20% of techmeme, internal yammer, some email and the few tweets i manage to catch

http://www.inkreadyprint.co.il barz

a bigger solution is needed. A developer can only handle security threats he knows about and it’s impossible to foresee every possible threat. You do your best and must also hope for the best. This problem is even bigger for cloud applications

http://www.firehost.com Chris Drake

Barz – totally agree. We haven’t rolled out a cloud solution as we’re not confident it can be adequately protected at this stage. Trust me, we’ve been trying to do it for over 6-months.

Nope

“Today we are trusting the web with our most personal and important data, from private photos and social graphs to finances and key work documents.”

Please speak for yourself. YOU do all of that.

I don’t.

@Nope

This problem is not about you or me Nope. It’s about the safety of the majority. Cloud computing is THE solution for it makes problems the size that can’t be ignored ;-)
Asking individuals to accepts responsibility is a losing strategy at this point. We need collective solutions so developers & start-ups can start using cloud based services that are safe.

[…] Today we are trusting the web with our most personal and important data, from private photos and social graphs to finances and key work documents. Our hesitation to share such information has dropped over the years as our trust in our favorite services grows. Yet all the while, the web is actually growing less secure, as sites are left open to new attacks that can spread easily and leave users…Read more » […]

James Grinter

Even if you don’t “trust the web”, someone else probably is on your behalf. Or, someone else you’ve had contact with will do something stupid that has an impact upon you. That’s the power of computer networks.

(Cross-site scripting attacks are, of course, merely attacks of the defensive programming stratagem “sanitise your input”. Just rather a sneaky one, where some thought they could safely sanitise all HTML.)

http://bojinov.org Hristo Bojinov

To add to the problem, many devices now feature multiple interfaces that can be used as alternative injection points into the browser. We call this cross-channel scripting (XCS) in a recent talk:

Or use a non-html parsing scripting solution. I remember when php would parse fake gif files and execute embed code skipping the binary headers.

Your much safer using something like C, Python, Perl or my favorite ScriptBasic. These scripting solutions are real programs that do what they are intended to do instead of parsing /executing whatever is passed their way.

Mike

C is not a scripting solution.

http://www.scriptbasic.org ScriptBasic

It is when you use something BCX Basic to C or BaCon Basic to C to produce fast, small CGI (compiled) scripts.

[…] at ‘cross-site scripting’ one of the latest ‘online security can-of-worms’. Click here to read the original […]

http://www.facebook.com/people/Angela_Hayden/507212615 Angela Hayden

I’m just a simple graphic designer trying to start an online audio tour business and it has been HELL! I can’t express in words how much I hate Dreamweaver, Notepad++, CSS, PHP, etc. I’m a starving artist so I have to do everything myself and I also wanted to host everything myself. Instead I’m having to pay E-Junkie to host my mp3 files. My hosting company can’t even send me instructions on how to stop someone from sending emails from my business account. My head is spinning from all the e-cart solutions.

AnyHoo, thanks for listening. I have to go produce 100 images in photoshop for another project. Oh yea, my shitty site is http://www.hereandthereaudiotours.com I’m editing the page now with a set-up css template using notepad++. I have much work to do.

Okay, now I’m crying. Damn it. And another thing, in the last year and a half I’ve lost data on 3 external hard drives. I’m going to bomb my office. I really have to go now.

ambert ho

“browser manufacturers themselves do not completely understand the issues involved, and in some cases are moving backwards (ie. the new IE8 is now allowing XmlHttpRequest across-ports)”

Curious, what’s the big deal with allowing XHRs to any port?

The API only allows you to initialize the xhr to make HTTP requests with HTTP headers (so it’s not like I can open an FTP request, or start arbitrarily talking SQL to port 3306) and even with the IE8 change it’s not like you can open connections to other servers – Same-Origin-Policy is still enforced, just not to the same port.

So I don’t really see how this makes the browser less secure – seems like it was just a feature added to better support SOAP, REST, etc. since some people are going to have their web services listening on nonstandard ports.

[…] was only three days ago that I wrote about the almost hopeless challenge of web security, specifically around new vectors […]

http://www.opsourcecloud.net Rick Lebherz

Good article.

I think the nature of the challenge isnt just with in IT and the Tech world. It comes down to human nature and pushing the limits of what is possible.

As long as someone creates something of value, someone else will be there trying to pick it a part and poke holes in it. Hopefully the intention is to improve and alert the community and not leverage this for personal gain. But many people are selfish creatures. All you can do is try and stay ahead of the curve.

Also along the same lines in case you missed it, OpSource is improving Cloud Security and performance to meet enterprise expectations and requirements. A multitiered architecture, firewalls and load balancing standard (not an option), dedicated private VLANs, Encryptions, SAS 70…yada yada yada…check it out