Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 19
  1. #1
    Regular Coder
    Join Date
    Oct 2007
    Posts
    277
    Thanks
    2
    Thanked 4 Times in 4 Posts

    What is the best way to secure my ajax requests?

    I am making an app which will later on allow developers to make plugins for the user to add to his account, but I am starting to think this kind of thing is a security risk because my app is mostly based on ajax and for instance if my app asks the server to delete a file the server accepts, but how will it know if that request was sent by my app and not by a plugin?

    The plugins reside in iframes which javascript allows to send ajax requests to the domain of the page.

    I would really appreciate any help.
    thanks.

  • #2
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,400
    Thanks
    11
    Thanked 595 Times in 575 Posts
    Quote Originally Posted by shedokan View Post
    if my app asks the server to delete a file the server accepts, but how will it know if that request was sent by my app and not by a plugin?
    the server can only examine the info it has available to make this choice. Sounds like you should be authenticating users using some kind of login.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #3
    Kor
    Kor is offline
    Red Devil Mod Kor's Avatar
    Join Date
    Apr 2003
    Location
    Bucharest, ROMANIA
    Posts
    8,478
    Thanks
    58
    Thanked 379 Times in 375 Posts
    You should also "clean" the query before sending it to the database (real escape the values). If the server-language is php, you may use something like:
    PHP Code:
    function clean_variable($variable) {
    $variable mysql_real_escape_string(trim($variable));
    return 
    $variable;
    }
    function 
    clean_array($array) {
        return 
    array_map('mysql_real_escape_string'$array);

    KOR
    Offshore programming
    -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

  • #4
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    26,561
    Thanks
    80
    Thanked 4,494 Times in 4,458 Posts
    I think that shedokan is making the point that if somebody simply invokes the URL of his AJAX handler directly from a browser--or from some hacker's fun application--then what protection does he have?

    After all, the typical AJAX request is nothing more than a URL with a query string.

    *IF* the PHP session information is available in the AJAX handler, then presumably a lack of session info would indicate a hack attempt. But if there is no session info available to the PHP handler, then I think he has to create his own security system. Presumably you could have the PHP code that generated the web page also generate a "password" (encrypted, of course) that the JS AJAX code sends to the AJAX server. You should be able to get pretty sophisticated with this. For example, you could encode the IP address along with maybe the time of day and then look for a match in the AJAX server code.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #5
    New Coder
    Join Date
    May 2008
    Posts
    80
    Thanks
    3
    Thanked 3 Times in 3 Posts
    Yes I second old pedant. sessions and cookies are your choices and of course a kind of login system

  • #6
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,400
    Thanks
    11
    Thanked 595 Times in 575 Posts
    set a cookie when the page laods using javascript.
    check for the cookie in php when answering ajax calls.
    most curlers don't bother cloning cookies...
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #7
    New to the CF scene
    Join Date
    Feb 2010
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts
    an an ajax request is just an http post, so your application is not subject to any more vulnerabilities than it is through a web form, so the same rules apply with authentication, sql injection etc..

  • #8
    Regular Coder
    Join Date
    Oct 2007
    Posts
    277
    Thanks
    2
    Thanked 4 Times in 4 Posts
    The problem is that AJAX is the same as redirecting a user to a webpage without any way of them knowing it, it's what makes ajax so convinient - it's behind the scenes.

    So if someone writes a plugin for my app that sends ajax requests to delete all files the user has no way of knowing that, I was thinking of using a special key for each plugin to pass each time they are sending an ajax request and then check for premissions but a malicious plugin can easily use the key the main app uses and make it look like it's coming from the app itself.

    Maybe some sort of not-understandable ajax requests that only I can understand? but what would that be?

    I mean like how AJAX Email clients do it?

    All of the SQL Injection and checking if the user is logged in and all that I got in place, but because the request is coming from the browser I can't know if the user intended to do that action or if it was forged by malicious code.

    Thanks
    Last edited by shedokan; 03-24-2010 at 12:18 PM.

  • #9
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,400
    Thanks
    11
    Thanked 595 Times in 575 Posts
    Quote Originally Posted by shedokan View Post
    So if someone writes a plugin for my app that sends ajax requests to delete all files the user has no way of knowing that, I was thinking of using a special key for each plugin to pass each time they are sending an ajax request and then check for premissions but a malicious plugin can easily use the key the main app uses and make it look like it's coming from the app itself.
    only give the key to your kingdom to folks you trust, or can at least identify and press charges against.

    perhaps it's the plugins that should need a key to do anything.

    do you need plugins to be able to delete all the files?

    HTML email programs don't have anonymously created plugins...
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #10
    Regular Coder
    Join Date
    Oct 2007
    Posts
    277
    Thanks
    2
    Thanked 4 Times in 4 Posts
    I don't have to give the key to anyone, someone could look in my ajax requests and find out my key easily if I will be sending it like http://www.app.com/ajax?key=dfsdfds

    I mean that if I have my app stored in the javascript object window.app a plugin could get the key using window.app.key and use it as if it was their own key. If I would not use keys I would have no idea from who I got the ajax request from.

    HTML email programs somehow protect their ajax requests so a user can't forge them, they maybe build their applications wisely but how can I implement that sort of thing into my apps.

  • #11
    Kor
    Kor is offline
    Red Devil Mod Kor's Avatar
    Join Date
    Apr 2003
    Location
    Bucharest, ROMANIA
    Posts
    8,478
    Thanks
    58
    Thanked 379 Times in 375 Posts
    Essential information (user/password/keys) are not be used via AJAX. You may also block any intrusion on using a server-side SESSION variable which is able to identify the user after he is logged in (but he must not login in with AJAX). That means to use a server-side protection as well. Make sure the SESSION data is destroyed on log out.

    In other words, AJAX was not designed to traffic vital data to a DB. A pure server-side protection is to be used as a filter by all means.

    JavaScript was not created to handle sensitive data from/to a DB.
    Last edited by Kor; 03-24-2010 at 07:39 PM.
    KOR
    Offshore programming
    -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

  • #12
    Regular Coder
    Join Date
    Oct 2007
    Posts
    277
    Thanks
    2
    Thanked 4 Times in 4 Posts
    Quote Originally Posted by Kor View Post
    Essential information (user/password/keys) are not be used via AJAX. You may also block any intrusion on using a server-side SESSION variable which is able to identify the user after he is logged in (but he must not login in with AJAX). That means to use a server-side protection as well. Make sure the SESSION data is destroyed on log out.

    In other words, AJAX was not designed to traffic vital data to a DB. A pure server-side protection is to be used as a filter by all means.

    JavaScript was not created to handle sensitive data from/to a DB.
    I know that, I don't use it for any vital data, but for actions like add/delete and such I'm using it.
    so for instance if the user presses a button to delete something an ajax request is sent to the server:
    http://www.app.com/ajax?do=delete&postid=30
    The server deletes the post and sends a response it was deleted
    javascript removes the post from the webpage

    but what if there was an iframe with a url of a different website which sent an ajax request to my server:
    http://www.app.com/ajax?do=delete&postid=31
    then the code in the iframe would have deleted post number 31 - an action which was not triggered by the user.

    Is there any way of preventing that?

    I'm not talking about a server sending messages to my server, that I can handle, but what if a request from the client side with all of the login cookies intact was sent?

    the server checks the cookies, sees that everything is alright and deletes the post even though the user didn't trigger it.

    If there's no solution to this problem just say so but don't act as if I don't understand the basics of security.

  • #13
    Kor
    Kor is offline
    Red Devil Mod Kor's Avatar
    Join Date
    Apr 2003
    Location
    Bucharest, ROMANIA
    Posts
    8,478
    Thanks
    58
    Thanked 379 Times in 375 Posts
    Are you talking about a DB injection? If php/MySQL read this:

    http://www.php.net/manual/en/securit...-injection.php
    http://www.phpbuilder.com/columns/Pr...y_excerpt.php3
    or a general view on:
    http://en.wikipedia.org/wiki/Code_injection

    or google for
    KOR
    Offshore programming
    -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

  • #14
    Senior Coder
    Join Date
    Jul 2009
    Location
    South Yorkshire, England
    Posts
    2,318
    Thanks
    6
    Thanked 304 Times in 303 Posts
    The O.P is referring to CSRF, XSS etc, I believe.

  • #15
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,400
    Thanks
    11
    Thanked 595 Times in 575 Posts
    Quote Originally Posted by shedokan View Post
    what if there was an iframe with a url of a different website which sent an ajax request to my server:
    http://www.app.com/ajax?do=delete&postid=31
    then the code in the iframe would have deleted post number 31 - an action which was not triggered by the user.
    Is there any way of preventing that?
    a different website cannot make request to your server using ajax, but a server or remote script request could. you can check the refferer header for a match as well. using post instead of get will cut off all non-user-approved (popup-warning) xdomain client-side IO actions.



    Quote Originally Posted by shedokan View Post
    I'm not talking about a server sending messages to my server, that I can handle, but what if a request from the client side with all of the login cookies intact was sent?
    the server checks the cookies, sees that everything is alright and deletes the post even though the user didn't trigger it.
    a script whose context originates from another site will not have access to your cookies.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%


  •  
    Page 1 of 2 12 LastLast

    Tags for this Thread

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •