Forgot your password?
typodupeerror

Is Your AJAX App Secure? 142

Posted by CmdrTaco
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.

Is Your AJAX App Secure?

Comments Filter:
  • JUG (Score:4, Insightful)

    by eldavojohn (898314) * <eldavojohnNO@SPAMgmail.com> on Wednesday April 05, 2006 @10:14AM (#15066102) Journal
    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 (Score:5, Informative)

      by stunt_penguin (906223) on Wednesday April 05, 2006 @10:21AM (#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)
      • ny (Score:4, Insightful)

        by Pieroxy (222434) on Wednesday April 05, 2006 @02:28PM (#15069027) Homepage
        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.
        • The problem I see with AJAX is that IE doesn't reliably pass the session cookie from the browser session when it creates a XmlHttpRequest; sometimes it creates a new session instead of maintaining the old one. So if you're using sessions to create a secure user experience, you can't secure anything you interact with using AJAX. I personally find it a real pain in the ass.
        • Sorry, by 'you pass your request into your pre-written function which has any request-related security processes written into it' I did mean server-side because of course, yes, anything that comes out of your box can be monkeyed with and you can only really, really validate input security-wise on the server side. Heh, I shoulda been clearer :o)
    • 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 ide [shiflett.org]
    • by Z34107 (925136)

      Actually, UUIDs are NOT (pseudo)random. The generator has to be mathematically guaranteed never to generate the same UUID twice, or otherwise, the whole concept of a UUID breaks down.

  • 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!
    • by 0110011001110101 (881374) on Wednesday April 05, 2006 @10:57AM (#15066511) Journal
      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.

  • by El_Muerte_TDS (592157) <elmuerte.drunksnipers@com> on Wednesday April 05, 2006 @10:17AM (#15066130) Homepage
    How is this different from securing a "normal" dynamic website?
    • by grazzy (56382) <grazzy@@@quake...swe...net> on Wednesday April 05, 2006 @10:21AM (#15066176) Homepage Journal
      There was a new buzzword in the middle of the sentence.
      • 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.
        • 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 he

          • I think Beryllium Sphere(tm) maybe was being sarcastic?

            Anyway, the article itself contained absolutely nothing new imho. Worse, it seems to suggest craptastic security measures such as checking referer or user-agent strings, and using POST rather than GET because its harder to fake! I mean, yeah, but none of these things will actually make the application safer in any real sense -- only very very slightly moderately harder to attack. ish.

            And what was this about:
            "If I would be able to insert Javascript
    • by stromthurman (588355) on Wednesday April 05, 2006 @11:08AM (#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.

      • by pikine (771084) on Wednesday April 05, 2006 @11:55AM (#15067170) Journal

        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.

      • 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
    • 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
      • What is AJAX? it is a method to get the marketingdroids, graphic artists and "web" designers off your ass about including unreasonable amounts gratutuious graphics and flash bullshit. If the simple page didn't include 1 meg of crap, you wouldn't even need AJAX; yeah I know google maps is a cool AJAXs app and necessary, but most I've seen is just AJAX for AJAX's sake.
    • Not different at all.

      To the security of a site, it makes precisely zero difference if the *clientside* is running javascript, asynchronous http-requests, or consists of a guy writing "telnet yourhost 80"

      You must remain secure regardless of what the client sends you. You cannot trust the client. This does in no way whatsoever change if "Ajax" or any other buzzword of the day is involved.

    • It's important to make sure your AJAX code is well written, and maybe using SSL with it can help protect your code as well. But the big security problem is that if you're running AJAX, your user has to turn on Javascript in their browser, so if they view a web page that's written by somebody malicious and haven't turned Javascript back off first, they're toast. There are Firefox extensions that let you enable/disable Javascript on a per-site basis, and IE has some similar features, but if your users aren
  • Obligatory (Score:4, Funny)

    by frodo from middle ea (602941) on Wednesday April 05, 2006 @10:18AM (#15066141) Homepage
    I write only static HTML you insensitive clod.
  • 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 litt
    • things most web developers should already know

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

    • 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 ide
  • by digitaldc (879047) * on Wednesday April 05, 2006 @10:22AM (#15066179)
    If not, you need to clean it up! [colgate.com]
    Code cleanliness is next to Dev godliness.
  • Challenges of AJAX (Score:4, Interesting)

    by cyberjessy (444290) on Wednesday April 05, 2006 @10:24AM (#15066207) Homepage
    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()
    • 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
    • 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.
    • 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
  • Enough already (Score:1, Flamebait)

    by gregarican (694358)
    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 cou

    • 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
  • by MikeRT (947531) on Wednesday April 05, 2006 @10:27AM (#15066226) Homepage
    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.
    • 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

      • 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.
        • 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). L
      • 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...
        • 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 t
    • 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.
      • 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.
        • 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 apostro
  • by Anonymous Coward
    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), o
  • 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
  • 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?
    • Or is this just a chance to write an article using the latest buzzword?

      Take AJAX a wild AJAX guess. AJAX.
    • 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.

    • 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 clien
  • what does the author mean using this word in this context? yes I looked it up [reference.com]
  • 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'
    • Not to mention that someone can have a legit number, and still be doing what they're not supposed to be doing.
    • by Bogtha (906264) on Wednesday April 05, 2006 @11:17AM (#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.

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

          <img src="http://www.example.com/foowebapp/delete-stuff .php?id=12345">

          ...and this submits a POST request to delete something:

          <body onload

  • by Anonymous Coward
    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
  • 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
    • 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 ap

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

        XMLHttpRequest can only send HTTP requests to the same domain from which it was invoked. Likewise, cookies can only be read from the domain from which they were inv

  • 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 ev
    • 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).
    • 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 th

    • 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 yo
    • MOD PARENT DOWN! (Score:2, Informative)

      by Anonymous Coward
      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
  • ....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 wr

  • Network security 101 (Score:4, Informative)

    by Aceticon (140883) on Wednesday April 05, 2006 @11:31AM (#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.

  • In Mortal Kombat 2, A JAX fatility showed a large African American man rip the arms off his enemy.
  • "AJAX" alternative? (Score:3, Interesting)

    by greywire (78262) on Wednesday April 05, 2006 @11:49AM (#15067098) Homepage
    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...
    • 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
      • Good luck. I've been asking for years what the Fi in WiFi means. Wireless Fidelity? What the hell does that mean?
        That's definately another one. I hate saying WiFi, but these days its what people understand. If you say 802.11 you get a blank stare. If you say wireless, they dont know if you mean cell phone, bluetooth, RC Cars, or what...
    • How about "JavaScript Kludge, Now With XML!"?
    • Personally, I refer to it as 20 Mule Team BORAX (Bidirectional Object Reuse Atop XML).

      20 Mule Team BORAX. Accept no substitutes!

      • Well done.

        I am sure this SHOULD be the new name.

        When I was a kid there was a powdered soap called Boraxo (a quick check later and it appears to still exist).

        Great stuff.
    • by screaser (901255)
      I've read and believe that AJAX is being or has been de-acronym-ified...

      AJAX is just a proper noun now, referring more to the user interaction style used in the BLURG apps you mention, and doesn't need to use any specific technology.

      i.e. Don't shove the whole user interface down the pipe every time the user clicks... adapt the interface as work progresses... etc.

      The term is probably here to stay... so we might as well make it mean what we want it to.
    • How about Web 2.0?

      Dan East
    • Web 2.0: We Are Finaly Understanding The Internet (WAFUTI).

      Not quite as cute a name, but, WAFUTI is pronouncable.. :)
  • by possible (123857) on Wednesday April 05, 2006 @11:54AM (#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.
  • - 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,
  • ...that my AJAX-based Slashdot posting console is secure.

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

  • .. 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.
  • Browser.... request .... security .... application
    Browser.... asynch request .... security .... application

    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.

"Maintain an awareness for contribution -- to your schedule, your project, our company." -- A Group of Employees

Working...