Independent Study: Web Application Security

(This is one of a series of posts about papers I'm reading for an independent study with Prof. Evan Chang at the University of Colorado, Boulder. The format is similar to that of a review of a paper submitted to a computer science conference. There are already-published papers, so I'll be writing with the benefit of hindsight, especially when the paper was published at least several years ago.)

Last week and the week before, I read papers which analyzed and proposed solutions for injection attacks in dynamic languages. This week, instead of reading a paper, I'm digging around for security trends related to JavaScript in the browser and dynamic languages on the server. Not much seems to have changed since the Spectator paper was published. There are still JavaScript worms, and the attackers are still using fancy tricks to subvert the filters of the web site operators. Compare, for instance, these technical descriptions of the original MySpace worm and the quite recent Reddit worm. So all-in-all, not much is new. However, reading this reportfrom the Web Application Security Consortium, I did run across what is, to me, a new kind of attack — HTTP response splitting — which may warrant further investigation. I suspect it is the case that existing taint mode techniques can be appropriately applied to HTTP response splitting, but it would be worthwhile to verify.

Resources

For Dynamic Languages

Douglas Crockford's slides on JavaScript security
Ruby on Rails Security Project
Python Security Advisories


General Internet Security

Web Application Security Consortium
Security Focus
Common Vulnerabilities and Exposures
SANS Storm Center
US-CERT

To get a flavor of US-CERT data, here are 2009 current activity reports:

• January
• February
• March
• April
• May
• June
• July
• August
• September
• October

Feeds

Web Application Security Consortium feed
Security Focus feeds
Common Vulnerabilities and Exposures
SANS Internet Storm Center
SANS: @RISK: The Consensus Security Vulnerability Alert
US-CERT

File Under Very Useful

The Web Application Security Consortium has statistics (which appear to be actively maintained) on website vulnerabilities. The WASC describes the data as the result of "a collaborative industry wide effort to pool together sanitized website vulnerability data and to gain a better understanding about the web application vulnerability landscape."

For tracking web application (i.e. web app framework and web browser) security vulnerabilities, SANS's @RISK: The Consensus Security Vulnerability Alert seems to be quite useful. It compiles reports from a number of commercial security sources. Here's an example of the web application section of a recent report:

Web Application - Cross-Site Scripting

• 09.28.24 - Zoph Unspecified Cross-Site Scripting
• 09.28.25 - Microsoft Internet Explorer "javascript:" URI in "Refresh" Header Cross-Site Scripting
• 09.28.26 - Opera Web Browser "javascript:" URI in "Refresh" Header Cross-Site Scripting
• 09.28.27 - Google Chrome "javascript:" URI in "Refresh" Header Cross-Site Scripting
• 09.28.28 - Horde "Passwd" Module Cross-Site Scripting
• 09.28.29 - CMME "admin.php" Parameter Cross-Site Scripting

Web Application - SQL Injection

• 09.28.30 - Opial "admin/index.php" SQL Injection
• 09.28.31 - ConPresso CMS "detail.php" SQL Injection
• 09.28.32 - Opial "albumdetail.php" SQL Injection
• 09.28.33 - ClanSphere Multiple SQL Injection Vulnerabilities
• 09.28.34 - Siteframe "document.php" SQL Injection

Web Application

• 09.28.35 - Drupal Cross-Site Scripting, Code Injection and Information Disclosure Vulnerabilities
• 09.28.36 - phion airlock Remote Command Execution and Denial of Service
• 09.28.37 - art of defence hyperguard Remote Denial of Service
• 09.28.38 - Radware AppWall Source Code Information Disclosure
• 09.28.39 - ADbNewsSender "path_to_lang" Parameter Local File Include
• 09.28.40 - Siteframe "phpinfo.php" Information Disclosure

JavaScript

The advice everyone who knows anything gives to anyone who wants to be safer online is to use NoScript. I use it. You should too. But it's only for Firefox, not all the other browsers out there, and discretionary plugins only get adopted so far. That leaves a whole lot of browsers (many of which have unpatched vulnerabilities) running on the desktops and laptops of the world. Further, most Internet users aren't sophisticated enough to know when they need to enable JavaScript, and since there's not a WWW cop to enforce the unobtrusive use of JavaScript, it's just easier for people to allow JavaScript from every site on the web, which gets us back to square one.

A few weeks ago I reviewed a system for detecting and containing JavaScript worms which mentions the MySpace JavaScript worm. Here are some more recent incidents. The Reddit incident was only a few weeks ago.

2009
Somebody's made a javascript worm
source code for the reddit/firefox [sic] exploit

2008
JavaScript worm from late 2007 happily frolicking in 2008
JavaScript worm still spreading, infection origin unknown

2007
More on Orkut worm

2006
JavaScript worm targets Yahoo!

2005
I'm Popular
Technical explanation of the MySpace Worm

Buffer Overflows, Oh My!

Because they manage memory on behalf of the programmer, dynamic languages may be thought of being invulnerable to buffer overflow attacks. However, the runtimes of some dynamic languages are implemented in C, which is itself subject to buffer overflow attacks, so programs executing in such runtimes may themselves be vulnerable. This is illustrated by these Ruby, Perl, Python, and PHP vulnerabilities, all reported in 2008.

The same is true of JavaScript running in Firefox, Internet Explorer, and WebKit/Safari.