Slashdot Mirror
Is Your AJAX App Secure?
ShaolinTiger writes "An article looking in detail at some of the security problems with AJAX, how to find them and how to approach them or fix them. Security with AJAX is of course an important consideration as it's asychronous and a malicious user could write data back to your database if implemented incorrectly."
In the article, he addresses a token used to generate random strings: And I think one of the most commonly used Universally Unique IDentifiers (UUID) generators is Java UUID Generator (JUG) which can be used by any type of application that can communicate with Java libraries (most apps capable of XML messaging can anyways).
Of course, this can be no better than pseudorandom as we all remember from our courses.
My work here is dung.
AJAX is not secure! if you look at google maps you can see my house... it's just sitting there on the screen waiting to be bombed. ahh.. my frickin' house!
Anons need not reply. Questions end with a question mark.
How is this different from securing a "normal" dynamic website?
I write only static HTML you insensitive clod.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
No, mine isn't. I developed a Q&D (quick and dirty) AJAX app along with a nasty "write-only" Perl script to manage a server for my own use. It's full of security holes and the server script doesn't even do the most basic sanity checks, it even uses some VERY insecure variable untainting, and runs on thttpd as root. But hey it works, and as I'm the only one using it, on my own internal LAN, well.. I don't mind :D
Pretty much everything in this article seems to be a complete rehash of things most web developers should already know, you should always be checking for possible xss/css problems, you should never depend on a cookie, never provide more information to the user than they absolutely require, always treat all input as tainted until it has been correctly validated, just because this article relates to a new technology doesn't mean it is refering to new vulnerabilities.
I am sure that some people can learn a little about security from this article but if you learn anything new reading this, you should go to any sites you have written in the past and take them down right away because chances are you already have a security hole. I recall quite recently a friend of mine was quite shocked that his AJAX application could perform sql injection attacks on his database, on looking at his code he was entirely trusting everything that came to it, I almost slapped him for that mistake.
GeekServ Unix Consulting Services (http://www.geekserv.com)
If not, you need to clean it up!
Code cleanliness is next to Dev godliness.
He who knows best knows how little he knows. - Thomas Jefferson
Force your users to use IE. Make them install ActiveX controls that host your program. Exploit their PCs.
Sheep need to be led.
Security with AJAX is of course an important consideration as it's asychronous and a malicious user could write data back to your database if implemented incorrectly.
That statement is a little misleading, as security is not directly related to requests being asynchronous. I think what the poster meant is that being asynchronous, AJAX application make lots of calls to the back end. In a non-AJAX app, typically you fetch the data during the page load. In AJAX app, users request sections of the page to be refreshed, meaning a lot more finely grained methods to the backend are exposed.
non-AJAX:
LoadMainPage()
AJAX:
LoadTitles()
LoadSections()
LoadSummary()
Life is just a conviction.
And no, I'm not a hater. I personally count Ruby amongst my programming languages of choice and I have written a couple of Rails applications that my company currently has in production. But the AJAX hype is getting tired.
Hasn't the threat of a SQL injection always been a threat, dating back to the pre-AJAX days of development? Why is this even news? Proper error handling and input checking should be enough to minimize these problems.
It runs through various ways in which your AJAX app can be insecure. All of which apply to any dynamic page, AJAX or no.
Then, instead of discussing how to, i dunno, say, actually _check_ your input, it rambles through various techniques of that stalwart of crappy coders: security by obscurity.
Every solution posited finishes with "Hey, people could still crack this easily, but it makes it that bit more annoying".
Time here would be much better spent reading some Shiflett (for php newbs of the world), or any "Security goofs 101 and how to _actually_ avoid them", not this "vaguely obfuscate stuff, and use POST" recommendation.
1/10
i fail to see the difference of a webbrowser initiated and a scripted request to a dynamicly generated response. In any way, permission must be checked, the script shall now work on request data nor send data back to a client with insufficient permission. Nothing to see here, move along ...
-S
No, security is not important because AJAX is asynchronous - security is important because an AJAX app is exposed to unknown users on the public Internet. The security issues with AJAX are the same as with any web application: don't trust any input and validate it before doing anything important with it. The security issues with the Javascript part (things like, but not limited to cross site scripting and sending things to your clients that may be harmful to them) are the same as any other Javascript-using website.
Oolite: Elite-like game. For Mac, Linux and Windows
Can someone explain to me why this is not a problem with regular GET and POST requests? What is special about AJAX that introduces new security problems? Or is this just a chance to write an article using the latest buzzword?
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
what does the author mean using this word in this context? yes I looked it up
AJAX Security
A possible way of securing one's application is using some form of 'sequence-numbering'-like scheme.
How is this not security through obscurity? The only difference between guessing this sequence number and guessing the session ID in a cookie is only that of duration, but one sniff on the wire and you got it.
Overall, the hype on AJAX security stems from people not treating the AJAX requests any differently from non-AJAX requests. Trusting your input is mistake #1 regardless of where or how it comes.
And we'll rehash this entire deal in a few years when AJAX is replaced with something else of equal buzzwordthyness.
:wq
He states POST is more secure because it is harder to fake?? Nice joke.
What difference does asyncronicity make with security? Zero.
What difference should AJAX make with security? Zero.
All security should be applied on the server-side portion of your AJAX application. The same way any other web application is secured. End of question.
Could someone please explain to me how these potential problems with AJAX requests are unique to AJAX at all? This article did a horrible job at that. Couldn't any GET (to a script) or POST request request be "faked?" Aren't forms and links just as vulnerable to variable insertion and whatnot? AFAIK, there is really no fundamental different between an HTTP request made by a user directly and XmlHTTPRequest.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Not to mention that someone can have a legit number, and still be doing what they're not supposed to be doing.
If corporations are people, aren't stockholders guilty of slavery?
I am growing sick of hype surrounding the AJAX bandwagon.
What, how is an article that talks about security vulns hype? Would you rather that information like this be "kept quiet"? I didn't see anywhere where AJAX itself was being hyped up, or that it was being claimed that it was superiour to anything else (aamof, quite the opposite, the author implies that there could be additional problems with this new beast).
I understand where you're coming from, but pick a more appropriate article to post your rant on, this isn't it.
This author of this article does not seem to properly comprehend security issues. He rambles on for several pages, but doesn't actually propose anything novel or indeed anything particularly useful.
Using POST instead of GET and checking for User Agents and Referer headers won't do much to make your web application anymore secure. It's the web equivalent of hiding the keys under the doormat. Sure, it's better than leaving your door wide open, but it's not security in any meaningful sense of the word.
The way to secure AJAX is the same way classic CGI transactions are secured; through sessions, passwords and SSL.
Please please please, buy a new house, or next time the Google Spyplane comes to take pictures, teepee your neighborhood with Tinfoil, I'm sure your neighbors will understand once you explain it to them.
Don't anthropomorphize computers: they hate that.
1. verify your data, i have a bunch of asp functions that each convert any input into a string/int/decimal/bool,date that return ""/0/0.0/false/(now) upon chocking on their inputs, simple
... i'd expect to be fired for making it that simple
:-)
2. use regular expressions, strip out the naugty chars from your inputs where you can, like newlines, even semicolons (no one i know has a semi colon in their name, date of birth or email address), and HTML encode your data BEFORE you try to save it to your db, gets rid of the double quotes AND saves time encoding it for every page write.
3. generate unique ids. easy way: generate a long random number, and then add the date and time of the request to the end. sure the right hand half is somewhat guessable but it ensures uniqueness*, which is always handy.
4. FFS dont assume that a user will only click links, anything that comes from the get or post needs double checking against the user's permissions. a lot of security flaws have been found this way: log in, view your bank account, change the url from viewuseraccount.asp?id=1234 to viewuseraccount.asp?1235
5. dont have "website.com/admin/"
6. dont use "UPDATE" or "INSERT" or "DELETE" querys
7. etc.
*nearly, unless you get slashdotted i suppose, then i expect your server will go down before the left (random) half also provides a collision anyway
If you don't risk failure you don't risk success.
The fact that it is asychronous has absolutely nothing at all to do with whether or not it has the ability to write back to the database.
You can have AJAX calls that write to the database, and ones that don't, both being asychronous. Also you can have sychronous AJAX calls (is this just "JAX"???) that write to the database.
Anyway - its pretty much the same considerations you should take when writing any web application. Verify all inputs, period.
Not quite. The article does a horrible job in explaining it, but basically, one problem is that if an attacker can induce you to view a page containing JavaScript, that JavaScript can execute GET and POST requests under your authority.
So, for example, if the attacker knows that you use Foo Webapp, then he can put up a page on his own site that executes requests corersponding to that web application, and send you a link saying "hey, look at this!" or whatever.
Here's the thing - because it's your browser making the requests, and because those requests are going to Foo WebApp's domain, your browser will send your cookies along with the request, proving that it's you.
What this means is that you not only have to prove that it's you making the request, you also have to prove that it's a request you meant to make. User authentication alone is not enough.
The typical solution to this is to additionally include another random cookie-type value as a hidden field in every form you generate. Because your attacker doesn't have access to the pages you are viewing, he won't have access to that value, so he can't construct forms that submit that value to Foo WebApp. In this way, you can reliably determine that it's a valid form submission that comes from your own web application.
None of this, of course, is dependent upon Ajax being used. Ajax is a red herring here. This security concern applies to all web applications, whether or not they use Ajax.
Bogtha Bogtha Bogtha
So, does that mean if I use more control of the use of my AJAX that I'll get less infections or reduce the chance of getting the clap?
http://www.f5.com/products/TrafficShield/
App Security
TrafficShield® is a web application firewall that provides comprehensive, proactive, network and application-layer protection from generalized and targeted attacks by understanding the user interaction with the application firewall. TrafficShield employs a positive security model ('deny all unless allowed') to permit only valid and authorized application transactions, while automatically protecting critical web applications from attacks such as Google hacking, cross-site scripting, and parameter tampering.
If a functionality is remotelly available via a public network then anybody can try to hack into your system via it.
Without AJAX: A web application serves pages via single HTTP calls, possibly with one or more parameters, per page.
- Hackers can try getting into your system via this web application by tweaking the parameters, URL, HTTP headers, etc of the requests used to retrive pages
With AJAX: A web application serves pages via a single HTTP call, possible with one or more parameters, per page. Additionaly, JavaScript embedded in the page will, typically in response to user input, send extra HTTP requests to get more information (mostly in XML or plain text format).
- Hackers can try getting into your system via this web application by tweaking the parameters, URL, HTTP headers, etc of the requests used to retrive pages or extra information.
Same principle for both, it's just that with AJAX there is a bigger number of entry points (more "handlers" for HTTP requests) since asynchronous HTTP requests from the Javascript code also require server-side code to process those requests (and generate responses).
Can you trust that nobody will try to get into your system by hand-executing an HTTP Request to a request handler that's supposed to only be called by Javascript code? Of course not!
It's the same reason why when an HTTP form is submited to the server you still check (on the server side) the validity of the information submited for that form even though your Javascript validator also does a full validation of the form before allowing the user to submit it.
Programmers that don't implement checks on information submited to the server and/or feed it directly to interpreted language engines (such as SQL query executers) without escaping or protecting it (in some other way) will ALWAYS leave gaping security holes open, AJAX or no AJAX.
An incompetent programmer is always an incompetent programmer.
If you're going to investigate this, try using Fiddler (http://www.fiddlertool.com/). It's pretty much incredible, though it is Windows-only. It's .NET so maybe it could get Mono-ized without too much trouble.
:)
Capcha: "unparsed"
In Mortal Kombat 2, A JAX fatility showed a large African American man rip the arms off his enemy.
1) Your analysis is based on bad assumptions so your result is way off. 2) You're a sick bastard for fucking a horse.
Can somebody please come up with a name other than AJAX? I find myself talking about the programming techniques covered by the moniker of "AJAX" (herein after refered to as "BLURG") and wanting to call it something other than "AJAX":
BLURG is not necessarily asynchronous: you may be updating only a small part of the page, but doing it synchronously.
BLURG does not require XML. In fact you could be returning HTML, Javascript, CSV, JSON, etc.
BLURG does not even require the XmlHttpRequest feature and BLURG techniques have been in use far before the existance of this feature.
Can we please come up with a better name for BLURG, one that covers the more general programing techniques involved? Something for us people to use that is NOT just the trendy new thing known as AJAX? Something that we can use that will let others like us know that we have been aware of these techniques even before the term AJAX was coined?
For now I will call it BLURG...
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
Microsoft ASP.NET version 2 also fights cross-site request forgeries with a MAC'ed token:
ViewState, ViewStateUserKey, andother ASP.NET security-related features
To save you futile Googling, be aware that Microsoft refers to cross-site request forgery as "one-click attacks".
Don't underestimate how important this attack is. To quote The PHP Consultancy, The most challenging characteristic of CSRF attacks is that the legitimate user is essentially making the request. Thus, regardless of how perfect the user identification and/or session management mechanism is, a CSRF attack can still be successful."
It seems that the author is unaware of all the research that has already been done in this area. This type of attack is known as Cross-site request forgery and the counter-measures (which the author re-derives from first principles in his article) are already known.
- JavaScript is used to create an SQL query based on what report the user wants.
- This SQL string is submitted in a form and executed as an SQL query directly without any checks or anything.
- The db user executing the query has enough rights to read / edit / delete all databases on the server.
- Everything the query returns is serialised and passed back to JavaScript to parse and display.
That's an actual case in an actual web application, though the guy had long experience with SQL he was new with AJAX apps, so we caught that in the code audit.
Now he knows that's a Really Bad Idea to do, I wonder how many boys and girls out there don't.
Your remark really concludes this topic, and I think any further remarks are redundant. I just want to point out that in the HTTP specification (RFC 2616) section 13.9, it says the following about GET requests:
And in section 9.5, about POST requests:
Thus, the only semantic difference between GET and POST is only on side effects. There is no sense in saying one is more secure than another, or one is easier to fake than another.
If we think of a web server as a function, GET requests means that, let y1 = f(x1) and y2 = f(x2), then x1 = x2 implies y1 = y2. POST requests means there exists y1 and y2, y1 != y2, such that y1 = f(x) and y2 = f(x) for some two applications of f with x. Here y, y1 and y2 are the "web pages" (more generally, resources), and x1, x2, x are the HTTP requests.
Of course, for a practical, dynamic website, the functional property does not usually hold, and that's why we have "cahce control", which attempts to establish what functional property holds under certain conditions.
I once had a signature.
Well, one difference I can think of is ease of use... or ease of abuse. With POST/GET, especially POST you have a fair bit more work. You need to setup a fake POST form that circumvents whatever security they might have in place, whatever.
With AJAX though, you can just view source of this existing page, then in the URL bar, start trying various combinations out, such as javascript://SomeAjaxFunction(someVar); enter. Repeat and rinse. Hell, you could do an inline breakpoint, and use your favorite client side js debugger to try new exploits.
In the end, not a big difference, except in the ajax way, you already inhereited an client side security tokens or whatever else that the page may be using for security. You are pretty much injecting your code on the fly into whatever the origonal author wrote. Whereas in POST manipulation, you are basically trying to emulate a client request from beginning to end.
...everyone else concerned with the topic means by it:
http://en.wikipedia.org/wiki/AJAX
But most of all, samy is my hero.
-- "I can't tell the future, I just work there." -- The Doctor
.. check for the session to be correct.. in other words, a user must login first and that login is stored in the session. so any of my servlets that actually talk to my database need that login first, as they ALL check the session. You can't just post the form to do an update in my system, you must have other data in order for that post to actually pass step 1. This is IN every servlet.
Only 'flamers' flame!
Does slashdot hate my posts?
We design applications so that they function entirely with JS disabled. All data that is validated on the front end is re-validated on the backend along with session state verification. If you aren't doing this you are going to get what you deserve in the end.
"...and a malicious user could write data back to your database if implemented incorrectly."
Isn't that supposed to be, "...if implemented correctly"
No sig for you! Come back one year!
Always validate what you run through eval()!
While not fool proof, making sure that what you got back from the server is JSON, and not a string of malicious code is paramount.
And guess what, such things already exist.
Granted, this doesn't prevent someone from embedding that same malicious code in valid object code that appears identical to what you expect as a server result, but its a huge step in the right direction.
I feel like I am entering the twilight zone...
This is an issue that has not changed one bit since the dawn of the web: Everything that comes in your server through an HTTP(S) request is to be assumed 'insecure' by definition. The only assumption one can make about such data is that it comes from a specific user if a proper session id is provided, nothing else.
This is a very very very common misconception in almost every application I have worked on. People (devs) seems all to think that a javascript consistency check is all it takes to ensure the user will not submit an amount too high, or anything else for that matter.
The approach is flawed because of one thing: Everything that runs out of your box can be fooled with. And JavaScript is so easy to fool with that it is a shame that ANYONE would rely on any piece of JavaScript without any security/safety check on the server side.
AJAX is just another extension based on the same principle. Anyone can fool an HTTP request. Anyone can fool a Browser. Anyone can execute arbitrary Javascript code in your browser to modify its behavior: Just type the code in the address bar.
This issue is just insane!
Is Your AJAX App Secure?: As secure as any webapp. Consistency and security checks needs to be made on every data coming in your system. Short of that, it is just swiss cheese: Full of holes.
Write boring code, not shiny code!
All controls being mentioned in the article are useless and do not address any issues with Ajax or any HTTP based technology (User-Agent, Referrer, ID's, etc are clinet controllabe)....
PS: Check out an HTTP proxy for your good...
Just thought of a quote by Thomas Brattli (a real DHTML-guru):
Let's keep DHTML alive and say bollocks to AJAX!
Even if I don't share his opinions, I strongly advise you to chech his site http://www.dhtmlcentral.com/. He has done some amazing things.
Sorry for the grammar, I'm swedish. Bork! Bork!
By reading your comments, anyone who has a clue can tell you're definitely a n00b at this. Things like HTML encoding your stuff before committing to DB lets us guess you're concatenating strings - the best way to be vulnerable to SQL injection attacks. Rather bad advice. If you were using parameters (parameterized queries or sprocs) none of this would be necessary. And even though one should strip off nasties from inputs, it becomes less critical that your stripping is 100% bullet proof (it'll never be).
#6 is just plain stupid. Might as well say "don't use databases". Things like that are required hundreds of times per second in thousands of every production systems. Somehow data HAS to change. And since you're concatenating to generate your queries, you're still more vulnerable to problems than someone using parameters properly - once a flaw is found in your "protection" (that often rely on things like blindly doubling single quotes and such), they can easily tack on a DROP TABLE at the end if they want to, whereas with parameters (again, used properly) it's quite safe to use INSERT/UPDATE/DELETE. (Not to mention, non-web apps will have to needlessly HTML decode stuff to display it when it's completely unecessary). Validating for proper user input (sever side req'd, client side as well preferably) is a must - just removing bad chars (like getting rid of double quotes) is NOT a good way to do this, and it'll often end up just crippling perfectly valid entries you hadn't expected.
#5 is nonsense. It does NOT matter what it's called. It just has to be secured properly. Or perhaps you're recommending security by obscurity - hopefully they don't ever guess or find out the admin page's directory name or else... I've never had a security problem with my admin pages, even if I put a direct link to them that's accessible to pretty much everybody. As long as they're secured properly it's a non issue. All they'll ever see in an "admin login page".
Honestly, you're NOWHERE near enough knowledgeable to give advice on how to secure apps. Lots of it is plain wrong, some of it is just a hack or workaround the real problem, and no real problem solving / peroper way to do it. You don't want others to use that, you're essentially doing them a disservice by giving them this wrong info. There's tons of great guides on the web that'll teach 'em all the good stuff that they should be reading instead (and perhaps you too). You still have TONS to learn. This isn't even the tip of the iceberg.
Browser.... request .... security .... application .... security .... application
Browser.... asynch request
erm, questions?
The point has nothing to do with 'asynch' but more to do with programmers think that the average user cannot produce requests to these server objects easily, despite being simple http calls...
so there. all bollocks.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
At first I thought it doesn't matter whether you use GET or POST, but he has a point with the image tag, because you can more often sneak a GET request into an im src attribute than a POST.
A second reason as pointed out by pikine is that all GET requests are supposed to be idempotent, as in, they perform operations which do no major changes to the basic data of the hosted application. For example, many wiki authors complained about rogue bots deleting their content when the bots actually were only following GET requests.
Well, my complaint about the article would be that the this also affects non-Ajax apps. Maybe it would be different if Ajax was using its own access method but POST and GET.
I'm still trying to figure out what people mean by 'social skills' here.
As far as _your_ applications go, your server does need to validate any input it gets and only accept correctly-formatted content. Your client should too, but if your server gets cracked then everybody who uses it is at risk. There's very little news there about AJAX that wasn't obvious 30 years ago when my college professors were telling their classes to assume that all input is potentialy malicious and malformatted and testing our homework projects to see what they did if fed bogus data - you still have to defend against that.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I recently was messing around with a program that a friend of mine had main. He had made wrapper functions for all 21 of his ajax functions which made it a matter of changing the relative URLs to absolutes and I was in. I could run any ajax function including giving myself an administrator account. Not being the malicious type, I emailed him and detailed how to fix the vulnerability (include the md5 of the password with all function calls), but I could have potentially done anything. Its my guess that there are thousands of these unsecure applications all over the internet.
I was under the impression that xmlhttdrequest won't allow you to access any domains other than the one the page was loaded from. So javascript loaded from example.com can't request stuff from foo.org.
Once more, this has nothing to do with Ajax, XMLHttpRequest, or anything like that. That was just something the article author added to get people reading. For POST requests, you just need the plain old JavaScript load event to submit a form, and for GET requests, you don't even need that. For example, this submits a GET request to delete something:
Both of these requests will be coming from your browser, your IP address, with your cookies, to the FooWebApp domain, no matter where the malicious code itself is hosted.
In the first case you shouldn't be using GET to perform unsafe actions, and in the second case, you should include a random secret token in each legitimate form that you check for upon submission. Unfortunately, there are a hell of a lot of web applications out there that don't bother, leaving themselves wide open to attack.
Bogtha Bogtha Bogtha
The only decent thing said in the article is right below the big 'darknet.org.uk' logo.
I totally agree about that.
You insensitive clod!