SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    SitePoint Zealot
    Join Date
    Jul 2006
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    security risks of ajax javascript vs. conventional forms

    I want to make a login system with ajax, but everyway I think of doing it seems to be like it would be a major security risk. Is it really that dangerous to set the password and username in a session cookie and then send them to the server any time the user is trying to do something where they would need to be logged in? Isn't that how a regular submit does it? I'm guessing that it would be safer to send the username and password as postdata as opposed to get. But wouldn't a hacker still be able to gain easy access into a members session cookie or intercept the message being sent to the server?

  2. #2
    SitePoint Addict dek's Avatar
    Join Date
    Oct 2004
    Location
    UK
    Posts
    352
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Whether you're using AJAX or not, you should never ever ever store usernames / passwords in a clientside cookie. The common way to do it is to store a session reference in a cookie, and maintain the session information serverside.

    The two main additional risks you run by using AJAX techniques - firstly, you must subject all AJAX'd calls to the server to the same security checks you'd use on anything else (session check, IP check, timeout check etc) - some security problems have arisen when coders have just assumed this wasn't necessary. The other, and more subtle thing to be concerned about is the possibility of outsiders hijacking your ajax responses to inject malicious code to the client-side (if you're eval'ing your responses, for example) - I don't know a whole lot about the feasiblity of this one however.
    Only dead fish go with the flow

  3. #3
    SitePoint Zealot
    Join Date
    Jul 2006
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not evaling code, but I am sending say "javascript.js" as a string and then loading that through the source attribute. Is that safe? From what I've been reading it seems to be.

    I was origionally going to store a reference to a session, but I thought that was impossible. I guess I'll have to figure out how to do that.

    What about the security checks? I wouldn't need to send security checks on something that I wouldn't need security checks for regularly would I? I know that for a user to update a page I couldn't just assume that becuase the user is logged in he could update, that I would have to basically re-log the user in. But I don't need to do that to just send the user a regular page right? I don't really see why I would need to.

  4. #4
    SitePoint Addict dek's Avatar
    Join Date
    Oct 2004
    Location
    UK
    Posts
    352
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by yahn
    I'm not evaling code, but I am sending say "javascript.js" as a string and then loading that through the source attribute. Is that safe? From what I've been reading it seems to be.
    Should be. It has it's own implementation issues, and you need to ensure that your code can only load local scripts, but that sounds fine.
    Quote Originally Posted by yahn
    I was origionally going to store a reference to a session, but I thought that was impossible. I guess I'll have to figure out how to do that.
    That's a serverside issue really. What serverside environment are you building this in?
    Quote Originally Posted by yahn
    What about the security checks? I wouldn't need to send security checks on something that I wouldn't need security checks for regularly would I?
    You don't send security checks as such, but you can use the session token to ensure they have a valid session and have logged in, you can check that their IP address is the same and kill the session if not, you can check for inactivity timeouts... all serverside stuff. For obvious reasons, no clientside security checks can be trusted.
    Quote Originally Posted by yahn
    I know that for a user to update a page I couldn't just assume that becuase the user is logged in he could update, that I would have to basically re-log the user in. But I don't need to do that to just send the user a regular page right? I don't really see why I would need to.
    I don't see why not - it depends on the way you've structured things, but I work on the principle of logging in once and maintaining that session information. So long as you take steps as suggested to make sure that sessions cannot be hijacked easily, that should be fine.

    Of course - it probably goes without saying that if you want it to be truly secure, you need to go the https:// route.
    Only dead fish go with the flow

  5. #5
    SitePoint Zealot
    Join Date
    Jul 2006
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think I found a pretty secure way to handle a login session. Although It does seem to be pretty server strenuous and I'm not really sure if I solved any of my problems. I think I did since I encrypted the data with the REMOTE_ADDR. I took another look into the one example I could find and I got the basic idea for what I'm doing here.

    First I send a request to the server for a seed. The server sees if your ip is in the database of users logged in, if it is it will send you the seed of the session you already should have, if you arn't then it makes a new seed. To make a seed I just generate a random string and add the date to it and then hash that with a hash encryption and take a part of the string to use as the seed. I store the seed and the ip in the database and I send the seed and the id of the seed in the database back to the user. When you go to login I send the seed id the username and password to the server. At the server, I hash the password and username to match how it would be stored in the database. If then I hash the username, password, and random string together and send it to the client. I then take that hash and add the REMOTE_ADDR and hash that and store it in the database. Whenever the client wants to do something that would require him to be logged in, I send the seed, seed id, and the hash stored in the database to the server. If the hash of the client's hash appended by the client's ip equals the hash stored in ther server at the seed id I allow them to do whatever it was that would require them to be logged in.

    My first question is, is that safe enough? Should I sha1 the password before I send it to the server and then sha1 it again at the server before I store it? Does the REMOTE_ADDR in php really solve the issue? I thought that it would make it so a hacker couldn't steal the session since his REMOTE_ADDR would be different? I wasn't sure if I needed to sha1 the password before I sent it to the server because I thought conventionally you didn't have to. I also thought that since the hash stored in the database was the hash of the clients hash and his ip put together that it was safe to store that hash in a variable.

    Is this method secure or is it a joke to hacker?


Bookmarks

Posting Permissions

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