Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is Your AJAX App Secure?

CmdrTaco posted more than 8 years ago | from the something-to-think-about dept.

142

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

cancel ×

142 comments

Sorry! There are no comments related to the filter you selected.

JUG (3, Insightful)

eldavojohn (898314) | more than 8 years ago | (#15066102)

Well, I'd like to say that this is an issue rarely addressed--which is alarming considering how widely AJAX is used these days.

In the article, he addresses a token used to generate random strings:
One should let the page, or some include javascript, generated on the server side, include some token that the performs some operation on which gives a result which is used in any consecutive request to the webserver. The webserver should not allow any request with another 'sequence number', so to speak.

The servers' 'challenge-string' should be as random as possible in order to make it non-predictable: if one could guess what the next sequence number will be, it is again wide open for abuse.
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 (4, Informative)

stunt_penguin (906223) | more than 8 years ago | (#15066174)

It should also be possible to add a function that you run for each http request that filters the request for common attacks, and also handles the key the parent talks about.

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.

/relative JS noob who writes a lot of actionscript so therefore *thinks* he knows a language ;o)

Who else does this right (2, Informative)

Beryllium Sphere(tm) (193358) | more than 8 years ago | (#15067103)

Microsoft ASP.NET version 2 also fights cross-site request forgeries with a MAC'ed token:
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 identification and/or session management mechanism is, a CSRF attack can still be successful." [shiflett.org]

it's not secure, check out googe maps (3, Funny)

Gravis Zero (934156) | more than 8 years ago | (#15066115)

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!

Tinfoil Response (4, Funny)

0110011001110101 (881374) | more than 8 years ago | (#15066511)

You sir, are a sucker. I have found a way to beat the dreaded AJAX Google Maps insecurities. Simply put, I have a new house built every couple of years. My current house will be done in a week or so, and according to Google Maps (evil AJAX house bombing helper) my new cul-de-sac does not even exist. It's just a lot of trees... now who would bomb trees?

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.

Re:Tinfoil Response (1)

the chao goes mu (700713) | more than 8 years ago | (#15068370)

I have a better solution. I live under those trees! Dressed only in my tinfoil jumpsuit, hiding in dense foliage, no google spyplane will ever find me!

How is this different (5, Insightful)

El_Muerte_TDS (592157) | more than 8 years ago | (#15066130)

How is this different from securing a "normal" dynamic website?

Re:How is this different (5, Insightful)

grazzy (56382) | more than 8 years ago | (#15066176)

There was a new buzzword in the middle of the sentence.

Re:How is this different (2, Funny)

Beryllium Sphere(tm) (193358) | more than 8 years ago | (#15067364)

Now, now, be fair.

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 (1)

NickFitz (5849) | more than 8 years ago | (#15068868)

That's not something new. I can host a web page which uses a JavaScript setTimeout trigger to repeatedly download your site's homepage into an Image object - it doesn't matter that it's not an image. If I then get that page Slashdotted, all Slashdot's readers who RTFA and have JS enabled will, for the time it takes to read my page, be participating in a DDOS attack against your website. This has been possible since Netscape 3 in 1996, and doesn't involve Ajax at all. As a number of commenters to TFA and here on /. have pointed out, there's nothing in there specifically to do with a threat posed solely by the use of Ajax.

Re:How is this different (0)

Anonymous Coward | more than 8 years ago | (#15066366)

You don't get to the front page of Slashdot if your article is called "Do you have any common sense whatsoever?"

Re:How is this different (0)

Anonymous Coward | more than 8 years ago | (#15066414)

This is true, but there are a large number of idiots with keyboards [thedailywtf.com] out there who don't any common sense what-so-ever. If we see a "Web 2.0 bubble" develop, you can bet your bottom dollar those idiots will be all over the web (2.0).

Re:How is this different (4, Informative)

stromthurman (588355) | more than 8 years ago | (#15066625)

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:



If the XmlHttp-interface is merely protected by cookies, exploiting this is all the easier: the moment you get the browser to make a request to that website, your browser is happily sending any cookies along with it.


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.

semantics of GET and POST (4, Insightful)

pikine (771084) | more than 8 years ago | (#15067170)

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:

Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any resources SHOULD NOT have side effects that would lead to erroneous behavior if these responses are taken from a cache.

And in section 9.5, about POST requests:

Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.

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.

Re:semantics of GET and POST (1)

stromthurman (588355) | more than 8 years ago | (#15068057)

Very well said. I particularly like the view of GET and POST as functions, but then I am a mathematician, at least in title.

Re:How is this different (1)

portcombine (966282) | more than 8 years ago | (#15067295)

Actually, as far as I understand what _does_ make POST more secure is that parameters (user credentials when logging in, ...) don't show up in the web servers log file?

Re:How is this different (1)

the chao goes mu (700713) | more than 8 years ago | (#15068417)

There are modules which can be used to record POST data, but for a default setup you are correct.

Re:How is this different (1)

Trails (629752) | more than 8 years ago | (#15067320)

I thhink what the author meant was that GET requests are easier to muck with.

We all know someone with malicious intent and a modicum of knowledge canfarily easily fake either, and the incremental difficulty from of POST as compared to GET is negligible.

However, a bored 13 year old, with minimal knwoledge, can easily muck with a GET, not so much with a POST. A POST requires a bit more know-how, hence limiting the user base that has the ability to dick around with your site, hence offering greater security.

Re:How is this different (1)

misleb (129952) | more than 8 years ago | (#15067749)

However, a bored 13 year old, with minimal knwoledge, can easily muck with a GET, not so much with a POST. A POST requires a bit more know-how, hence limiting the user base that has the ability to dick around with your site, hence offering greater security.
But isn't it the kids with just a bit more know-how that you have to worry about?

-matthew

Re:How is this different (1)

Trails (629752) | more than 8 years ago | (#15068122)

Well, it's all of them really. Look, security, to some degree, is a numbers game. Nothing is perfectly secure. It's about reducing the ease of exploitation. Coverting from GET to POST is EASY, and, clearly, less people know how to create a POST as opposed to a GET.

To analyse a POST, one needs: knowledge of HTML and javascript, and to spend time reading the source of the form in question to figure out what the post looks like.

To create a fake POST, one needs: knowledge of how HTTP headers work, and either telnet knwoledge or a firefox extension [mozilla.org] (courtesy of post below).

To analyse a GET, one needs: a browser

To create a fake GET, one needs: a browser.

To convert from GET to POST does NOT make you app secure. However, it'll reduce the number of phony requests you have to deal with.

Re:How is this different (1)

the chao goes mu (700713) | more than 8 years ago | (#15068463)

Actually, to fake a post most of the time you simply need to save a local copy of the relevant form and manually edit a field or two (or turn a hidden field into a text box, or something similar). It is much easier than you suggest in 90+% of the cases. (Yes, extensive use of javascript makes this harder, but most websites use pretty simple forms, and any JS is for input validation. You can usually ignore the JS, especially if you are mangling a hidden field -- as JS usually does no validation on hidden fields.)

Re:How is this different (0)

Anonymous Coward | more than 8 years ago | (#15067750)

A POST requires a bit more know-how,


Or a Firefox extension [mozilla.org] .

A

Re:How is this different (1)

cyngus (753668) | more than 8 years ago | (#15067515)

Its not. As far as your server is concerned, there is no difference. What is AJAX? Its a way to send an HTTP request without changing the page displayed in the browser. From the server point of view, an HTTP request is an HTTP request is an HTTP request. Rule #1 of web applications, trust no parameter. I spend probably 20% of my time validating parameters in one way or the other. Let's say we're talking about a forum and you receive a delete request along with a post id. First, validate the post ID. Then validate that this post belongs to the user (assuming you're using something like the Tomcat Realms session management system). I mean, these are basics and AJAX doesn't change the way the game is played. It provides a different path for submitting HTTP requests, but it doesn't provide a fundamentally different HTTP request.

Obligatory (3, Funny)

frodo from middle ea (602941) | more than 8 years ago | (#15066141)

I write only static HTML you insensitive clod.

Re:Obligatory (1)

skurrier (643587) | more than 8 years ago | (#15066655)

I only write plain text, in uppercase, you insensitive clod.

Re:Obligatory (1)

aurb (674003) | more than 8 years ago | (#15066751)

Yes, but is your HTML Secure?

Re:Obligatory (1)

cshark (673578) | more than 8 years ago | (#15066952)

Whatever man, this argument hurts my feelings.
I'm just going to go back to my hyperlinked help system now.

Just switch javascript off... (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15066151)

Disadvantages:

  1. AJAX apps and badly coded web pages no longer work

Advantages:

  1. Eliminates most browser vuls
  2. Eliminates most XSS type vulns
  3. AJAX apps and badly coded web pages no longer work

Take that web2.0!

PS: captcha is "exploits"

No (1)

hjf (703092) | more than 8 years ago | (#15066156)

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

But we already know this... (2, Insightful)

liliafan (454080) | more than 8 years ago | (#15066175)

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.

Re:But we already know this... (1)

haralder (681551) | more than 8 years ago | (#15066553)

things most web developers should already know

You are right, they should know it. But I can guarantee that reality is much harder.

Re:But we already know this... (1)

Karma Farmer (595141) | more than 8 years ago | (#15066796)

Pretty much everything in this article seems to be a complete rehash of things most web developers should already know

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 idea how to describe, recognize, or fix any of them.

Re:But we already know this... (1)

billcopc (196330) | more than 8 years ago | (#15067481)

I always figured security was rather simple, you just have to pretend to be the MPAA/RIAA: treat everything and everyone as criminals. Any data, ANY DATA coming from a browser has to be validated to hell and back. If there's anything sketchy about the request, send back an error message and let the user try again. Any foreign characters ? Escape them if you really want them (e.g. posting code in a forum or CMS), or else loudly complain to the user and tell them to play nice.

When dealing with web sites, I've always found it very handy to log any suspicious activity, at least in the beginning. This will let you see where and what the red flags are, and maybe give you some insight into what kind of sneaky shit the users are trying to pull. Sometimes it will expose usability problems, like breaking the Back button or maybe one of your forms needs to be simplified/explained. In any case, it will give you tools to harden your app.

AJAX App Secure? (2, Funny)

digitaldc (879047) | more than 8 years ago | (#15066179)

If not, you need to clean it up! [colgate.com]
Code cleanliness is next to Dev godliness.

You're doing it the wrong way (0, Offtopic)

BadAnalogyGuy (945258) | more than 8 years ago | (#15066180)

Force your users to use IE. Make them install ActiveX controls that host your program. Exploit their PCs.

Sheep need to be led.

Re:You're doing it the wrong way (0)

Anonymous Coward | more than 8 years ago | (#15066441)

Simon? Is that you?

Challenges of AJAX (3, Interesting)

cyberjessy (444290) | more than 8 years ago | (#15066207)

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()

Re:Challenges of AJAX (1)

misleb (129952) | more than 8 years ago | (#15066526)

Sure, but there are typically any number of links on that non-AJAX page that make similar requests for data. All of which use GET requests... exactly the kind of thing that the author of the article warned against.

-matthew

Re:Challenges of AJAX (0)

Anonymous Coward | more than 8 years ago | (#15066530)

That statement is a little misleading, as security is not directly related to requests being asynchronous. I think what the poster meant is that...

Having skimmed the article, I think that it's likely that the poster simply doesn't know what "asynchronous" means. He's an idiot. Let me quote you some gems:

Do you even check referrers or some trivial token such as the user-agent? Chances are you do not even know. Chances are that other people, by now, do.

Using GET is a major mistake-a-to-make. POST is a lot better, as it harder to fake. The XmlHttpRequest can easily do a POST. But I cannot get a script, for instance I could have embedded one in this article, to do a POST request to another website

Yes, you can. You just create a hidden form that POSTs to a hidden iframe. You don't need XMLHttpRequest.

His "my prediction" sequence numbering is a poor reinvention of transaction cookies (note: not HTTP cookies), already widely used. This is a really shitty article, written by an amateur new to the field.

Re:Challenges of AJAX (1)

grimJester (890090) | more than 8 years ago | (#15066540)

Actually, I think AJAX creates security problems because most coders consider problematic input from the user to their app, not necessarily input from their client to their server. I imagine sloppy coders put javascript checks on input for convenience and forget to check the input the server recieves for cases the javascript would have caught.

Re:Challenges of AJAX (1)

supersnail (106701) | more than 8 years ago | (#15067729)

All the "loopholes" described in the rather brain dead article describe security holes at the server end.
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 that your web server application is insecure if you code it badly and even if you code it well you can still be subject to DOS attacks.
This is not news.
   

Enough already (0, Flamebait)

gregarican (694358) | more than 8 years ago | (#15066209)

I am growing sick of hype surrounding the AJAX bandwagon. It reminds me of the mid 1990's when the advent of Java had folks proclaiming how web based applications would be the preferred way of creating new applications across the board. Yeah, right. In short, web based apps have their purpose and can be effective. But they aren't the savior to mankind and the AJAX delivery method has been around for years now. We didn't use crudely fashioned stone tools then either.

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.

Enough with "Enough already" (0)

Anonymous Coward | more than 8 years ago | (#15066436)

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.

Re:Enough with "Enough already" (2, Insightful)

Bogtha (906264) | more than 8 years ago | (#15066587)

What, how is an article that talks about security vulns hype?

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 many times as possible.

Re:Enough with "Enough already" (2, Insightful)

gregarican (694358) | more than 8 years ago | (#15066708)

You hit the nail on the head regarding the source of my rant. The article is just cashing in on the craze and adds nothing of value to the broader subject of web app security as it applies to all of the non-AJAX world. The cashing in idea reminds me when I was a kid growing up in the 70's. When roller skating was popular all of these shows threw skating rink scenes into their episodes for no apparent reason just to cash in. Disco dancing obviously another sad, sad example too. Someone please mod me offtopic now :-)

Re:Enough with "Enough already" (1)

the chao goes mu (700713) | more than 8 years ago | (#15068556)

You forgot the late 90's trend of adding "virtual" to everything. Or adding "e" to the begining of any word (which Apple morphed into adding "i" to everything).

Re:Enough already (1)

misleb (129952) | more than 8 years ago | (#15066572)

And I'm getting tired of people who have knee jerk reactions to any mention of AJAX regardless of the content. Did you even RTFA? There was no hype in it. Although I am still wondering what the poitn of it was. Seemed to me that everything they talked about would apply to "regular" web pages.

-matthew

Isn't that always a threat? (4, Insightful)

MikeRT (947531) | more than 8 years ago | (#15066226)

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.

Re:Isn't that always a threat? (1)

_xeno_ (155264) | more than 8 years ago | (#15066482)

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 over GET. It's something that people should be able to figure out, but not necessarily something that people do figure out.

Re:Isn't that always a threat? (1)

Karma Farmer (595141) | more than 8 years ago | (#15066656)

I really wish I was kidding, the first response to "we should never do this" was "oh, so we should be using POST instead?"

I really wish I was kidding, but the first thing the article suggests is using POST instead.

Re:Isn't that always a threat? (1)

makomk (752139) | more than 8 years ago | (#15067386)

I really wish I was kidding, but the first thing the article suggests is using POST instead.

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). LiveJournal had some problems related to this (now mostly fixed).

Re:Isn't that always a threat? (1)

lukewarmfusion (726141) | more than 8 years ago | (#15066687)

Many developers learn it the hard way - when someone exploits them. My eyes were opened to security when the client's parent company audited our work and found holes.

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? (1)

the chao goes mu (700713) | more than 8 years ago | (#15068631)

I know what you mean. At one job I found a web page with the argument (in a GET statement) "include=file.html". I decided to play with it a bit (it wasn't my code and I didn't have any read/write rights to that directory) and tried "include=../../../../../etc/passwd". Surprise! I could read it. And /etc/vfstab, and pretty much everything else I wanted short of /etc/shadow. I also discovered that our cgi executables contained hardcoded username/password pairs visible when this webpage tried to read them as text. My boss' reaction "So, why is this a problem?".

Re:Isn't that always a threat? (1)

franky999 (921789) | more than 8 years ago | (#15066501)

But it's hip!

Re:Isn't that always a threat? (1)

MyLongNickName (822545) | more than 8 years ago | (#15066574)

Avoid SQL injection by not relying on dynamic SQL queries. Use Stored Procedures, and you avoid a lot of risks. Users do not even need rights to underlying tables. If you insist on dynamically generating SQL based on user input, then triple check everything and pray a lot.

I don't understand giving attackers a free attack vector in your applications.

Re:Isn't that always a threat? (1)

MagicM (85041) | more than 8 years ago | (#15066788)

Avoid SQL injection by not concatenating user input into your dynamic SQL queries. Use bind variables [akadia.com] , and you avoid a lot of risks while still maintaining all the flexibility. As a bonus, you may end up with improved performance.

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? (2, Informative)

rjstanford (69735) | more than 8 years ago | (#15067292)

As a bonus, you may end up with improved performance

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 apostrophe into a free-form text field. [shudder]

Poor article. (1)

Anonymous Coward | more than 8 years ago | (#15066257)

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

Something new ? (1)

Spliffster (755587) | more than 8 years ago | (#15066283)

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

Asynchronous? (1)

Alioth (221270) | more than 8 years ago | (#15066301)

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.

Maybe I'm stupid (1)

LS (57954) | more than 8 years ago | (#15066329)

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?

Re:Maybe I'm stupid (1)

colinbrash (938368) | more than 8 years ago | (#15066842)

Or is this just a chance to write an article using the latest buzzword?

Take AJAX a wild AJAX guess. AJAX.

Re:Maybe I'm stupid (1)

the chao goes mu (700713) | more than 8 years ago | (#15068681)

If I had mod points I would mod you +5 interesting! Something about what you said just fascinates me!

Re:Maybe I'm stupid (1)

porneL (674499) | more than 8 years ago | (#15066863)

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 (1)

Serapth (643581) | more than 8 years ago | (#15067207)

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.

asynchronous? (1)

Douglas Simmons (628988) | more than 8 years ago | (#15066353)

what does the author mean using this word in this context? yes I looked it up [reference.com]

Re:asynchronous? (0)

Anonymous Coward | more than 8 years ago | (#15067039)

I believe the idea is that the browser and the server don't need guaranteed agreement on a time frame, and the server does other things until the browser asks for a content refresh. That is, the server doesn't sit and wait for the browser to ask for content; it can handle other requests or exit and let another server instance handle the next request. The browser, on the other hand, may be tied up doing other things when it's supposed to get a refresh (and the refresh comes late), or there may be server lag and the browser continues to allow the user to manipulate the old page until the new data arrives.

I suppose the implications for security are that you could conceivably form a malicious request by creating two requests that check out okay by themselves, but are mutually incompatible. As a completely contrived example, suppose you had a store that kept user info, including the contents of the current shopping cart, in a database. When the Check-out button is clicked, the amount referred to on-screen is billed to the user's credit card and all the items in the shopping cart are marked as "SHIP TO USER." So if the user has multiple windows/tabs open, he can add a few items to his shopping cart in one window, and then click Check-out in another, and get a few items for free. Of course, being able to exploit this requires a great degree of familiarity with the system, not to mention a great deal of poor design to begin with.

The same thing... (1)

C10H14N2 (640033) | more than 8 years ago | (#15067335)

...everyone else concerned with the topic means by it:

http://en.wikipedia.org/wiki/AJAX [wikipedia.org]

Additional AJAX Security Resources (0)

Anonymous Coward | more than 8 years ago | (#15066375)


AJAX Security [cgisecurity.com]

Sequence numbering? For sure? (1)

MasterC (70492) | more than 8 years ago | (#15066399)

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.

Re:Sequence numbering? For sure? (1)

DavidTC (10147) | more than 8 years ago | (#15066434)

Not to mention that someone can have a legit number, and still be doing what they're not supposed to be doing.

Re:Sequence numbering? For sure? (3, Informative)

Bogtha (906264) | more than 8 years ago | (#15066722)

The only difference between guessing this sequence number and guessing the session ID in a cookie is only that of duration

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.

POST is more secure, WTF? (1)

Anonymous Coward | more than 8 years ago | (#15066402)

He states POST is more secure because it is harder to fake?? Nice joke.

Re:POST is more secure, WTF? (1)

DahGhostfacedFiddlah (470393) | more than 8 years ago | (#15067233)

The only way I can see POST being more secure is that web-apps that display HTML content may strip out a lot of tags and javascript, but pass image/link urls through without validation.

An image or link can't send information to a script that only accepts POSTs.

Check out this link [slashdot.org] for more information.

What? (1)

cosinezero (833532) | more than 8 years ago | (#15066403)

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.

Can someone explain...? (1)

misleb (129952) | more than 8 years ago | (#15066409)

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

Re:Can someone explain...? (0)

Anonymous Coward | more than 8 years ago | (#15066657)

Because it's trivial to expose the guts of your api with AJAX, whereas GET and POST typically go through a single well-defined and secured interface. Most AJAX API's pay short shrift to security and don't even give you a decent way to secure their remoting interface.

I guess that analysis just flew over the heads of all the knee-jerkers here.

Re:Can someone explain...? (1)

misleb (129952) | more than 8 years ago | (#15067549)

Because it's trivial to expose the guts of your api with AJAX, whereas GET and POST typically go through a single well-defined and secured interface.
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.
Most AJAX API's pay short shrift to security and don't even give you a decent way to secure their remoting interface.
The only two AJAX APIs i've used extensively are JPSpan and Prototype/Ruby on Rails. JPSpan most certainly defines a single point of entry for ALL ajax requests, typically called server.php. And RoR treats AJAX requests as the same as any other request. So I have no idea what yo are talking about. And since you are an (anonymous) coward, I don't suspect I'll get an opportunity to find out either.

-matthew

This is security advice? (1)

arevos (659374) | more than 8 years ago | (#15066457)

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.

Re:This is security advice? (2, Informative)

possible (123857) | more than 8 years ago | (#15067461)

The way to secure AJAX is the same way classic CGI transactions are secured; through sessions, passwords and SSL.

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 application by using HTTPS and entering a password. A randomly generated session ID is stored in a cookie on your browser. Now in another tab, you browse to evil.com, which has some AJAX JavaScript which causes your browser to send a complete, well-formed HTTP POST request (including session cookie) to your webmail application. The POST request changes your webmail password to a known value (chosen by evil.com). The webmail application designers followed all of your suggestions (HTTPS, passwords, and session IDs), yet some random site on the internet just changed your webmail password without you even knowing.

Go read the Cross-site request forgery [wikipedia.org] article on Wikipedia.

without RTFA .... (1)

cyclomedia (882859) | more than 8 years ago | (#15066515)

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

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 ... i'd expect to be fired for making it that simple

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 :-)

Re:without RTFA .... (1)

martinmarv (920771) | more than 8 years ago | (#15066742)

6. dont use "UPDATE" or "INSERT" or "DELETE" querys

What do you mean? Only use stored procedures? You can safely use the above if you parameterise them (as long as the queries are on the server-side code, and not embedded in the javascript or something silly like that).

Re:without RTFA .... (1)

arevos (659374) | more than 8 years ago | (#15066783)

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

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.

Running the numbers through an MD5/SHA1 hash is also often used. But surely session handling is mostly automatic in this day and age? I can't remember the last time I had to think about manually constructing a session cookie and session ID.

6. dont use "UPDATE" or "INSERT" or "DELETE" querys

Eh? What do you mean by this?

Re:without RTFA .... (0)

Anonymous Coward | more than 8 years ago | (#15067038)

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 ... i'd expect to be fired for making it that simple

I actually used to work at one web development agency, and one of the first things I had to do upon starting work there was fix about a dozen online shopping websites so that this wasn't a problem. What would happen was that the buyer would complete his transaction, and end up at something like /confirmation.asp?id=12345, which was a page (using SSL! Yay for security!) displaying the visitor's name, address, order details, and their full credit card details. Of course, any remotely observant visitor could simply decrement the ID number repeatedly to look at previous orders. But at least it was encrypted!

These websites earned the agency tens of thousands of pounds each, but they were completely atrocious. Of course, the businesses hiring us had no idea how to evaluate security, so they got fleeced. I distinctly remember my boss telling a client who had a complaint about somebody not being able to use their website in Opera that he was a no-good hacker with too much time on his hands and should be ignored.

I have my own business these days, and unfortunately, I still lose contracts to people like these, because clients simply don't believe that "respectable" agencies that have been going for a decade would churn out something as awful as they tend to do.

Re:without RTFA .... (1)

rjstanford (69735) | more than 8 years ago | (#15067227)

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.

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 you need to re-encode it - ick. Keep it native as long as possible and HTML encode it on the way out.

But really, none of that should be necessary. Your app should never, ever, be creating a big long string of SQL. Its about the least efficient way to communicate with your database. Write all of your queries using bind variables (effectively placeholders for values, often a ? in the string). Prepare them once (some modern databases will correctly cache and pool them for you even if you skip this step) and execute them with the variables containing your data.

Making all of your queries this way means that there's no, nada, zero chance of the content of one of those variables ever "infecting" your database, because the database knows at a fundamental level which information is instruction (your SQL command) and which information is data (contained in your variables). Doing anything else is asking for trouble, no matter how well you think you may have checked the data.

So. Its faster, easier, and more secure. Its supported by every major database language layer that I know of. And its more "standards-compliant" to boot. Life is good, no?

Stupid comment (1)

brunes69 (86786) | more than 8 years ago | (#15066660)

....as it's asychronous and a malicious user could write data back to your database if implemented incorrectly."

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.

AJAX STDs cleaning (0)

Anonymous Coward | more than 8 years ago | (#15066733)

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?

TraficShield (0)

Anonymous Coward | more than 8 years ago | (#15066785)

http://www.f5.com/products/TrafficShield/ [f5.com]

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.

Network security 101 (3, Informative)

Aceticon (140883) | more than 8 years ago | (#15066875)

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.

Use Fiddler for this analysis (0)

Anonymous Coward | more than 8 years ago | (#15066955)

If you're going to investigate this, try using Fiddler (http://www.fiddlertool.com/ [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" :)

buzzword wins, flawless victory (1)

Flunitrazepam (664690) | more than 8 years ago | (#15066989)

In Mortal Kombat 2, A JAX fatility showed a large African American man rip the arms off his enemy.

"AJAX" alternative? (2, Interesting)

greywire (78262) | more than 8 years ago | (#15067098)

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

Re:"AJAX" alternative? (1)

merreborn (853723) | more than 8 years ago | (#15068817)

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":

Good luck. I've been asking for years what the Fi in WiFi means. Wireless Fidelity? What the hell does that mean?

Someone suggested "Wireless Frequency" which is even stupider, as there is no one "Wireless Frequency" (not even amoung the 802.11 standards) -- not to mention the fact that it's an unused term ...and I don't know how "Frequency" shortens to "Fi".

I suggested WiNet, as in WIreless NETworking. Haven't gotten any takers yet.

Re:"AJAX" alternative? (1)

the chao goes mu (700713) | more than 8 years ago | (#15068829)

How about "JavaScript Kludge, Now With XML!"?

Cross site request forgery (2, Informative)

possible (123857) | more than 8 years ago | (#15067161)

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 [wikipedia.org] and the counter-measures (which the author re-derives from first principles in his article) are already known.

Most secure AJAX app evah (1)

suv4x4 (956391) | more than 8 years ago | (#15067164)

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

I'm pretty sure... (1)

Netsnipe (112692) | more than 8 years ago | (#15067560)

...that my AJAX-based Slashdot posting console is secure.

But most of all, samy is my hero [namb.la] .

all of my servlets (1)

josepha48 (13953) | more than 8 years ago | (#15068148)

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

AJAX like all JS should be supplimental at best (1)

Hohlraum (135212) | more than 8 years ago | (#15068351)

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.

depends on which 'side' you are on (1)

thoughtlover (83833) | more than 8 years ago | (#15068434)

"...and a malicious user could write data back to your database if implemented incorrectly."

Isn't that supposed to be, "...if implemented correctly"
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>