Slashdot Log In
Is Your AJAX App Secure?
Posted by
CmdrTaco
on Wed Apr 05, 2006 09:13 AM
from the something-to-think-about dept.
from the something-to-think-about dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
JUG (Score:4, Insightful)
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) [safehaus.org] 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 [wikipedia.org] as we all remember from our courses.
Re:JUG (Score:5, Informative)
So when you're writing a command to make a request, you pass your request into your pre-written function which has any request-related security processes written into it. This way things are reasonably seamless in that you don't have to worry about security every time. I think.
Parent
ny (Score:4, Insightful)
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.
Parent
Who else does this right (Score:3, Informative)
ViewState, ViewStateUserKey, andother ASP.NET security-related features [microsoft.com]
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 ide [shiflett.org]
How is this different (Score:5, Insightful)
Re:How is this different (Score:5, Insightful)
Parent
Re:How is this different (Score:3, Funny)
The article proposes one kind of attack: "it would leave massive DoS possibilities if I can create an HTML page that, using Javascript, can request thousands of concurrent web-pages from a web-site".
An attack like that would hit the web server's current directory, ".", like a slasher. An attack site that takes thousands of incoming connections and then floods the victim, implementing this "slash dot" effect, is a brilliant innovation.
Re:How is this different (Score:5, Informative)
You are absolutely correct. The example the author provides of the .len paramter not being checked by the web app is a prime example of the kinds of problems that plague any web application, AJAX or not. Input validation, session validation, user authentication and so forth are required by EVERY web application. This part particularly irritated me:
That is true of most common methods of session management. For instance, PHP's very own built-in session management, which many people use, uses nothing more than a cookie value to manage the session. If you want to secure any web-app that uses sessions through cookies (again, AJAX or not) you'd better be using an HTTPS connection and cookies that are flagged to only be transmitted across a secure connection, and the author never touches on this point.
Add to that the whole nonsense about POST being "more secure" or "harder to fake" and it becomes clear that these are the words of a novice web programmer. And clearly this article illustrates nothing more than a web programmer's first experiences with examining the security of a web app.
But, he's linked to slashdot's main page, with plenty of AdSense links... so good for him.
Parent
semantics of GET and POST (Score:5, Insightful)
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.
Parent
Re:How is this different (Score:2)
Obligatory (Score:4, Funny)
Re:Obligatory (Score:2)
I'm just going to go back to my hyperlinked help system now.
But we already know this... (Score:2, Insightful)
I am sure that some people can learn a litt
Re:But we already know this... (Score:2)
Pretty much everything in this article seems to be a complete rehash of things most web developers should already know is wrong.
Seriously, I don't think I've ever read a more clueless, half-baked article about web security in my entire life. Most of the advice is misleading or just plain wrong, the author seems to only partially understand even the most basic threats, and clearly has no ide
AJAX App Secure? (Score:3, Funny)
Code cleanliness is next to Dev godliness.
Challenges of AJAX (Score:4, Interesting)
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()
Re:Challenges of AJAX (Score:2)
-matthew
Re:Challenges of AJAX (Score:2)
Re:Challenges of AJAX (Score:2)
Anyone serioulsly trying to exploit this will not be using javascript and a browser but something like curl and perl.
At this level there is really no difference between between "get" and "post" as curl can handle both equally easily, and, there is really not much difference between a URL designed to be read directly by the browser and a URL designed to be read by AJAX.
What the article is really saying is
Isn't that always a threat? (Score:5, Insightful)
Re:Isn't that always a threat? (Score:2)
No, of course not. I mean, who could ever sneak in something malicious to http://host/report?q=SELECT+%2A+FROM+CUSTOMERS? I really wish I was kidding, the first response to "we should never do this" was "oh, so we should be using POST instead?"
But, yeah, these types of problems aren't exactly new. Although there are quite a few people out there who seem to believe that if you simply hide the location bar via window.open, you remove all chances of tampering with the request. Likewise with using POST ov
Re:Isn't that always a threat? (Score:2)
I really wish I was kidding, but the first thing the article suggests is using POST instead.
Re:Isn't that always a threat? (Score:2)
He also says that you can't make a POST request to a website other than the one the page doing the POST is on. This is true if you're using XmlHttpRequest to do the POST, but if you're using standard forms you can. You can even hide a form in a FRAME/IFRAME and use JavaScript to automatically submit it in the background. (Of course, you can't get the content returned in response, but the same is true with GET). L
Re:Isn't that always a threat? (Score:2)
I was assigned the job of fixing the problems, leading me to become a ridiculously paranoid developer.
The point of these articles (heck, I've written articles just like this) is to reach those developers that may not have considered these problems.
Of course, you also have to convince the idiots out there that security is a concern...
Re:Isn't that always a threat? (Score:2)
I don't understand giving attackers a free attack vector in your applications.
Re:Isn't that always a threat? (Score:2)
Unless your DBMS doesn't support bind variables. In which case you may want to consider one that does. I hear PostgreSQL is nice.
Re:Isn't that always a threat? (Score:3, Informative)
While this is true for the most part (and in fact I made a case for it elsewhere on this thread), the one side-effect is that your DBMS can't examine the value of the parameters when determining the query path, possibly resulting in sub-optimal optimization. However, it does result in incredibly repeatable query paths, which is a trade-off I'll take almost any day.
It still amazes me when you can crash even high-dollar enterprise apps by putting an apostro
Asynchronous? (Score:2)
Maybe I'm stupid (Score:2)
Re:Maybe I'm stupid (Score:2)
These are old security problems in new cooler, faster, better package.
AJAX seems to be hidden and because of that is as deceptive to n00bs as <input type=hidden> is.
Security by obscurity is no security at all.
Easiness Mostly (Score:2)
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 clien
asynchronous? (Score:2)
The same thing... (Score:2)
http://en.wikipedia.org/wiki/AJAX [wikipedia.org]
Sequence numbering? For sure? (Score:2)
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'
Re:Sequence numbering? For sure? (Score:4, Informative)
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.
Parent
Can someone explain...? (Score:2)
-matthew
Re:Can someone explain...? (Score:2)
Really? Isn't the typical PHP application, for example, full of different interfaces? index.php, mailbox.php, submit_form.php, etc? Typical non-AJAX web apps rarely define a single point on entry.
The only two AJAX APIs i've used extensively
This is security advice? (Score:2)
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
Re:This is security advice? (Score:3, Informative)
Did you even read the article? This is a new class of vulnerability. The risk is from the AJAX features in the browser. It allows malicious code on site A to cause things to happen on site B, as long as the user has a session established (in another window or tab) with site B. This attack works even if site A uses sessions, passwords, and SSL.
Imagine this: you log into a secure webmail ap
Stupid comment (Score:2)
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 wr
Network security 101 (Score:4, Informative)
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.
"AJAX" alternative? (Score:3, Interesting)
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...
Cross site request forgery (Score:3, Informative)
I'm pretty sure... (Score:2)
But most of all, samy is my hero [namb.la].
Tinfoil Response (Score:4, Funny)
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.
Parent
Re:Enough already (Score:2)
-matthew
Re:Enough with "Enough already" (Score:3, Insightful)
It's hype because Ajax has absolutely no bearing whatsoever on the topic at hand. Web applications that don't use Ajax are just as vulnerable to these problems as web applications that do use Ajax, and the problems are solved in exactly the same way.
Yet somehow, the submitter has managed to get a badly-written article that offers nothing novel whatsoever to the front page of Slashdot merely by arbitrarily inserting the latest buzzword as
Re:Enough with "Enough already" (Score:3, Insightful)
Re:without RTFA .... (Score:2)
I'm not too familiar with ASP, but wouldn't exceptions be a better choice instead of returning null input?
The easiest way to validate input I've found, is to just grab a decent web framework with a validation system built in. There's plenty around.
Re:without RTFA .... (Score:2)
Well, yes and no. HTML encoding your data is really messy if you have to pass it off to other systems and you keep wondering if you've already decoded it, or not, or if yo