HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Ajax Security more than Increased Attack Surface

I got an email from Christ1an the other day asking me what Ajax Security was all about. I was just going to send him the table of contents to the book, but I thought it might be educational to see how the components of Ajax security relate, and where they come from. In Jeremiah's fascinating Web Application Professionals Survey less than 3% of people think there is nothing new about Ajax security which jives with the idea of Ajax Security acceptance.  And while over 2/3 understand that Ajax applications have an increased attack surface, many of the comments showed that some people believe Ajax security is just about an increased attack surface.



Let me assure you, if Ajax Security was only about an increased attack surface two things would have happened:



  1. Addison Wesley won't have asked me to write a 500+ page book about it

  2. Bryan and I would have finished a long time ago :-)



 There are many issues with Ajax Security and hopefully this piece will help people see the bigger Ajax Security picture.


 -Billy




Ajax
makes applications more responsive. It does this by allowing client-side JavaScript
to asynchronously fetch data from the web server without blocking user
interaction or refreshing the web page. This seems trivial, but it is not. Everything
about Ajax
security stems from this fundamental shift in application architecture
.




This shift means there must be code running on the client to
send these requests and process the results. So what is it talking to? Web
services running on the server which may or may not have been there before. Attack
surface grows, so at the very least developers have more inputs that need to be
properly secured. Anyone reading Full Disclosure or Secunia knows how well we
are doing in that department as is. But you already knew that, so lets more on.




Ajax application straddle the network and exists on both the server and the client. So what’s in that client side code? Variables names, return
values, string and numeric constants, data types, value ranges, proper program
flow based on which web services are called in what order and which interdependent
values. All good details about the inner working of an application. That black
box is looking a little gray. What’s more there’s an interaction between the
client and the server code and the attacker controls the client. Variable x is
used by web service 1 and web service 3, only its value can be modified by an
attacker between the two uses. An attacker can call the web services out of
order, manipulate the logic, etc. Reverse Engineering of client code is a
growing field, so don’t count on protecting your logic.




The fundamental unit of a traditional web app is a web page
written in HTML. The fundamental unit of an Ajax web application is arbitrary data. So
how do developers move data back and forth between client and server? With a data
transport layer! Sure they can use name/value pairs in a query string when submitting
data, but what about the format for what gets returned? JSON, SOAP, CSV,
Base64, binary data, and custom formats are all fair game. And with it come
the problems of implementing robust parsers and serializers while avoiding Denial
of Service attacks.




And lets not forget forgot all the programming errors of
writing an enterprise web application in still more programming languages. Functions like
String.replace(), String.substring() and RegExs don’t work in JavaScript the
way the work in most languages. It’s interpreted so everything except syntax
errors are runtime errors. And it’s asynchronous, so you can have race
conditions, deadlocks, livelocks, etc. Have fun QAing that. There are also odd
properties of JavaScript, like dynamic reassignment of functions. And you can
do a lot more then just JSON hijacking. Function clobbering, logical MITM, and
even real-time JavaScript environment monitoring to attack lazy loading are all possible and explored in the book.





If developers do silly things in client-side code now, what
do you think they will do when that client-side code actually does something
meaning for the application? It was pretty hard to have a database connection string
on the client in a traditional application because there was not much that
could be done with it. Ajax
applications are talking directly to data tiers and more business logic is
ending up on the client. After all, the client is
a place where code can execute so developers use it. They are doing more
and more on the client and even adding new features to the client. Now we have
client-side storage, which opens a giant can of worms. How is the data stored? It’s
it session or global oriented? How much can I store? What can I store? Do I have to serialize everything to a string? More data transport layer issues! Can it auto expire or is the develoepr responsible for clean up? Does it require user interaction to clear it? What
are the access controls? Which sites can access also access the data? Does exposing access to
the data expose my API as well? I’m looking at you crossdomain.xml! Cross
directory, cross domain, and cross port attacks, data integrity, and missing
data are all concerns of the developer. And every storage method, from cookies
to DOM Storage, to Flash LSO and IE’s userData do things differently. Too bad
Dojo.Storage abstracts away which is being used when you application must be
written with certain assumptions. Cooke storage = built in HTTP Response
Splitting vulnerability.




And speaking of enabling the client, look at offline Ajax frameworks like Google
Gears, Dojo.Offline, and Microsoft Sync. Now we are writing so much of a web
application in JavaScript that it can do meaningful things when it’s not even
connected to the Internet. There can be no isolation of business logic there. Code
transparency issues just got worse. Transparent local web servers to serve
cached resources that can be poisoned from other web apps (including poisoning
the JavaScript logic of the offline Ajax
app). Extended threading models that allow CPU intense JavaScript to run in a
separate thread (think Jikto, JavaScript port scanning, or XSS-Proxy running
all the time). JavaScript accessible SQL databases that can auto sync with the
server are even cropping up. Yes, with offline Ajax applications you can have client-side SQL injection attacks!




The widget craze is largely possible with Ajax and thus is
an important subject for Ajax
security. After all, could you imagine a web page with 9 widgets that all have
to do post backs with full page refreshes to exchange data with the server? The
web application would always be blocking and unresponsive with nothing but “Receiving
data from PageFlakes” on the screen! IFrame jails, cross widget attacks and
hijacking, degrading trust of 3rd party data sources, cross Flash
communication, data leakage, and crazy/bad stuff like JavaScript implementations
of RSA and SHA-256 are all covered. And let’s not forget mashups. You want to
take data from numerous untrustworthy sources and load them in your security
context? Cascading exploits, misplaced trust, and the Confused Deputy all play
out in that arena.




And what about all this rich content you are accepting? Web
2.0 is the world of user generated content after all. RSS feeds, sitemaps, Cascading
Style Sheets, JavaScript code snippets. Forget validating that a telephone
number is really a telephone number, how do we validate rich content? How do
you deal with phishing attacks and polymorphic JavaScript which evade widget filter
functions? What about attacks that exploit nothing but DOM styles? A magician succeeds
by fooling your eyes and nothing else; the same is true for presentation layer
attacks.




What native security features do the frameworks like DWR,
Dojo, Prototype, and ASP.Net Ajax provide? What do you have to implement
yourself? What features are on by default that you don’t know about? How does a
developer choose an appropriate framework? How do QA test an Ajax application when a textbox might contain
a SQL injectionable web service but the ODBC message is suppressed by the
JavaScript?




We’ve only just started to talk about what’s in the Ajax
Security
Book. There is still JavaScript malware, control flow exploitation, request
origin uncertainty and more. Hopefully this little taste shows you that there
is far far more to Ajax Security than some JavaScript eye candy and an
increased attack surface. Developer, QA professional, and hacker alike will all
find Ajax Security an enormously powerful resource to help design, build, test, and
hack Ajax
applications.

Comments
| ‎11-08-2007 09:34 PM
I'm starting to get bummed out about Ajax Security (the concept and the book). The Rough-Cuts version was only updated twice it appears, so I really don't know what you guys are up to. It almost seems like a disappointment!

I think you're reading Jeremiah's October survey data incorrectly. I read it as `almost 37 percent of the 140 professionals who responded think that Ajax adds new attacks'. I only answered `it adds new attacks' because I recall Jeremiah's JSON call-back attack against GMail and the subsequent paper on "Javascript Hijacking" from Fortify Software (Brian Chess, Jacob West, etc).

What the Javascript Hijacking paper doesn't explain well is that it's really JSON Hijacking... and has very little to do with Ajax/Javascript other than that JSON requires Ajax in their examples. The real vulnerability is a CSRF type of issue (you say, "Confused Deputy") with the way JSON is implemented. Of course, DWR has provided some protections against these attacks (it's the only Ajax library that even has the word `security' in their manuals/docs).

So I'm starting to buy into the "only a larger attack surface view", even though before I was convinced that Ajax did add "some new things".

You say, "Function clobbering, logical MITM, and even real-time JavaScript environment monitoring to attack lazy loading are all possible and explored in the book", which all sounds interesting - but how is this different than other weaknesses or attack-paths in modern software? It's not really... Ajax just makes things faster, stronger, better for attackers (i.e. increases attack surface). Everything you mention seems to be possible in other languages/environments, including inherited from Javascript.

There is a significant lack of tools in the Ajax space, especially for crawling Ajax or even looking for links or standard HTML/JS source grep. Sprajax just plain sucks, scanajax doesn't actually do what its name says it does, w3af only has trivial support for Ajax grep and is very immature and unstable, there are no static source analysis tools for Ajax (and only one language-specific IDE, Aptana), etc etc etc.

In your book, I see no mention of any Ajax "tools" besides FireBug - and maybe a slight mention of some `generic' Javascript malware obfuscators, decrypters, packers, etc.

Even in the software testing world there are only a handful of commercial and open-source tools that support this stuff. For security testing - Cenzic Hailstorm and IBM/Watchfire AppScan support Ajax in a native sort-of way, while HP/SPIDynamics WebInspect supports Ajax in a similar way as scanweb2.0's Urlgrep tool. For SQA testing, I'm sure HP/MercuryInteractive's QTP can probably choke on Ajax about as well as WebInspect... while the dominant tools being FrogLogic's Squish, PushToTest's TestMaker (well, free - and has the open-source TestGen4Web Firefox add-on), and what else...SilkTest? Actually there are quite a few tools here - http://www.aptest.com/webresources.html - but the new question is, "are any of them any good?".

Of the ones listed, almost all are capture-playback tools which require tons of setup. Using RBNarcissus or FireWatir - I could code a faster Ajax crawler in a few minutes, and as far as I understand - scRUBYt has scraping support for this sort of stuff as well. I really hope you're going to talk about these in your book - because this is what I'm most looking forward to hearing about.

Worse - it could be that Ajax is shadowed-over by the other RIA/RCP frameworks - especially Microsoft SilverLight and Adobe AIR, which are both gaining bookshelf coverage at Borders and Barnes and Noble much faster than books on Ajax or even web application security. By the time we add one more security professional who specializes in Ajax, we'll have built over a billion applications that have over a billion lines of code each - all that code will be copy-pasted code out of these books - and the same code will be copy-pasted code within code.

So, yes, I think Ajax security is a huge issue - but it's not ground-breaking as far as software weaknesses or new attack-paths go. Which I think was Jeremiah's point. Of course, his company's scanner doesn't support Ajax much at all, so he might be biased.
| ‎11-09-2007 08:43 AM
I would like to draw your attention to another alternative which is a paradigm shift for AJAX front ends. One should be aware that I am not, and do not pretend to be objective, never the less I believe that one can judge for himself. Visual WebGui is an AJAX frame work that doesn’t expose logic, data or open services on client requests and therefore is not as vulnerable as common AJAX solution. Worth a look at www.visualwebgui.com
| ‎11-26-2007 04:25 PM
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.