Archives

SecuirtyFocus has a decent article entitled Ajax Security Basics. A sample:

A second challenge relates to the difficulty involved in securing the increased attack surface. Ajax inevitably increases the overall complexity of the system. In the process of adopting Ajax, developers could code a great number of server-side pages, each page performing some tiny function (such as looking up a zip code for auto completing a user’s city and state fields) in the overall application. These small pages will each be an additional target for attackers, and thus an additional point which needs to be secured to ensure a new vulnerability has not been introduced. This is analogous to the well known security concept of multiple point of entry into a house: the difficulty involved in securing a house with one door as compared to securing one with ten doors.

Good basic explanation of Ajax, and the new security vulnerabilities it exposes. The article also points out some pitfalls for current webapp testing methodology:

Applications may periodically send requests to the server to update information on the web page. For example, a financial application may use the XHR object to update parts of the web page that display current stock market information. The tester may not be aware of this process happening in the background if they do not catch the request at the right time, since there may not be visible links or buttons to suggest to the tester that there are requests being made in the background.

Well worth checking out.

Technorati : ajax, security

A number of readers have noted that XMLHttpRequest can only communicate back to the same host that served up a page. This is true. We’ve all played around with XMLHttpRequest to see if we could make it break. Barring browser bugs, even with iframe and document.domain hacks there isn’t much you can do. You can use the super twin powers of Flash to do cross domain scripting in some cases, but even that has its limitations. So we’re safe, right?

As I pointed out last week, sites that allow for the persistence of executable artifacts — Javascript scripts and Flash files — can provide a leading wedge for AJAX worms and viruses. Many of these same sites have various forms of messaging, such as email. If you can push the buttons on these apps, you don’t have to make cross domain XHR calls at all. So, is an application like Yahoo or Google mail “scriptable” enough to allow this sort of subversion?

I know that reading through code like this

may make you feel confident that no one could decipher the inner workings of Gmail, but remember the old cracker war cry: “Security through obscurity is no security at all.” What man has compiled, man will also decompile — the Google Web Toolkit will give up its secrets.

With this in mind, I would be much more at ease if all of the various google applications I use — maps.google.com, spreadsheets.google.com, mail.google.com, and the various apps under www.google.com — didn’t all have single sign-on and the same google.com domain. It makes for a better experience, to be sure, but I’m pretty certain I don’t want someone mailing my spreadsheets to a compromised mailbox.

In the olden days, a popup browser window that started behaving strangely was a dead giveaway that foul play was involved. These days there is no window or status bar message and email may be going out in your name that you don’t even know about.

Over at Simple Thoughts, they disect a Flash/AJAX worm that has been laying waste to MySpace.

The unnamed worm isn’t malicious but the Shockwave Flash (.swf) file containing the payload embeds JavaScript into the profile of any MySpace user who views the .swf file. This can easily replicate Samy is my friend worm without breaking a sweat.

This javascript code would then be interpreted by any user who visited the site, allowing sensitive data to be stolen, such as a hash value required to carry out operations as a user, and performing operations on behalf of that users (without consent obviously). Currently, that access is being used only to spread the JavaScript code to other profiles on the popular social network site.

They go on to describe how this worm, if malicious, could be used to compromise MySpace security and a user’s Office applications. Defanged (commented) Javascript is included.

It’s fair to say that this is just the beginning of these worms/viruses. The fundamental security situation in the browser hasn’t really changed — the same sort of mischief that could be done in 2004 or 2002 can be done today. So what has changed? At least three things as I see it.

1. Web 2.0 sites now persist Javascript and other executable online artifacts. We all know that a Word or Excel file from a buddy must be treated with caution. We have no such expectations when it comes to their MySpace profiles or plain text emails. It’s this persistence of executable artifacts that turns a malware into a worm, flowing from one user to another with Web 2.0 haste.
2. Our guard is down. If in 1989 anyone outside of a University campus had found a piece of software contacting all manner of remote computers and transfering data, they would have shut it down immediately. Now we don’t even blink when our browser secretly accesses other web sites via XMLHttpRequest. How to identify malicious activity when it doesn’t look all that different from normal AJAX activity? That’s sort of like the old Mac virus detection tools complaining about a compiler because it tried to modify a resource fork of a file. It’s about context.
3. Although Flash, XMLHttpRequest, browser extensions and rich Web 2.0 apps haven’t really changed the basic security picture for browsers, in combination they can lead to unforseen vulnerabilities. This latest worm simply demonstrates how inching the security door open in Flash and Web 2.0 at the same time can lead to trouble. When you design webapps for security, don’t assume a pristine client environment. Assume the worst and design accordingly.

I don’t have any solutions to these problems other than “don’t use flash or AJAX.” I’d be interested to hear your thoughts on this topic. Comment away.

Not sure if this is a real security issue or not or if the folks at Zabbey are just getting all bent out of shape about nothing.

While developing Zlap I
accidentally ran my test HTML file from my local machine. I was using
the XMLHttpRequest(), commonly used in AJAX software, that is built
into FireFox. The request I was making was to a PHP file that was also
on my local machine and it returned the full contents of said file.
Upon further examination I discovered I could pull any file from any
directory and have it displayed on the machine. I also tried to
replicate this after uploading the test file to my server, luckily it
failed.

What’s the big deal? I can’t remotely execute the file so we’re all
safe. Well sort of. If I can get you to open a perfectly safe HTML file
on your machine I can access your entire system. That’s right I can get
the Directory structure, the files and all the contents of those files.

I can execute this script without you knowing. I can upload the
contents of files to my server without you knowing. All I need to do is
get you to run a simple HTML file.

Hmmm, seems like correct behavior. Am I missing something?

Via Ajaxian we get an object lesson in the dangers of exposing business logic in the browser:

Beau Hartshorne of Snipshot (formerly Pixoh) says “massive chunks” of Cellsea code are identical to Snipshot. “This is not an accidental inspiration. Check out the cropping code, the resizing code, and so on. We’ve also noticed that portions of their website are also stolen directly from ours … We are contributors to MochiKit open source project. However, the code in question is proprietary and was taken directly from out site.”

Can I say “I told you so?” I’ve blogged about the danger of Ajax and Leaky Business Logic before. What is the danger here and the lesson the be learned?

• Don’t put your crown jewels in the browser. See if you can’t lock a fair bit of your business logic on the server side by using a server-side component framework like Echo2 or ZK.
• If you’re going to deploy meaningful applications in Javascript, do what people have been doing with script source code for decades: obfuscate. You can do something simple like renaming all of your variable to one or two character names, or you can use a code generation framework like GWT or Morfik that produce unreadable code from the beginning. Be forewarned that code generators can be vulnerable to decompilers — in short, if someone knows how GWT generates it’s code, you could possibly reverse the process and produce the original source code.
• Build in anti-theft mechanisms. This could be something as simple as a method that checks to see that the url the application is running on is the correct one, otherwise display a nasty message. You could make this as tricky and complicated as you like, all the way to encrypting big chunks of code with the website url and only decrypting them at runtime.
• Hold out for “byte compiled” Javascript.

A combination of all of these may be what we end up with. I’m not sure I’d want to run any script in my browser, though, that I can’t understand. Still, you would hate to be the victim of code-theft as has apparently happened to Snipshot.

How similar are these two programs? Well, Cellsea offers a bunch more functions, but they do look very similar, both in terms of the UI and the underlying code. The original Snipshot is here and the knock off here. You be the judge.

If you are really hungry for a good AJAX image editing app, the best of the bunch of them may be Phixr, which gives you preview, the ability to marquee select for certain operations, etc. Slick, even if the UI is a bit jumpy.

Update 3: Eric Pascarello has a brief blog entry describing the mechanisms by which the worm works. If you’d like to look at a defanged version of the code, it is here.

Update 2: I’ll save you reading all the way to the bottom. This blog entry
over at the Washington Post seems to take the view that users of Yahoo
Mail Beta (the AJAX version) are in fact not vulnerable to the critter. The fix is apparently to migrate to Beta. Like I said, these reporters often scramble the facts.

—

Looks like we have our first AJAX-related security hole. From the InformationWeek article:

Yahoo Mail relied on a JavaScript function in connection with uploading
images from a message to their mail server. Yahoo Mail made limited use
of Ajax to spur interactions between the mail user and Yahoo’s servers.
The Yamanner worm exploited one of the few JavaScript functions that
Yahoo Mail didn’t already screen out, the ability to execute JavaScript
in connection with directions to upload an image from a user’s mail
message. The worm substituted its own JavaScript commands where the
image-handling code was meant to go.

[...]

Yahoo Mail is displayed in the user’s browser Window, and browsers are
designed to execute any JavaScript they find in an HTML page or
message. As Yamanner recipients opened their messages, there was no
outward sign for the user that anything was amiss. The Yamanner worm
didn’t need an image to be included with a message to do its work. The
JavaScript executes in background, the browser performs no checks on
whether it is performing the expected function or not, and the worm
shows no telltale of its activity on the user’s screen, except a
possible slowdown in other activities.

In addition to ordering the user’s computer to query the Yahoo
mail server for the user’s address book, generate a message and send
them out to each name in the address book, Yamanner also captured the
addresses and uploaded them to a still unidentified Web site. By doing
so, it was building an email list with many thousands of names that
could be sold to spammers, note Web security experts.

The reported flip-flops between "worm" and "virus" in the article. I know from personal experience that reporters can get these things a little mixed up, so I’ll try not to take the breathless tone of the news article.

What exactly did this "worm" do? Not a whole lot of information out there yet. Was it simply that they uploaded a Javascript file instead of an image? Then the only way this was an AJAX vulnerability is that AJAX apps cut functionality into nice little chunks ("send message", "delete message", "view message", etc.) that can be accessed by the browser without the user knowing about it. So, nothing really new here, other than an example of cross site scripting. Stay tuned.

Update 1: Symantec has a security response here.

JS.Yamanner@m arrives on the compromised computer as a Yahoo! HTML
email containing JavaScript. If the email is opened within Yahoo! Mail,
it performs the following actions:

1. Exploits a vulnerability in the Yahoo! Mail service and executes a script.

2. Scans emails in the personal folders of the Yahoo! Mail
   account. The worm gathers email addresses that contain @yahoo.com and
   @yahoogroups.com domains.

   Note: The personal folders are email folders in the currently
   logged in Yahoo! Mail account. These include folders such as the Inbox,
   Sent, and any custom-named folders in the account.

3. Sends a copy of itself to the email addresses gathered. The email may have the following characteristics:

   From: Varies
   Subject: New Graphic Site
   Message Body: Note: forwarded message attached.

4. Redirects the Web browser from Yahoo! Mail to the following Web site:

   [http://]www.av3.net/index.htm

5. Sends the list of gathered email addresses to the above URL.

I came across an open source AJAX security scanner called Sprajax. From the Denim Group’s press release:

Sprajax is the first web security scanner
developed specifically to scan AJAX web applications for security
vulnerabilities. Denim Group, an IT consultancy specializing in web
application security, recognized that there were no tools available on
the market able to scan AJAX. AJAX allows web-based applications a
higher degree of user-interactivity, a feature with growing popularity
among developers.

Denim Group developed this innovative tool that
will revolutionize security assessments by providing a more thorough
diagnosis of security vulnerabilities within the AJAX code that other
web security scanners are not designed to read. The software then
produces a report of possible weaknesses for developers to remedy.

It’s Open Source, so I decided to download it and see what the hype was about. First, the application is written in C#. Second, you will need SQL Server to get it to run as the results are stored in SQL Server and are pulled into reports using stored procedures. Finally, the application doesn’t do all that much.

The application takes an application URL as a parameter and has three main functions.

• You can “footprint” the application, i.e. scan it for Javascript files and web services.
• You can “fuzz” the application, i.e. pass garbage into the web services to see if they will barf.
• You can display the results of the previous two functions.

Essentially, the footprint function spiders the application, detects the framework used, finds Javascript files included, and discovers web services used. The fuzz function uses those discovered web services and passes some garbage into them and sees if they returned error conditions. There are just a few problems with this tool, however:

• The tool only detects the Atlas framework. No Dojo, DWR, etc.
• It only detects SOAP web services used by the Atlas framework. No REST, no framework specific calls.
• It doesn’t scan the Javascript files for XHR calls, another place to find calls back to the server.

The fuzz function only tests robustness and in a fairly limited way, i.e. will the app go belly up when you pass in garbage data. Typically, security scanning tools test for known exploits of web application frameworks, a much more useful approach.

Finally, consider that many AJAX frameworks make use of dynamic XHTML and Javascript to drive content and navigation. This tool just sucks in the content and looks for URL’s. It wouldn’t find even one link in an Echo2 application, for instance.

Overall, there isn’t much here. It has the feel of something that a journeyman programmer put together over a weekend. I applaud the Denim Group for releasing an Open Source tool, but the hype in their statement is wildly inaccurate. You can likely write something in Perl in a few hours that would do all of this and more.

Lots of articles from eWeek broach the subject of AJAX and security but give few answers. The most insightful quote from the article is from the Dojo man:

Panelist Alex Russell, co-founder and project lead for The Dojo Toolkit, a popular AJAX framework, said, “It’s worth noting that the fundamental problems with browser security and Web application security haven’t changed in five years—most rely on a single root of trust, and AJAX doesn’t change that. Wider spread use of cross-domain content distribution,” which is not new with AJAX, is part of the issue. “The short version is still, Don’t trust the client.”

Right on. But beyond “nothing to see here…move along, move along,” can we at least categorize security concerns and explain how they might apply to AJAX?

The security issues, as I see them, fall into two distinct categories: end-user and server. End-user issues revolve mostly around privacy. A user wants control over what information is revealed to third parties. The server issues, on the other hand, revolve around exposing services that a malicious user can exploit by subverting the client. (There are hybrid versions of these, such as third parties launching attacks on sites using cross domain content, etc.) AJAX has added a wrinkle to both of these issues.

On the client side:

• XHR has made it difficult for the user to know whether information about their behavior is being transmitted back to the server. Solution: give users a way of seeing what is happening with XHR and other “invisible” communications.
• It is easy for developers to overlook the need for SSL or some sort of encryption when confidential information is sent back to the server. Solution: Give the use better insight into how information is about to be transferred.
• Larding in new functionality into the browser raises the chance that security holes might be opened up. Solution: decouple the browser from the OS (IE) and institute a sandbox approach. Don’t hold your breath for this one.

Should we give the user more control over XHR, i.e. give them an option to disable certain features of the browser? With the increased complexity of these apps, even tech-savvy users might find it difficult to evaluate the security of the application.

On the server side:

• Ad-hoc code – We’ve learned to protect ourselves from things like injection attacks and the like on the server side through the use of webapp frameworks. Opening up lots of little services using ad-hoc AJAX tools can lead to repeating these mistakes. Solution: consider using a server-side component GUI framework like Echo2 or ZK to avoid this issue.
• Reliance on too much business logic in the client. No matter how much you obfuscate your code, it is still accessible to the client. This is the pitfall with client-side component GUI frameworks like Tibco GI and OpenLaszlo. Solution: you can try and fight against this by making the services they access as simple as possible and dependent on cryptographically secure session information. I just wouldn’t do anything mission critical with this.
• Application complexity – It used to be that if someone compromised your site, they would deface it, install a rootkit or grab some credit card numbers. Now, a cracker might instead modify your AJAX application to send malicious Javascript to the client. Since “view source” ain’t what it used to be with DHTML and eval’d Javascript, this sort of compromise might be hard to detect. Solution: regular regression testing against the app is probably the best you can do.

The Open Web Application Security Project has some good resources on webapp security, but they’re a little bit behind on AJAX. One of their suggested approaches that I can heartily recommed is using modsecurity, sort of a stateful firewall for webapps.

A reader pointed out this blog entry from Infoworld, Mercury: AJAX has its drawbacks. It’s from the middle of April, but it is still worth responding.

“AJAX is incredible where people are starting
to adopt it and it immediately causes a lot of problems because it’s
not very structured,” said Rajesh Radhakrishnan, vice president of
Application Delivery at Mercury. Several Mercury executives met with
InfoWorld editors at Mercury offices in Mountain View, Calif. on
Tuesday morning.

“We’ve seen tons and tons of problems,” with AJAX, Radhakrishnan
said. In testing for functionality and regression, Mercury has seen an
increased number of regressions in AJAX, said Radhakrishnan.

As a workaround, Radhakrishnan suggests using AJAX for the cutting
edge part of UI development, to enable interactions between the client
and server in which the server is able to respond to client requests
later. “For the rest of it, you don’t really use AJAX,”"Radhakrishnan
said.

It is precisely using AJAX for the “cutting edge” parts of a UI that causes the problems. Calling an architectural principle like AJAX “not very structured” betrays an ignorance of the topic. It’s like calling web service “not very structured” because people are using raw java.net sockets to do everything.

This post is from April of 2006, not 2005 when this sort of comment would have been excusable. Now there are several stable intermediate forms such as DWR that allow for fairly structured development of AJAX solutions on top of existing webapp frameworks. Further, there are already some more advanced forms such as Tibco GI, OpenLaszlo, ZK and Echo2 that allow for development of sophisticated desktop-type apps.

Mercury may be trying to discourage folks from developing AJAX apps until they’ve had a chance to update their testing software to keep pace. I suggest that they work harder on their next release instead.