SitePoint Sponsor

User Tag List

Results 1 to 23 of 23
  1. #1
    <?php echo"GiroPets"; ?> giropets's Avatar
    Join Date
    Jul 2003
    Location
    United States
    Posts
    242
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question JavaScript Hijacking ???

    Hi everyone,

    This one idiot messenged me telling me that they can hijack accounts on my website through a JavaScript code and have it eMail the username and password to him.

    I told the dude that there is no possible way for a JavaScript code to open the cookie and decrypt passwords, but he goes on with a 2 hour essay stating that this is a big flaw on my site.

    My site has very tough security on the accounts and I doubt that anyone can crack, well, for the exception of people who use really easy-to-guess passwords.

    Anyway, I'm here to ask if this is true or if this is false. I believe that it is false, I highly doubt that any JavaScript code can do that.

    Thanks.

    Best Regards,
    - Mike S.
    GiroPets.net.

  2. #2
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    I am pretty sure javascript can decode a cookie. Thats why you dont put important information in a cookie. You put a hashed password or something so all they see when they decode it is the hashed password, useless. I mean you can see what is in a cookie just by opening it in notepad, so I wouldn't even call it decoding.
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  3. #3
    <?php echo"GiroPets"; ?> giropets's Avatar
    Join Date
    Jul 2003
    Location
    United States
    Posts
    242
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I know that JavaScript can decode things, but he went and said that his code can get the password by only entering a username into the cookie.

  4. #4
    SitePoint Wizard GoldFire's Avatar
    Join Date
    Oct 2002
    Location
    Oklahoma City, OK
    Posts
    1,517
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    try this :

    PHP Code:
    $var preg_replace("#<(.+?)script(.+?)>#is","",$var); 

  5. #5
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    It depends on how your script varifies users. If the script just checks if the users name is in the cookie, then yes he could change the cookie and it validate him as the user.

    For example something like

    if $_COOKIE['name'] == "jack"{
    echo 'welcome back';
    }

    Then he could change the username to make it validate.

    Your user validation should be something like this.

    $name = $_COOKIE['name'];
    // do some database stuff to get that users email or something else stored on that user
    // then tack on a keyword, so the validation would look like this
    if ($_COOKIE['pass'] == md5($myrow['email'].'mykeyword'){
    echo 'welcome back';
    }

    If the code looks similiar to the last example, then there is no way for him to crack it without bruteforcing which would take years.
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  6. #6
    <?php echo"GiroPets"; ?> giropets's Avatar
    Join Date
    Jul 2003
    Location
    United States
    Posts
    242
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My site uses the second method of cookie checking. So, then that means that he can't hijack it then ?

  7. #7
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    I dont see how.
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  8. #8
    SitePoint Wizard GoldFire's Avatar
    Join Date
    Oct 2002
    Location
    Oklahoma City, OK
    Posts
    1,517
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No, believe me he can, did the same thing to me, but the code I gave stopped it.

  9. #9
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Really? How?
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  10. #10
    + platinum's Avatar
    Join Date
    Jun 2001
    Location
    Adelaide, Australia
    Posts
    6,441
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    They could potentionally use javascript to grab the cookie details, and retrieve the username and hashed password, then get it to pass the details onto them through a mallicious script.

    Basically, don't allow them to run javascript from your site, and it should be fine. They would phyicially have to run these commands on your site for it to work like this btw (by means of posting a message, or similar).

  11. #11
    SitePoint Wizard GoldFire's Avatar
    Join Date
    Oct 2002
    Location
    Oklahoma City, OK
    Posts
    1,517
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, exactly platinum And that is what the code is for that I gave you, that will filter out javascript so they can't grab your users' cookies

  12. #12
    <?php echo"GiroPets"; ?> giropets's Avatar
    Join Date
    Jul 2003
    Location
    United States
    Posts
    242
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok thanks everyone.

  13. #13
    SitePoint Guru okrogius's Avatar
    Join Date
    Mar 2002
    Location
    US
    Posts
    622
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by schooglepets
    Yes, exactly platinum And that is what the code is for that I gave you, that will filter out javascript so they can't grab your users' cookies
    Wrong, wrong, wrong.

    How about <script>? Oops, doesn't get that. Well you say what's the issue? 1- type the entire script on your site, 2- use the less well known importing command within that script tag. I'm not even going to think about five billion other tags which can screw your site over.

    You should never allow any html whatsoever. If you display user content always run it through a safety function like htmlspecialchars();

  14. #14
    SitePoint Wizard silver trophy KLB's Avatar
    Join Date
    Nov 2003
    Location
    Maine USA
    Posts
    3,781
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My advice is to NEVER store username or password in a cookie, whether it is encrypted or hashed or not.

    Instead the cookie should store a hashed "session id" or to make it more difficult, a randomly generated hashed user id and a hashed session id. These hashes should not be generated using password information. MD5 hashes are a great hash to generate because they are un reversable and are large enough to always be unique if unique information is used to generate them.

    The user id hash can be generated by combining different data fields in your user table with a time stamp and then hashing this string. Session ids can be generated using a simular method.

    Code:
    <?
    $RandomString = rand(100,900000000);
    $StringToHash = $RandomString.$field1.$field2.$field3.$field4.microtime();
    $HashedUserID = md5($StringToHash);
    ?>
    This Hashed string would be stored in the database record for the user. In addition a simular string would be generated and stored in the session record each time the user logged in. By using a table to store hashed sessions, you can expire out the session id reducing the risk of a cookie being misused. The level of protection could be increased by simply storing the IP address and browser string in the session record and not only comparing the session id against the session record but the IP address and browser string. This would prevent a cookie from being stolen or shared and used on a different computer.

    The beauty of this method is that the cookie contains keys that are non-recoverable, non-repeating and have a limited shelf life.
    Ken Barbalace: EnvironmentalChemistry.com (Blog, Careers)
    InternetSAR.org
    Volunteers Assist Search and Rescue via Internet
    My Firefox Theme: Classic Compact
    Based onFirefox's default theme but uses much less window space

  15. #15
    + platinum's Avatar
    Join Date
    Jun 2001
    Location
    Adelaide, Australia
    Posts
    6,441
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    KLB: how does that make any difference. You can use the same method to grab the "sessionID" out of the cookie and use that instead.

    Although that method does have merits over storing username/hashed p/w's into the cookie from a purely "good practice" point of view.

  16. #16
    SitePoint Wizard silver trophy KLB's Avatar
    Join Date
    Nov 2003
    Location
    Maine USA
    Posts
    3,781
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by platinum
    KLB: how does that make any difference. You can use the same method to grab the "sessionID" out of the cookie and use that instead.
    So what? No long term usable information would be disclosed. In addition, it would be useless especially if you add other unique information into the mix. For instance verifying the IP address and User_Agent string the browser provides to the server. In addition the session ID should have a limited shelf life. Maybe someone could spoof the User_Agent string, however, spoofing the IP address would be difficult. If any higher level of security were needed, one should be using SSL.

    I also agree that if one is using a forum or something else that allows third-parties to post something on one's website, those individuals SHOULD NOT be allowed to post HTML or at least the HTML should stripped of dangerous code. Using something like what Sitepoint uses for HTML would be a good idea. To strip all tags all together in php, use "strip_tags ($var)"
    Ken Barbalace: EnvironmentalChemistry.com (Blog, Careers)
    InternetSAR.org
    Volunteers Assist Search and Rescue via Internet
    My Firefox Theme: Classic Compact
    Based onFirefox's default theme but uses much less window space

  17. #17
    SitePoint Zealot
    Join Date
    Aug 2003
    Location
    everywhere
    Posts
    179
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    At the end of the day cookies can be spoofed by the user you shouldnt really rely on them and if really required e.g. in a forum for users not to have to login then id try and use what schooglepets suggested and always check ALL user input.
    Webmobo - Open Source News Scripts
    Portfolio / Blog

  18. #18
    SitePoint Wizard silver trophy KLB's Avatar
    Join Date
    Nov 2003
    Location
    Maine USA
    Posts
    3,781
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gsoft
    always check ALL user input.
    This goes without saying
    Ken Barbalace: EnvironmentalChemistry.com (Blog, Careers)
    InternetSAR.org
    Volunteers Assist Search and Rescue via Internet
    My Firefox Theme: Classic Compact
    Based onFirefox's default theme but uses much less window space

  19. #19
    + platinum's Avatar
    Join Date
    Jun 2001
    Location
    Adelaide, Australia
    Posts
    6,441
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by KLB
    So what? No long term usable information would be disclosed. In addition, it would be useless especially if you add other unique information into the mix. For instance verifying the IP address and User_Agent string the browser provides to the server. In addition the session ID should have a limited shelf life. Maybe someone could spoof the User_Agent string, however, spoofing the IP address would be difficult. If any higher level of security were needed, one should be using SSL.
    I know what you're saying, the only way to stop it would be to match up the requesting IP, however there is still a large number of people who use dialup, or DSL without a static IP. Not to mention AOL users. So the cookie would be pretty much useless to the person trying to have their "details remembered". It would also create problems for people wishing to stay logged in at more than one location (ie, if they swap between work and home computers).

    I could simply create a fake cookie on my machine, dump in the unique "sessionid" and away we go, same could be done with the username/password combo. So really IMO, it may create more difficulties.

    Basically, as you and other posters have said, never trust anything coming from the outside user, treat all input as mallicious attempts.

  20. #20
    SitePoint Wizard silver trophy KLB's Avatar
    Join Date
    Nov 2003
    Location
    Maine USA
    Posts
    3,781
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by platinum
    I know what you're saying, the only way to stop it would be to match up the requesting IP, however there is still a large number of people who use dialup, or DSL without a static IP. Not to mention AOL users.
    You are correct if you want to allow people to stay logged in over an extended period of time, you couldn't validate against IP. If, however, security is such a concern that you need to prevent spoofing of cookies, then you shouldn't be allowing persistent cookies.

    Quote Originally Posted by platinum
    I could simply create a fake cookie on my machine, dump in the unique "sessionid" and away we go, same could be done with the username/password combo. So really IMO, it may create more difficulties.
    The way I handle this is prevent accounts from being hijacked is by only implementing changes to key authentication information after it has been validated via a special URL sent to the original email address.

    Again, if security is a significant concern, then one should be using SSL and should not use persistent cookies.

    Quote Originally Posted by platinum
    Basically, as you and other posters have said, never trust anything coming from the outside user, treat all input as mallicious attempts.
    Basically there are three possible spots a cookie or any user information could be stolen:
    1. From within website: This is addressed by preventing the posting of malicious code and securing the server.
    2. From the user's computer: This is addressed by the user using a properly patched system, not allowing persistent cookies (but this denies the ability to stay logged in) and automatically expiring out the session id after a set idle time.
    3. Man-in-the-middle: This can only be protected against by using SSL. Whether or not to protect against this risk depends upon the sensitivity of data maintained in the user's account.


    In all cases above, limiting the sensitivity of data stored in the user account limits the risk. By not allowing account authentication information or account email address to be changed without a validation email being sent to the original email address, one can prevent the account from being hijacked. In addition user passwords should be stored in a non-reversible hash (e.g. MD5) and should never be displayed in plain text to the user.

    With the proper safeguards in place, and their limitations understood and respected, cookies are a perfectly acceptable means of maintaining session state and user authentication.
    Ken Barbalace: EnvironmentalChemistry.com (Blog, Careers)
    InternetSAR.org
    Volunteers Assist Search and Rescue via Internet
    My Firefox Theme: Classic Compact
    Based onFirefox's default theme but uses much less window space

  21. #21
    <?php echo"GiroPets"; ?> giropets's Avatar
    Join Date
    Jul 2003
    Location
    United States
    Posts
    242
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by KLB
    In addition user passwords should be stored in a non-reversible hash (e.g. MD5) and should never be displayed in plain text to the user.
    My website uses MD5 encryption on authentication with it's own secret key, and checks every time you load a page to see if the username and the encrypted password in the cookie match the one in the database.

    So how come he says he has account information and he can hijack accounts with it ? Maybe he's lying ? Maybe he's trying to scare me ?

  22. #22
    <?php echo"GiroPets"; ?> giropets's Avatar
    Join Date
    Jul 2003
    Location
    United States
    Posts
    242
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ignore the post above, I figured out how he's hijacking accounts. He has a JavaScript code on my site (I disabled it) that checks the cookie that's set (including username and encrypted password), and redirects to a page that eMails him. In the eMail is the cookie info from my computer. He edits the cookie on his computer and pastes what is on mine into his. He saves the file, clicks onto my site, and he's in.

  23. #23
    SitePoint Wizard silver trophy KLB's Avatar
    Join Date
    Nov 2003
    Location
    Maine USA
    Posts
    3,781
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by giropets
    I figured out how he's hijacking accounts. He has a JavaScript code on my site (I disabled it) that checks the cookie that's set (including username and encrypted password), and redirects to a page that eMails him. In the eMail is the cookie info from my computer. He edits the cookie on his computer and pastes what is on mine into his. He saves the file, clicks onto my site, and he's in.
    Thus as the user was pointing out and we have been pointing out you need strip out all HTML and JavaScript from anything your users upload. I've seen many attempted functions that are only supposed to strip out scripting and allow "safe" HTML, however, everyone I have seen has had some major weakness.

    You had best thank this user for bringing the problem to your attention rather than allowing this flaw to remain on your site.
    Ken Barbalace: EnvironmentalChemistry.com (Blog, Careers)
    InternetSAR.org
    Volunteers Assist Search and Rescue via Internet
    My Firefox Theme: Classic Compact
    Based onFirefox's default theme but uses much less window space


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
  •