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 Book is published with strong buzz and reviews

Our Ajax Security book from Addison Wesley has been published! By now I'm sure everyone is tried of me talking about the book and its merits, so let's see what some of experts in the web security space are saying about it:

Andrew van der Stock The Executive Director of OWASP reviewed a draft of Ajax Security and here is what he had to say about it:

If you are writing or reviewing Ajax code, you need this book. Billy and Bryan have done a stellar job in a nascent area of our field, and deserves success. Go buy this book.

Is it just a re-hash of old presentations? No. The book breaks some new ground, and fills in a lot of the blanks in all of our presentations and demos. I hadn’t heard of some of these attacks in book form before. The examples improved my knowledge of DOM and other injections considerably, so there’s something there for the advanced folks as well as the newbies.

really liked the easy, laid back writing style. Billy and Bryan’s text
is straightforward and easy to understand. They get across the concepts
in a relatively new area of our field.

The structure flows pretty well, building upon what you’ve already learnt ... there is advanced stuff, but the authors have to bring the newbie audience along for the ride.

Billy and Bryan spend a bit of time repeating the old hoary “no new attacks in Ajax” meme
which is big with the popular kids (mainly because their products can’t
detect or scan Ajax code yet and still want money from you), and then
spend the rest of the book debunking their own propaganda with a
wonderful panache that beats the meme into a bloody pulp and buries it for all time.

Web security guru dre offers up this review of Ajax Security:

It’s quite possible that many Star Wars Ajax security fans will be calling Billy Hoffman, the great “Obi-Wan”, and pdp “Lord Vader” to represent the “light” and “dark” sides that is The Force behind the power wielded by Ajax.

The book, Ajax Security, covered a lot of new material that hadn’t been seen or talked about in the press or the security industry. The authors introduced Ajax security topics with ease and provided greater understanding of how to view Javascript malware, tricks, and the aberrant Javascript worms from a security perspective.

are some of the “new” concepts that I enjoyed most Hijacking Ajax apps,
Attacking Offline Ajax apps, Ajax proxy exposure of third-party
XML/JSON data.

I really enjoyed the suggested defenses against
“mashup” attacks as well as JSON API Hijacking. Without going into
detail (I don’t want to ruin the book and the authors’ hard work), I can say that the explanations are not only better than mine — but that the imagination and creativity for optimal solutions were clearly first and foremost in the authors’ intentions. This is really where their good intentions shined.

authors also did a great job ... exposing all of the intricacies of
Ajax, HTTP, HTML, and XHR abuse issues. They showed that with great
power comes great responsibility. The level of attack capability that
HTTP/XHR can muster is scary indeed.

You definitely don’t want to miss out on what they have to say about attacking ! There hasn’t been a lot of research that I’ve seen, and some of the attacks seem incredibly daunting.

comes the best part! I know that a lot of you are curious if the book
covers Samy. Of course it does! The book also covers the less exciting
but discussion-relevant Yammaner worm. I was very excited to read this
chapter, but also afraid of some of the “dark side” prescriptions it

I haven't seen it in physical stores yet, but
people who order from Amazon or directly from Addison Wesley have
received their copies only a few days after ordering. I cannot express
how happy I am that the book is getting such good attention. It's just
more proof of Ajax Security Acceptance in the industry.

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.


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

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

We’ve only just started to talk about what’s in the Ajax
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

Praise for Ajax Security Book

Bryan and I got to see the cover of our book Ajax Security before it went to the printers today. It included what is known in the industry as a praise quote, where someone who is famous in a certain space reads the manuscript and provides a quote for the book.

 Byran and I received the following quote from the father of Ajax, Jesse James Garrett:

"Ajax Security is a remarkably rigorous and thorough examination of an underexplored subject. Every Ajax engineer needs to have the knowledge contained in this book - or be able to explain why they don't."

Bryan and I know how detailed and complete the book is. We know how the industry now is accepting what we have been saying for 18+ months. But there is still something unbelievably refreshing when one of the most visible people in Web 2.0 developement annouces that everyone should own a copy of your book.

 Oh yeah!

Ajax Security Acceptance

Its time again for AjaxWorld, the largest Ajax conference in the US. Bryan and I are thrilled. AjaxWorld offered us back-to-back sessions so we can do a 90+ minute workshop on how to break into Ajax applications. We will not only hit the major themes like increased attack surface, code transparency, etc, but are also demonstrating some more advanced features such as control flow manipulation, reversing client logic, exploiting Offline Ajax applications, and Mashup/Aggregate hacking. All of which we are covered in our upcoming book, Ajax Security.

Sharp eyed readers will note that 90+ minute is a ridiculous amount of time. This is on par with how much time the keynote speakers and presentations are given. Normal speaking slots are only 40 or 45 minutes! AjaxWorld did this because, well, they love SPI. We have spoken at the every AjaxWorld held so far. We give solid presentations that developers can understand and they personally invite us back every time.

Which leads me to my point.

I think people are starting to get the message about Ajax Security. Lets use AjaxWorld as a barameter of Ajax Security acceptance. When we spoke at the first AjaxWorld, SPI's was the only presentation talking to developers about Ajax Security. That was 1 talk about security out of around 100 presentations. And it was packed. At the 2nd AjaxWorld, SPI talked about Ajax security, and was joined by another presentation on security given by Dan Cornwell of Sprajax fame. Sure there were a few other presentations that had the word "secure" or "security" in the title but these were mainly product pitches and none offered product agnostic security advice to developers about the risks they face. Thats 2 presentations out of 100+ talking about security.

Now we get to AjaxWorld West 2007 and there are 5 presentations about security and all of them look great. Brian Chess from Fortify, Joe Stagner from Microsoft, Byran and I from SPI/HP, Danny Allen from Watchfire/IBM, and Pothiraj Selvaraj from CGE. I am absolutely floored by the turn out. And its not just more security speakers at Ajax conferences. There are other indications that people are accepting Ajax Security. We are seeing a number of books on Ajax Security come out. Ajax frameworks are starting to implement security features natively. In some cases framework developers are reaching out directly to the web security companies that seem to get it. For example SPI has been to Redmond multiple times this year working with the ASP.NET and Atlas teams. We see security vendors and consultants who were in denial about Ajax have toned down the rhetoric. Now vendors from the scanner and source code analysis spaces are joining SPI on stage this year at AjaxWorld. We've gone from a 20 something with long hair talking about Ajax security to CTOs and CEOs, and VPs spreading the message. And that is extremely satisfying.

I suppose if anything, AjaxWorld 2007 is a nice breath of fresh air. A cause SPI has been championing for nearly 2 years now is becoming more mainstream and finding acceptance in the Security and Development communities. I welcome my friendly competitors to the party, even if they were a little late and got lost along the way. :-) Because at the end of the day, more smart people working on tough problems helps everyone.

And thats the kind of thing that makes me want to go to work everyday.

Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog


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.