Slashdot Mirror
Experts Say Ajax Not Inherently Insecure
An anonymous reader writes "Jeremiah Grossman (CTO of WhiteHat Security) has published Myth-Busting - an article dismissing the hyped-up claims that AJAX is insecure. He says: 'The hype surrounding AJAX and security risks is hard to miss. Supposedly, this hot new technology responsible for compelling web-based applications like Gmail and Google Maps harbors a dark secret that opens the door to malicious hackers. Not exactly true ... Word on the cyber-street is that AJAX is the harbinger of larger attack surfaces, increased complexity, fake requests, denial of service, deadly cross-site scripting (XSS) , reliance on client-side security, and more. In reality, these issues existed well before AJAX. And, the recommended security best practices remain unchanged.'"
Way to make up an issue and then show off attacking it.
Tsunami -- You can't bring a good wave down!
When something is this widely adopted and this tempting to rapidly trot out (because PHBs are desparate for that shiny stuff as they head to the next board meeting), the fact that you're suddenly introducing a wildly more complex set of GETs and POSTs and layered hoo-hah on an interactive page (never mind the purpose of the app) means that all of the stuff that always introduces vulnerabilities will be there, multiplied by the new complexity. And, of course, with a smaller crowd of talented, experienced people truly able to quickly size up the risks as something goes live.
It's not the (non-existent?) inherent security problems in the bundle of techniques we're referring to, it's the weaknesses that show up in the practice of shoddy implementation, cheezy hosting platforms, etc. There's nothing wrong with AJAX, it's the AJAX-envy among less sophisticated operators that we have to worry about. We just have to quit saying it's 'easy' to implement, because none of the underlying bits and pieces are (in terms of being bullet-proof) are 'easy,' and a browser-agnostic soup of a couple dozen of those bits is that many times harder.
Don't disappoint your bird dog. Go to the range.
> One of the best ways to protect yourself is to turn off Javascript in your browser settings.
The more things change, the more things stay the same.
Best security practice has always been to turn off ActiveX, Javascript, Flash, and any other means by which untrusted executable content is automatically downloaded to one's machine and then automatically executed.
...and in the movie Mars Attacks! the Martians kept telling the U.S. government they weren't going to invade. Hmmm.. Maybe THAT'S where the Bush administration got their inspiration from for the premptive strike. Certainly would explain a lot...
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
It's irresponsible for a security professional to claim otherwise.
Yup, existing best practices takes care of all of the security issues for AJAX: disable Javascript. Problem solved.
... you're expected to nod agreeably when the website says "just trust us".
/demands/ that you trust them without evidence" should be the #1 best practice out there.
With open-source, you can examine the source before you run the program, and can take steps to ensure that the program you run is compiled from the source you examined and that it's unchanged since the last time you ran the program. There's no good way to do the same thing with Javascript
"Not trusting someone who
And who is honestly saying these things? Am I alone in not seeing the percieved risks here?
All AJAX really gives you is that first 'A': asynchronous. All the other underlying mechanics of client-to-server communications over HTTP apply. This means that your security checklist is absolutely no different than using a good old-fashioned [form].
To slam AJAX as insecure as a technology is just bad thinking to begin with - it's a tool, that's all. Whether or not it's used in a secure fashion is really more a best-practice and/or training issue.
Besides, didn't we already go over all this when Web-Services were a big deal?
There's some justice in saying that Ajax doesn't introduce any new problems over and above Javascript, but that is faint praise and doesn't allow for the fact that buzzword-compliant organizations are now creating more web sites that require Javascript.
His advice about keeping web apps secure is sound and practical but incomplete. The last OWASP conference I went to, one of the speakers pointed out that there's an Ajax development toolkit out there in which you can't tell a priori whether a piece of functionality you program will end up on the client or on the server. "Avoid toolkits like that" should be on the list of security precautions.
>AJAX is a web browser (client-side) technology. It does not execute on the server.
The XMLHttpRequest certainly does execute on the server and allows a range of parser attacks that you were less likely to get with other technologies. Which would you rather validate, a set of CGI parameters or a blob of XML?
This appears to be yet another case of, "You can write Fortran in any language" where the author ignores that some technologies make it much easier to write Fortran than others. Obviously with a number of things you can avoid the bad stuff by avoiding the bad stuff -- but when bad stuff is the default mode of operation, rather than the odd, explicit corner case then yes... there's an issue.
Put another way, it's a lot easier to not write Fortran in Haskell than it is in C.
-30-
AJAX is just a convenient method for sending and retrieving data from the server without a full page refresh.
As long as the sever side still requires proper authentication for the AJAX requests as they would for any other web request, it is no less secure than a normal web site.
Client side, AJAX is just as secure as javascript. It can move things around and report about anything happening on the web page back to the server hosting the web page. If you are doing things on the website that you don't want reported back to the sever (completing a form but not submitting it), don't use the web site.
The security problem comes in when people design sites that trust communication between the client side of the application and the server side of the application. Anything can be modified client side, including the javascript of the ajax application. Always pass an opaque timeoutable token that identifies the user for all requests and check the permissions before doing anything and you are about as secure as a web application can be. Even if they hack the application to send requests that your application won't let them, the sever should limit the harm to only things that user should be able to do anyway.
it's the weaknesses that show up in the practice of shoddy implementation
Right, that's what I was about to say. The only vulnerability I've seen that I would say was AJAX-specific was that someone put security on the main page, but on none of the little ajax widgets. It just didn't occur to this person that securing the widgets was necessary - probably because what we're used to when programming on the web is a main page (that is secure) and libraries that can only be called on the server side.
Someone who has more experience with web services wouldn't have made that mistake.
So anyway, like you said, the problem is shoddy implementation.
It's your fault, jackass!
Personally, I think Jeremiah Grossman is a wanker; this nonsense will come back to haunt him. But that's his rep, and not mine. Anyway, here's the definition of an expert.
"X" is an unknown quantity.
"spurt" is a drip of water under pressure.
Thus, an "expert" is an unknown drip under pressure.
Where are the pics of Kari?
I swear officer, he was alive a minute ago. He was just sitting in front of his PC trying to check his bank balance!
Indeed AJAX is not a new technology but a set of existing technologies in combination. Here's the issue though. JavaScript is a known point of vulnerability for clients. Secure clients may be hardened against attacks by disabling JavaScript. Good web design has therefore always required that pages function correctly without use of JavaScript, rather than forcing a client to be configured for greater vulnerability in general for the sake of accessing one website in particular.
But AJAX pages, by definition, unconditionally require JavaScript on the client. Hardened clients need not apply. If your security policy is not concerned with client security, or if your operation can afford to exclude some client systems, then you can regard the security of the AJAX client, as an attack surface, to be out of scope.
However, a general analysis of AJAX security also has to consider tightly integrated applications where client and server security are interrelated. Many web services exist for account administration, inventory control, system configuration, and other operationally critical forms of information management. Note how these activities are controlled by the client. In this context it's fine for servers to perform client authentication and input checking, but the advice to "never trust the client" completely misses the point of developing these applications.
Therefore, the article is incorrect to suggest that AJAX solutions need not be concerned with client security. Moreover, it's evident that AJAX creates a larger attack surface on the client. There are environments where you can decide to exclude these issues from consideration. In a general analysis of security, you cannot.
Parity: What to do when the weekend comes.
The first web game that I wrote in PHP 3/4, called Merchant Empires (www.merchantempires) was hacked mercilessly. Of course, those were the good old games of the web when SQL injection was possible on a large number of main stream sites.
My second web game, called Grand Strategy (www.denizengames.com), is a full fledged Ajax application (written using DWR and Dojo) and the game hasn't been hacked (that I know of). Of course, I can only hope if those same Russian hackers hit it, they are as kind as they were before and they send details after they get tired of toying with the game.
This type of legalese is just plain irritating. And the phase is begging the question, so if a phobia were to walk by...would that make Ajax insecure? This is like the backhand complement, "You are not unattractive."
FTA: Furthermore, in my experience, AJAX-enabled web applications are no more functionally complex than standard web applications. ... Gmail is less complex than Outlook Web Access.
Gmail and OWA both use AJAX. Heck, Microsoft created the XMLHTTPRequest object. Comparing Gmail to OWA to prove this point just doesn't make sense.
If that's true, then why does he have to carry around that HUGE shield?
Or were you talking about little Ajax?
then AJAX would not exist.
In the long term bandwidth will be (practically) infinite and whether processing is done on the server or the client will become irrelevant except that server-based processing will always be more secure and controllable.
AJAX is a temporary tool to enhance client-server interactivity until almost everyone has a high-speed Internet connection. Once that occurs such hacks as AJAX will disappear.
And good riddance! Because of it's arcane nature, security problems and greater development cost, I look forward to the day when AJAX fades.
I think that there are none "inherently insecure" things. Anything can get somehow secured. I think that given a program that is specifically designed to be insecure one can still somehow (maybe by modyfiyng the enviroment it runs it or whatever) relatively secure. Well security in fact is quite relative.
So it is not that using AJAX itself is insecure. It is that probably lot of people will try to make AJAX apps since it is trendy right now. But AJAX *is* quite complicated or just new stuff. Somebody without experience and deep understanding how these things (and for me they are quite complex) works will probably make mistakes using some code generator and generally don't understanding fully what is going on.
It is nothing new. Security is mostly about knowledge and understanding. You can't make something secure that you do not know deeply and don't understand.
It is not technical (like this technology is insecure) issue IMHO.
It is of course possible for well-intentioned Javascript or AJAX writers to write insecure code, which can be attacked either by the end user or possibly by cross-site scripting attacks, and the author of the article offers some good advice about how to prevent and manage those risks. IMHO, it's really really nice to hear somebody today offering up the same basic advice I learned when I first took programming in college 30 years ago, which is to never ever trust input from users. Any kind of scripting that runs in the browser offers more opportunities for a programmer to trust the end users - for instance, one of Javascript's big uses has always been to validate input fields in forms before submitting them to the web server, and while that can often help users who accidentally put incorrect types of information in forms, or forget to fill out fields you want, it's no protection against a malicious user trying to send malformed data to your application. AJAX gives you some more tools for trusting users (:-), as well as more tools to validate input from users because of the structure imposed by XML. And of course it's also possible for malicious users to abuse old-fashioned simple web forms, especially if the programmer isn't careful about validating form contents for safety before handing them to any applications.
Most of the popular browsers give the user some granularity in managing what kinds of scripting you'll accept from what sites, so in theory it's not as dangerous as just turning on the big red kick-me switch like on earlier browsers (or Netscape 2, which didn't even give you a choice.) But in practice the tools aren't that friendly, and the vast majority of users aren't going to use them successfully.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
You allow excessive processes to be run on client side, yet you say its secure ?
anything relegated to client side is exploitable to hell.
Read radical news here
HTTP doesn't support client-side security. Not a single server supports client-side security. The only thing you can do is try to secure a client but you can't rely on the client not being compromised.
Custom electronics and digital signage for your business: www.evcircuits.com
The original article is right that there aren't any really new problems with AJAX apps, but they are different, so some mistakes are easier to make and some mistakes are harder.
... ...
Two of the mistakes that I've found easier to make with Ajax apps are XSS and drive-by-scripting attacks.
XSS attacks arise when a user can put text on your site that runs with the domain privileges of your site. Once they can do that, it's easy to steal user information, cookies, etc. and send it back, or make modifications to user data on their behalf.
The way to avoid XSS attacks is by properly escaping all text converted to html or javascript. The difficulty arises for two reasons
1) DOM manipulation is just too slow, so you end up having to generate html. Generating html safely requires keeping a lot of escaping conventions in mind.
2) Users often want to enter rich text, so you end up passing around some strings that are plain text and some that are (hopefully properly sanitized) html.
The first can be addressed by templating -- use something PHP or JSP like to generate your html. You can make it fast, and make it obvious what's escaped and what's not. It's not a silver bullet, but it makes the problem manageable. If you want to get fancy, you can make it smart enough to know that substitutions in HREFs should be encodeURIComponented, and substitutions in onClick should be escaped as javascript strings. Just make sure that people don't have to work around the system for those rare, but necessary cases where they know they've got safe content. It's much better for there to be clear, easily-audited exceptions to the rule than for people to have to bypass your system entirely to "fix" a critical bug late on Friday night.
The second problem is harder. A good static type system for javascript might allow different types for Strings that contain plain text vs. html vs. CSS vs. javascript. Then some simple static analysis could warn you when you add plain text to html to compose a string. Unfortunately, there aren't many such tools, so my recommendation is to use naming conventions. I know everyone hates anything that smacks of Hungarian notation, but do you find it easier to spot the bug in
var name = document.form.myform.elements.myinput.value;
nameNode.innerHTML = '<div>' + name + '</div>';
or
var nameAsText = document.form.myform.elements.myinput.value;
nameNode.innerHTML = '<div>' + nameAsText + '</div>';
In the second case, you're documenting what a variable contains, so someone reviewing the code has a hope of knowing what escaping schemes need to be applied when.
Drive-by-scripting attacks occur when someone malicious finds that you're using some neat JSON-like javascript to communicate between the browser and the server. It seems like a good idea and it is, because eval is fast, and you need every bit of speed because javascript interpreters are dog-slow.
And the cross-domain policies ensure that noone can do an xml-http-request and get back the javascript, and if they do, it's safe because it has no side-effect.
Unfortunately, anyone can write a script tag, and they can replace the Array constructor. So if your message contains an array, and they can trick your user into visiting their site, then you're screwed.
What do you do? Instead of sending over
[valuable, user data]
send over
while(1); [valuable, user, data]
That way, the constructor for the data they were trying to steal never gets executed, and no other javascript on their site executes, so hopefully the user realizes that that's not a good site to visit.
How does that help you? Well, since you're using XHR, and obeying the cross-domain policy like the fine upstanding citizen you are, you can just get the response text, and strip the "while(1);" from the front and go about your merry way.
Finally,
Yes, JavaScript is an evil, evil thing in the hands of the malcontent, but having scripting support deactivated in your browser isn't really going to stop much. Some of the most recent work being carried out by Jeremiah Grossman and others who like to dabble in the area has shown that it is possible to enumerate systems on internal LANs via the browser of a visitor to an external website that the attacker controls.
Without Scripting enabled.
While the developed technique is still quite noisy and fairly obvious, there has been some work at making it more efficient. But, if you add enough shiny elsewhere on the page, then history has shown that people will be happy to put up with almost anything to get at the shiny.
Outside of the LAN, and with scripting support disabled, it is trivial to develop a network scanner that hits every port of every IP on the network segment that a site visitor is coming from, and which triggers only when the site is visited by the victim.
The bigger threat to AJAX in recent months has been the widely published (amongst security researchers) issues affecting the core AJAX components for Internet Explorer and Firefox. IE had threats affecting the XMLHTPPRequest ActiveX object (sort of core to the whole AJAX experience) as well as other threats targeting different scripting support, while Firefox had a number of issues affecting JavaScript support. Most of these issues had public exploit code and actively circulating exploits (though only in small numbers). Had something been developed which was aggressive in attacking these flaws, Web 2.0 could rapidly have become Web 0.2 for many users. Before you claim that trusted sites should be safe, the WMF vulnerabilities from last December / January showed that once an adhost gets compromised, it is game over for many many many sites that should otherwise be trusted.
InfoSec that matters, when it counts.
It forces you down a design path that leads to insecure code. If you want to plug every hole, you've got to do ten times as much work.
I wish there was some HTML attribute or some simple way of telling the user's browser things like "Don't let any of this part of the DOM tree be scripted from outside", or "this script is only allowed to do AJAX from these domains". Sort of like SELinux for HTML.