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

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

  • by Beryllium Sphere(tm) (193358) on Wednesday April 05, 2006 @11:49AM (#15067103) Homepage Journal
    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]
  • 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.
  • by rjstanford (69735) on Wednesday April 05, 2006 @12:03PM (#15067292) Homepage Journal
    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]
  • by possible (123857) on Wednesday April 05, 2006 @12:14PM (#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.

  • MOD PARENT DOWN! (Score:2, Informative)

    by Anonymous Coward on Wednesday April 05, 2006 @03:05PM (#15069423)
    By reading your comments, anyone who has a clue can tell you're definitely a n00b at this. Things like HTML encoding your stuff before committing to DB lets us guess you're concatenating strings - the best way to be vulnerable to SQL injection attacks. Rather bad advice. If you were using parameters (parameterized queries or sprocs) none of this would be necessary. And even though one should strip off nasties from inputs, it becomes less critical that your stripping is 100% bullet proof (it'll never be).

    #6 is just plain stupid. Might as well say "don't use databases". Things like that are required hundreds of times per second in thousands of every production systems. Somehow data HAS to change. And since you're concatenating to generate your queries, you're still more vulnerable to problems than someone using parameters properly - once a flaw is found in your "protection" (that often rely on things like blindly doubling single quotes and such), they can easily tack on a DROP TABLE at the end if they want to, whereas with parameters (again, used properly) it's quite safe to use INSERT/UPDATE/DELETE. (Not to mention, non-web apps will have to needlessly HTML decode stuff to display it when it's completely unecessary). Validating for proper user input (sever side req'd, client side as well preferably) is a must - just removing bad chars (like getting rid of double quotes) is NOT a good way to do this, and it'll often end up just crippling perfectly valid entries you hadn't expected.

    #5 is nonsense. It does NOT matter what it's called. It just has to be secured properly. Or perhaps you're recommending security by obscurity - hopefully they don't ever guess or find out the admin page's directory name or else... I've never had a security problem with my admin pages, even if I put a direct link to them that's accessible to pretty much everybody. As long as they're secured properly it's a non issue. All they'll ever see in an "admin login page".

    Honestly, you're NOWHERE near enough knowledgeable to give advice on how to secure apps. Lots of it is plain wrong, some of it is just a hack or workaround the real problem, and no real problem solving / peroper way to do it. You don't want others to use that, you're essentially doing them a disservice by giving them this wrong info. There's tons of great guides on the web that'll teach 'em all the good stuff that they should be reading instead (and perhaps you too). You still have TONS to learn. This isn't even the tip of the iceberg.

At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.

Working...