Netcraft is reporting today about a phishing attack leveraging XSS  against an Italian bank. From the article (emphasis mine)

An extremely convincing phishing attack is using a cross-site scripting vulnerability on an Italian Bank's own website to attempt to steal customers' bank account details. Fraudsters are currently sending phishing mails which use a specially-crafted URL to inject a modified login form onto the bank's login page.

This attack highlights the seriousness of cross-site scripting vulnerabilities on banking websites. It shows that security cannot be guaranteed just by the presence of "https" at the start of a URL, or checking that the browser address bar contains the correct domain name.

Cross-site scripting vulnerabilities on SSL sites also undermine the purpose of SSL certificates - while the attack detailed here injects external content via an IFRAME, it is important to note that a malicious payload could also be delivered solely via the vulnerable GET parameter. In the latter case, any SSL certificate associated with the site - included Extended Validation certificates - would display a padlock icon and apparently assure the user that the injected login form is genuine.

If this sounds familiar, it should. I gave a talk at Toorcon 2005, the Phuture of Phishing. This focused exclusively on current phishing techniques and defense and how XSS vulnerabilities takes phishing to a completely new level. From the slide 24 of the preso:

• Current Phishing attacks revolves around deceiving the user into think a website is a different website.
• Current Phishing defense revolves around:
• Applications preventing HTML from deliberately hiding functionality or actions of links and script
• Determining fundamental stats about a site to see if it truly is the site it claims to be
• But what happens if the phishing site was the actual website?

Exactly! XSS vulnerabilities turns a banks website into the phishing site. SSL certs, reputation systems, DNS checks, blacklists, and other phishing defenses utter fail to handle XSS+phishing.

I'm certainly not the only one banging this drum. Jeremiah Grossman predates me by a few months with a good presentation about XSS+phishing. I've had a friendly battle running with Lance James for a few years now about the role of local malware vs. website XSS in the future of phishing.

This certainly isn't the first XSS+phishing attack reported in the press. It wouldn't be the last. Hopefully attacks like this will raise awareness about the dangers of XSS. Remember, XSS isn't just cookie theft, or just key logging, or just page vandalism; XSS is complete client-side code execution!

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 [the Presentation Layer]! 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.

IBM/Watchfire released their analysis of Larry Suto's web scanner comparative review, which was released in October.  If you recall, we wrote one as well.  IBM/Watchfire questioned Suto's methodology just like we did; they also found discrepancies between their own testing and the scan files Suto provided them (yes, that's right--Suto's reported results apparently don't match Suto's own scan files).  Interesting is their discussion on how vulnerabilities are counted (issues vs. instances), and their knowledge of how NTOSpider apparently counts its findings (it counts instances), causing a higher/inflated vulnerability finding count.

Overall, Suto's analysis illustrates an important concept: testing and product comparisons are not trivial to perform.  You need a sound methodology, and you need to make sure your numbers and math make sense.

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!

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

RegEx Validators are handy for implementing Whitelist input validation (our DevInspect product has a library of a hundred or so) so it pays to see what they  actually do under the covers. The following code is from the class System.Web.UI.WebControls.RegularExpressionValidator which implements the RegEx Validator in ASP.NET. I'm looking at version 2.0 of the .NET framework. The EvaluteIsValid() function is what actually determines if an input matches the allowed regex:

protected override bool EvaluateIsValid()
{
    string controlValidationValue
        = base.GetControlValidationValue(base.ControlToValidate);

    if ((controlValidationValue == null)
        || (controlValidationValue.Trim().Length == 0))
    {
        return true;
    }
    try
    {
        Match match = Regex.Match(controlValidationValue,
            this.ValidationExpression);
        return ((match.Success && (match.Index == 0))
            && (match.Length == controlValidationValue.Length));
    }
    catch
    {
        return true;
    }
}

Lets look at the first if statement closely. The conditional is a logical OR, so we can treat each part as individual if statements. The code says "if the control value is null, the input passes this validator." The control value can only be null if the control doesn't exist, and chances are you would have had a compile error. Either way, I don't really care about this statement.

The second part of the if statement is interesting. If the trimmed value of the input has no length, the input passes validation. This is a little weird. Trim() removes all leading and trailing whitespace from a string. Things like tab, carriage return, linefeed, etc. The full list is in the .NET String Class documentation. So input consisting of nothing but whitespace passes any ASP.NET RegEx Validator, regardless of the regex. This is counter-intuitive. If I set a RegEx validator to use [a-zA-Z]+ whitespace-only input should not get through. More interesting is that characters like vertical tab, CR, LF, and form feed are often interpreted as delimiters, so input with nothing but whitespace could in fact do some weird things in a backend app.

Moving along, we see that the input is matched against the supplied patterned. If a match is found and that match begins with the first character of the input and the length of the matched text is the same as the length of the input, then the input passes the validator. Essentially, this is saying that the entire input must match the regex defined. This is good and bad. Its good because I often see developers define a whitelist and forget to use the the "start position" and "end position" characters (^ and $ respectively). Consider an simplified regex for valid email address [a-zA-Z0-9]+@[a-zA-Z0-9]+\.[a-z]{3}. (This RegEx excludes valid email addresses and is just to illustrate the point). This RegEx matches email addresses like billy@hp.com. It also matches email address like <script>alert("XSS")</script>billy@hp.com because the regex doesn't force that the entire input must match the regex pattern, but merely some subset of the input matches. The RegEx should be ^[a-zA-Z0-9]+@[a-zA-Z0-9]+\.[a-z]{3}$ where ^ and $ force the entire input to match.

I often see developers make this mistake and in a way Microsoft is solving the problem by saying "Developers are stupid we will also match the entire string so they don't have to." Ok, I like erring on the side of caution, but this prohibits advanced users from using $ and ^ appropriately. Microsoft completely usurps the developer and removes the choice from their hands. You have to use a CustomValidator class to implement RegExs which utilize just ^ or $. However I can live with this because it undoubtedly saves the Internet for silly mistakes.

A final thing that caught my eye was the try ... catch ... block. If the Regex.Match() call throws an exception, the validator returns true indicting the input is safe. This means in event of an error, the validator fails open instead of failing closed! Deciding when applications/appliances/software/hardware/structures should fail open or fail closed is way beyond the scope of this post and the answer is almost always circumstantial based on the individual situations. Quick, should firewalls fail open or closed? Fail open? Well then an attacker knocks out your firewalls and its open seasons on the FTP servers and Samba shares inside your organization. Fail closed? Thats a nifty DoS you built into your network infrastructure now isn't it? when should input validation fail open or fail closed? Again depend, but my gut tells me it should fail closed more often than it fails open.

Ignoring how it should fail is moot if you can't make it fail. How can we make Regex.Match() throw an exception? Null strings would do it, but a brief glance at the code paths in ASP.NET seems to prevent that from occuring. Invalid RegEx syntax would do it, but you get compile-time problems or an immediate runtime error during the Page_Load event, long perform input is validated. So RegEx Validators in ASP.NET fail open if there is an exception, but I can't seem to get it to exception in an exploitable way to sidestep input validation. Perhaps someone else can take a swing at it :-)

[Update: PDF attachment download is working now] 

In October 2007, Larry Suto released a case study entitled “Analyzing the Effectiveness and Coverage of Web Application Security Scanners,” available for reading at http://www.stratdat.com/webscan.pdf.  The study compared the results of three commercial web application security scanners, including WebInspect.  There has been much discussion in the industry about this study (for a good example, see the “Coverage and a recent paper by L. Suto” thread at http://lists.immunitysec.com/pipermail/dailydave/2007-October/thread.html).  Part of the discussion focuses on Suto’s questionable methodology & conclusions relating to application coverage, and the vagueness of his results.

Since any solid science experiment should be repeatable, SPI Labs set out to re-create Suto’s study to reasonably verify his conclusions and methodology.  In doing so we discovered significant discrepancies between our results and the results reported by Suto.  Attached is our final report (Suto_review_FINAL.pdf), where we indicate the results we received when we tested the same applications.

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 3^rd 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.

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!

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.

When JSON hijacking was first discussed and demonstrated in 2006 and 2007 by Whitehat, Fortify and others, all of the proof of concepts used Mozilla specific JavaScript extensions like setter or __defineSetter__. This led many people to believe that these vulnerabilities only existed in Mozilla-derived browsers like Firefox because only those browsers supported extensions like __defineSetter__. Brian Chess tempted me when he made an offhand comment in Fortify's paper that there was a way to performing hijacking against IE. However after an email exchange I learned that Chess et all were unable to actually hijacking IE.

When performing some research for my upcoming Ajax Security book, I wanted to see if I could find a way to perform this attack against users of IE. I started poking at this quite a bit and learned some interesting things. First of all, I needed a way to hijack the Array() and Object() constructor functions in a non-Mozilla specific way. I was able to expand on Joe Walkers approach and came up with the following:

function Array() {

    var foo = this;

    var bar = function() {

        var ret = "Captured array items are: [";

        for(var x in foo) {

            ret += foo[x] + ", ";

        }

        ret += "]";

        //notify an attacker. Here we just display it

        alert(ret);    

    };

     setTimeout(bar, 100);

}

We use anonymous functions and a closure to persist scope for our setTimeout() call. Renaming this function to Object will hijack the object constructor. Awesome. So I have a proof of concept that doesn't use Mozilla specific extensions. This should work in IE right? The answer is no, it still only works in Mozilla. To understand, think about the two conditions that make JSON API hijacking possible:

1. JSON array literals and (properly enclosed) object literals returned by Ajax endpoints are valid JavaScript
2. The JavaScript interpreter automatically calls the array or object constructor when it encounters the appropriate literal.

Of these two reasons, there is nothing that can be done about #1. Indeed, JSON was deliberately designed to be a subset of JavaScript to ease its parsing through the use of the eval() function. However, reason #2 is specific to each browser’s JavaScript interpreter. The authors tested the major browsers and concluded that the JavaScript interpreter in Mozilla derived browsers is the only JavaScript interpreter which invokes the array or object constructors when a literal is encountered! Only by literally calling the constructor function with the new keyword such as var obj = new Object(); or  var array = new Array(); will other browser actually invoke the appropriate constructor!

So it turns out that Mozilla derived browsers (such as Mozilla, Firefox, Netscape, IceWeasel, etc) are still the only browsers vulnerable to JSON hijacking, but for a completely different reason that previously believed!

While checking my email this morning, I suspected that yet another message eluded my SPAM filter.  Much to my surprise, the subject line "Your TigerDirect Account Update" from 'TigerDirect@promo.tigeronline.com' was legitimate.  Unfortunately, reading the message was more troubling than the contents of many other SPAM messages I routinely receive.  Within this message, I'm told that "in an effort to improve security, we have eliminated certain previously allowed characters for use in the creation of a password. (Example: ><@')." What's even more troubling is the next line: "Our records indicated that one or more of these characters were used in your password."  As indicated by their "records," it's apparent my password is stored as plain text or, at a minimum, in a state that can be reversed to reveal the actual password composition.

Click on the thumbnail below for the full message:

 At first glance, there are several things wrong with this scenario:

1. This email correspondence actually alerts users to the fact that the security level has been reduced, not "improved" or otherwise strengthened.
   
2. Secure storage of confidential or sensitive information (in this case "password") is absent or inadequately implemented.  If any attacks are successful and allow access to the main "records" repository, user information is vulnerable to compromise.  If this is incorrect and all information really IS stored securely, I'd like to know how my password was deemed "non-compliant" with the "improved" security policy.
   
3. After resetting my password, it's apparent that there is no password policy (beyond 4-12 characters).  The user is permitted to supply the password "pass" with success.

1. First and foremost, store sensitive information as a hashed value; never store sensitive information as plain text.
   
2. Enforce the use of secure passwords using the following criteria:
• Minimum password length between 7-12 characters.
• Set a minimum number of occurrences of Upper- and Lower- case characters.
  
• Set a minimum number of occurrences of numeric and special characters.
3. Implement an incremental delay or temporary account suspension period after a series of unsuccessful login attempts.
   

Resources:

"Preventing a Brute Force Attacks"

http://www.spidynamics.com/spilabs/education/articles/brute-force.html

"Selecting Secure Passwords" (While this link mainly applies to OS password policies, the general theory is the same).

http://www.microsoft.com/smallbusiness/support/articles/select_sec_passwords.mspx 

The Apple iPhone’s Safari web browser has a special feature that allows the user to dial any phone number displayed on a web page simply by tapping the number. SPI Labs has discovered that this feature can be exploited by attackers to perform various attacks, including: 

• Redirecting phone calls placed by the user to different phone numbers of the attacker’s choosing
• Tracking phone calls placed by the user
• Manipulating the phone to place a call without the user accepting the confirmation dialog
• Placing the phone into an infinite loop of attempting calls, through which the only escape is to turn off the phone
• Preventing the phone from dialing 

These types of attacks can be launched from a malicious website, from a legitimate website that has Cross-Site Scripting vulnerabilities, or as part of a payload of a web application worm. 

For example, an attacker could determine that a specific website visitor “Bob” has called an embarrassing number such as an escort service. An attacker can also trick or force Bob into dialing any other telephone number without his consent such a 900-number owned by the attacker or an international number. Finally, an attacker can lock Bob’s phone forcing Bob to either make the call or hard-reset his phone resulting in possible data loss. 

It appears that the source code to Jikto is in the wild. I suppose it was only a matter of time, even though as you will see SPI to extreme steps to prevent this from happening.

As my Shmoocon presentation slides discuss, Jikto bypasses the "Same Origin Policy" by using a proxy website like the-cloak, proxydrop, Google Translate, etc. This allows Jikto's code and the content of 3rd party sites to be loaded into the same security domain (ie the proxy sites), and thus read the responses. I believe pdp of GNUCITIZEN first discussed this and I based much of Jikto off his work. The consequence of this means that Jikto's code had to exist somewhere on the public Internet when I did my demo. Worse, when I got to Shmoo I saw that I didn't have a hard connection to the Internet, only wireless. This means anyone in the audience sniffing traffic would see where Jikto was and get a copy. Obviously I couldn't let that happen.

Instead I VPNed into SPI. This created an encrypted tunnel. I then remotely connected to my Desktop machine at work and did the demo from there. This means no one in the audience could sniff traffic and see where Jikto was stored. The problem is if someone watched very closely they could see the URL of where Jikto's code was. I ran all my traffic on the work machine through a proxy to show all the requests Jikto was making. The first request would have been to grab Jikto's code. Someone could have seen the URL and grabbed it.

Which is exactly what happened! A guy named LogicX grabbed a copy this way and posted it on Digg just a day after Shmoocon. However I contacted LogicX and asked him to take it down. I'm thankful he did. However, it seems someone else grabbed either his copy before it was removed or grabbed the code themselves at Shmoocon just like LogicX did.

The long and short of all of this is Jikto's code is in the wild. Regardless what you might have heard, SPI didn't leak it. Even LogicX admitted he snatched it because he got lucky. I suppose it was only a matter of time.