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.

stop the alert();

For nearly a decade, those of us in web security have been doing a disservice to ourselves and, more importantly, our customers. Like Pavlov, we've trained people to respond to certain stimuli. Rather than a bell, we've relied heavily on the alert() dialog box to prove our point--that cross-site scripting is possible.


And why shouldn't we (assuming we're not doing hardcore pentesting where we really need to abuse it)? It's easy to exploit, it's easy to explain, and most importantly: it's in your face.


I'm not saying everyone does it but... everyone does it. We've all proven our point, at one time or another, to a skeptical business person or developer by sending the trivial-but-hard-to-ignore link containing a <script>alert('Vulnerable+to+XSS' )</script> variant. Don't deny it, you know you have.


So what's the end result of all this alert() training? "There was no popup, therefore it's a false positive."  I have heard this more times than I want to admit. When I hear this, I have to sit back and wonder where we went wrong. When did that (business security consultant|developer|manager) become a dog salivating for another alert? When did I let it happen?


At this point you of course have to prove it's somehow dangerous, which means taking time to make the alert work or some sexier attack. Did the developers clobber alert() for some reason (Facebook), or does it need a simple tweak? Who knows... the point is, it takes time. The guy that can fix it didn't just look the source and say "oh crap, the kitchen sink is making it through unfiltered" simply because he didn't get smacked in the face with an alert box.


So what do we do? Well, there's no going back in time... but consider using other examples when you can. Liberal use of the <blink> and <marquee> tags with a "business has closed due to pending litigation" message or a redirect to a competitor's website will often do just as well. Or maybe someone should make an injectable version of jsAscii that replaces all the images on a page (that would be pretty sweet).


So stop demonstrating XSS with alerts and stop being lazy. Mix it up a little and give some different examples--in the end it will make all of our lives easier, our sites more secure, and just may stop that infamous developer who thinks the fix is to filter out the word 'alert'...

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.

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

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

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

Here
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
gave.

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.

JavaScript strings immutable in Rhino???

Update: Hmmm. I think I'm looking at the wrong thing. This needs more testing/tracing to see exactly whats going on.

Just a quick update from yesterday's post. It appears that Mozilla Rhino (a JavaScript interpreter written in Java) uses Java's String object to represent JavaScript strings inside of the engine. Here is the constructor from /js/src/org/mozilla/javascript/NativeString.java:

 69     private NativeString(String s) {
 70         string = s;
 71     }

This could be bad, depending on what people are storing in JavaScript strings (which are represented as Java String objects). Strings are immutable in Java (and many other languages). You as a developer cannot easily clear out the contents of the String object. As you manipulate a string, mulitple copies are made of its contents. For example consider this Java code:

String foo = "p@$$w0rd";

System.out.print("Your password in upper case is:");

System.out.println(foo.toUpperCase());

There are now two copies of the password string in memory, "p@$$w0rd" and "P@$$W0RD." Noted security expert John Viega has discussed disclosing sensitive data in memory in length.

Why is all of this an issue? Because the JavaScript language spec doesn't provide an information/warnings/guidance about what you should and should not store in JavaScript strings (and really they shouldn't). It's up the designers and implementors of JavaScript interpreters to explain how their interpreter handles data. However I don't now of a single JavaScript interpreter that does this. Rhino certainly contains no warnings that sensitive data should not be stored in JavaScript strings. To make matters more concerning, Rhino is not typically embedded in a web browser where client-side JavaScript strings shouldn't contain sensitive information anyway (yes, I know that web security readers just let out a laugh). Rhino embedded in other programs/projects where the types of data it could be processing are far more diverse than in a web browser and the probability that sensitive data will be present in JavaScript (and thus Java) strings is higher.

All and all, the Mozilla folks should probably modify Rhino so that it uses a StringBuilder Object instead of a String object to represent JavaScript strings. I haven't dug into SpiderMonkey, but hopefully they are clobbering character arrays with junk before freeing it. Interestingly, I just found this article describing situations where compilers will "optimize" memset() calls to override sensitive sting data. Its possible SpiderMonkey leaves sensitive data lying around as well even if they are trying not to!

[snarfs coffee]... wait, What are you doing?


While reading through an article about Firefox 3 on Security Focus today I snarfed my drink when I read the following passage:



The group also rewrote the Password Manager in JavaScript from C++ to eliminate memory errors, Schroepfer said.



Digging a little deeper I find an article talking about how OS keychain tools can interact with Firefox 3's JavaScript password manager. In the comments of the article is the following tidbit:



The JS portions mostly handle DOM interaction and file IO for
signons2.txt. The two main reasons for switching to JS are simpler code
and increased security (eg, no buffer overflows possible)
. Most of the
Firefox frontend is already JS, so this isn’t exactly a radical change.
But, in any case, the actual encryption of logins continues to be done
be a C++ component (using Triple-DES).




 There are numerous things about this that concern me:



  1. JavaScript code is *not* simple. It is highly dynamic, loosely typed, with late bindings. This means short of a syntax error, all your errors are runtime errors. Not fun to debug regardless of how awesome Firebug is. In fact, we have an entire chapter in our  Ajax Security book about nuances of JavaScript (variable scoping and declaration, oddly performing functions, deadlocks/race conditions/live locks with no mutexs, etc) that make it tricky to develop JavaScript. Dumping one language for another solely to improve readability of your code is admitting you are a poor software architect and, frankly, rather of lame.


  2. Moving to JavaScript because most of Firefox/chrome is JavaScript kind of makes sense. Moving to JavaScript from C++ to "fix" buffer overflows and memory problems is a horrible reason. You are admitting you are incapable of solving a very well known problem and the only solution was to move to a language/runtime that removed the problem for you.

  3. Is this JavaScript interface accessible from plugins or other chrome controls? Please don't tell me you just increased what can be done with Cross Zone Scripting attacks.

  4. As is pointed out in the comments of the second article, programs must be very careful when freeing memory that contains passwords. In C you can blast the buffer with junk before a free(). You have to be extremely careful with passwords in memory for managed languages like C# or Java where strings are immutable. JavaScript? No control what-so-ever over how string data is stored and destroyed. Does Spidermoney or Rhino handle JavaScript strings securely? Hmmmm...



All and all, this is a scary jolt first thing in the morning.

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.

Speaking at Shmoo

I’m really excited to be speaking at Shmoocon again and especially excited about my presentation this Saturday at 1pm. Javascript Malware for a Gray Goo Tomorrow focuses on the increased scope of damage caused by Cross-Site Scripting (XSS) vulnerabilities in the last year. The Web 2.0 revolution has been built on the back of standards compliant browsers and enhancements to the JavaScript language. This homogenous platform, coupled with JavaScript’s new features has enabled attackers to perform advanced attacks using XSS that were thought to be impossible even 2 years ago. Self-propagating XSS+Ajax worms, advanced keystroke and mouse loggers, port scanning, fingerprinting, and assaulting intranet applications, as well as stealing search engine queries or browser histories are now all components in an attackers toolbox.

The first part of my presentation will provide an overview of all these new advanced threats. Specifically, how this attacks work and how they can be prevented. In the second half I’ll discuss how JavaScript is capable of crawling and auditing 3rd party websites just like a traditional web scanner. As a proof of concept, I created Jikto, a web scanner written in JavaScript. Although I will not be releasing the source code of Jikto, I will be giving a full live demo and provide a detailed discussion about its methodology and architecture. The purpose of this public discussion and demonstration is to raise awareness of the danger of a XSS vulnerability and educate web developers and administrators on how to create websites securely. The biggest tragedy of all would be if a developer decides to put off fixing a XSS vulnerability because they weren’t aware of all the damage that could be done.

I really believe people are going to see some cool tricks, learn more about how attackers are using the often misunderstood JavaScript to perform sophisticated attacks, and leave with the knowledge to design, code and deploy secure websites. Hope to see you all there!
Search
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog

Featured


Follow Us
Labels
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.