Signed tokens vs. session-based tokens - Page 2
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 40

Thread: Signed tokens vs. session-based tokens

  1. #16
    Senior Member
    Join Date
    Mar 2009
    Posts
    1,153
    Quote Originally Posted by Derokorian View Post
    This part seriously concerns me. You're given them the token and the resulting hash, given enough of these combinations a hacker can guess the secret, since its always the same I believe. I would use a separate key, and encrypt that entire string with openssl_encrypt, then when you check you can use this key to decrypt to the string above. I think this would be more secure.

    PHP Code:
     $signed $token.'-'.$hash
     
    $signed openssl_encrypt($signed'AES-256-CBC'ENCRYPT_PASS);

        public static function 
    verify(string $signedToken
        { 
            
    $signedToken openssl_decrypt($signedToken'AES-256-CBC'ENCRYPT_PASS);
            
    $parts explode('-'$signedToken); 
    I tried to avoid using something that wasn't part of the SPL. My original implementation used openssl_random_pseudo_bytes(), but then I had to check to make sure the extension was enabled. That is why I switched to using random_bytes() because it's included by default in PHP 7, and there are no checks or exceptions being thrown in the generation of a token.

    Is there some kind of fallback in the SPL that can be used if the OpenSSl extension is not loaded?

    Also in my very cursory testing with openssl_encrypt, you must provide an initialization vector. When I tried to run your code I got a PHP warning (or a notice - I forget which). And from what I can tell you must provide the same initialization vector to decrypt it, which kinda defeats it since it would have to be generated every time and then passed every time, but to pass it every time means it has to be available client-side.

    In any case, I'm not worried about someone "guessing" the secret. Granted, it can be as complex as the developer would like it to be, but in my case it's a string of 100 random characters, whose character set includes every character on the standard keyboard minus the space, single quote, double quote, and back slash. No supercomputer on the planet could crack that in a trillion years.

    I like the idea, however, so if there is a proven fallback in the SPL I see no reason not to implement it.
    Declare variables, not war.

  2. #17
    Senior Member
    Join Date
    Mar 2009
    Posts
    1,153
    Quote Originally Posted by sneakyimp View Post
    The first thing that occurs to me is that TOKEN_SECRET should probably not be defined as a constant. To define it as a constant suggests that you set one value which does not change. It also smells like Service Locator/Factory patterns to me. I think some kind of dependency injection approach would be better. E.g., pass in $token_secret as a var to a constructor? Or if you really want static methods, assign some value to Token::$token_secret? It would make your class more flexible if a user could choose their own method of defining $token_secret rather than having to define a constant somewhere? E.g., reading it from a config file or a cookie or something.

    Philosophically, and from a security standpoint, the idea that there is one TOKEN_SECRET defined somewhere in a constants file doesn't sound all that secure to me. I don't really know how you are defining TOKEN_SECRET but my guess is that it is consistent from page access to page access. My security muscles have atrophied a bit, but have you considered applying Kerckhoff's principle? I.e., if someone were to read your source, would they gain access to TOKEN_SECRET?

    Also, if you allow any random visitor to see a possibly unlimited number of token-hash combinations, you are badly exposing your system to a known-plaintext attack.

    Perhaps you could provide some very simple usage examples for discussion?
    I'll start with a simple usage example:

    1. Page loads and a token is generated using Token::generate().
    2. It's printed in a hidden input field (or something similar).
    3. An AJAX call is made. The value in the hidden input field is passed as part of the request.
    4. In the PHP file on the server-side, the token is verified using Token::verify($thePostedToken).
    5. If they don't match, throw an exception or error out or do whatever you want.
    6. If they do match, then proceed.

    So the intent is to keep it constant - hence the use of the constant. The developer can define it anyway they want to.

    Kerckhoff's Principle honestly doesn't make much sense to me. It sounds great but to me isn't grounded in reality for a very simple reason: if an attacker has access to my source code then it's game over. There's no security in the world that can handle that. Furthermore if that were to ever happen, the last thing I care about is my token. I don't give a rodent's rear at that point - there are far larger fish to fry. You know what else I have stored away in my source code? Database credentials, PHPMailer credentials, etc. I have bigger problems than a token.

    Quote Originally Posted by sneakyimp
    I would say that any value that depends on the current user's id should not be defined in a constant.
    The token secret has nothing to do with the user's ID.

    Quote Originally Posted by sneakyimp
    I'd also point out that password hashing best practices dictate the use of a salt that is different for each and every password.
    This has nothing to do with passwords so I am not sure why it was mentioned. Also, each hash will be different anyway since the token will be different.

    Quote Originally Posted by sneakyimp
    How is TOKEN_SECRET generated?
    However the developer would like. For me, I used KeePass and generated a random 100 character string.

    Quote Originally Posted by sneakyimp
    If it's just a fixed value in a constants file and he's using that class above, then any valid token-hash will be valid forever (or until he changes his TOKEN_SECRET in his source code) and there's nothing to stop Mallory from getting one valid token-hash value and using it to forge requests for Alice, Bob, or whoever.
    In my specific example, yes, but as I mentioned in my original post you could harden it by including an expiration during hashing or a user's ID, etc. That is left up to the developer.
    Declare variables, not war.

  3. #18
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,793
    Quote Originally Posted by Bonesnap View Post
    I'll start with a simple usage example:

    1. Page loads and a token is generated using Token::generate().
    2. It's printed in a hidden input field (or something similar).
    3. An AJAX call is made. The value in the hidden input field is passed as part of the request.
    4. In the PHP file on the server-side, the token is verified using Token::verify($thePostedToken).
    5. If they don't match, throw an exception or error out or do whatever you want.
    6. If they do match, then proceed.

    So the intent is to keep it constant - hence the use of the constant. The developer can define it anyway they want to.
    Assuming TOKEN_SECRET is constant and your token class is defined as above, then doesn't that mean that any output of Token::generate() will never expire and any token generated is valid for any visitor? If so, this doesn't protect against anything at all because an attacker can simply visit your site, view the form, take some valid token from the hidden input field, and then concoct a malicious form hosted on any domain under the sun, and if they trick one of your users into submitting it, then your site will accept that token and the attack will succeed. In my understanding, the way you defend against CSRF is to construct tokens with a short lifespan that are valid *only for one particular user.* If any valid token is also valid for any visitor, then you are not protected at all against CSRF. You may want to review owasp CSRF prevention cheatsheet.


    Quote Originally Posted by Bonesnap View Post
    Kerckhoff's Principle honestly doesn't make much sense to me. It sounds great but to me isn't grounded in reality for a very simple reason: if an attacker has access to my source code then it's game over.
    KP is a principle to guide security review. It's complicated but basically boils down to suggestions like: good encryption systems are still good even if the entire mechanism of encryption is known. Keep your keys secure and ideally separate from your source (e.g., in an environment variable somewhere). In practice, PHP applications are totally compromised if the source code gets compromised, but alls is not lost if attackers only manage some SQL injection. Ideally an SQL security failure wouldn't compromise the security of your data. In applying it to your token-generating scheme, the lesson I take away is that your system generates ALL of its tokens using one single constant. I suggest you improve your system by having it generate tokens that also depend on a user-specific (or session-specific) value.

    Quote Originally Posted by Bonesnap View Post
    There's no security in the world that can handle that. Furthermore if that were to ever happen, the last thing I care about is my token. I don't give a rodent's rear at that point
    If your PHP source were compromised, but all your sensitive credentials injected as envrionment variables (e.g., via an apache conf file) then your system would not necessarily be compromised.

    Quote Originally Posted by Bonesnap View Post
    Database credentials, PHPMailer credentials, etc. I have bigger problems than a token.
    Yes this is how most PHP apps work. I'm not trying to be pedantic. I do mean to suggest that I think your CSRF protection is perhaps not providing the protection you think it is.

    Quote Originally Posted by Bonesnap View Post
    The token secret has nothing to do with the user's ID.
    I think the token should have something that makes it specific to each visitor. If the visitor is not yet authenticated, you can still maintain a session using a session ID and store something unique for each user so that every user who visits will receive tokens that are only valid for them and no one else. This could be a randomly generated session ID stored in a cookie, for instance.

    Quote Originally Posted by Bonesnap View Post
    This has nothing to do with passwords so I am not sure why it was mentioned. Also, each hash will be different anyway since the token will be different.
    The reason I mention passwords is because MD5 hashing and SHA1 hashing are being deprecated, with more likely to follow -- there's a cautionary tale here. The best-practice of using a salt when hashing passwords and the fairly recent introduction of password_hash is a to improve security. Not only is each password different, but we generate a random salt to hash that password to further insulate our hashed values against attacks. Not only does each password hash to a different value, but the same password, used twice, will never have the same hash thanks to the salt.

    Quote Originally Posted by Bonesnap View Post
    However the developer would like. For me, I used KeePass and generated a random 100 character string.
    Depending on the charset used, that sounds like 800 bits or so, which is pretty hefty. The risk, as I've pointed out lies primarily in the fact that a token that works for me also works for you. If I'm an attacker, I view your form, I extract a valid token, and I construct a malicious form you using the token and the token will still be accepted. I just have to trick you into clicking on my form. This is the essence of a CSRF attack. CSRF prevention hinges upon insuring that tokens valid for me are NOT valid for anyone else.

    Quote Originally Posted by Bonesnap View Post
    In my specific example, yes, but as I mentioned in my original post you could harden it by including an expiration during hashing or a user's ID, etc. That is left up to the developer.
    It may be impactical for any given project to invest in CSRF protection if the risk of attack is low, but you only have to do it right once. It is the expiration of a token that introduces the trouble when you have a lot of AJAX, a SPA, or multiple windows open. You can probably relax your expiration times and let your tokens last for hours without much risk. However, I think it's critically important that a token displayed in hidden input in User A's browser should not work at all for User B. You should store a secret random token in session or in a cookie -- a different one generated for each visitor -- so that User A cannot attack User B.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  4. #19
    Pedantic Curmudgeon Weedpacket's Avatar
    Join Date
    Aug 2002
    Location
    General Contact Unit "Coping Mechanism"
    Posts
    22,395
    Quote Originally Posted by sneakyimp
    In practice, PHP applications are totally compromised if the source code gets compromised, but alls is not lost if attackers only manage some SQL injection.
    Note that under Kerckhoff's principle "compromised" here means "being able to read it", not necessarily alter it (KP is why algorithms like Rijndael and Keccak (aka AES and SHA3) can be published in full and yet still be considered secure enough for government work). A potential attacker could, for example "compromise" the PHP application in this context by reading the first post in this thread; do that and work on crafting an attack that will break security, knowing in advance how the application will respond to messages that it is sent - they don't need access to the actual system to do so. KP means that knowing how the system works isn't enough to make that system vulnerable.
    Last edited by Weedpacket; 02-28-2017 at 08:14 PM.
    THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER
    FAQs! FAQs! FAQs! Most forums have them!
    Search - Debugging 101 - Collected Solutions - General Guidelines - Getting help at all

  5. #20
    Senior Member Derokorian's Avatar
    Join Date
    Apr 2011
    Location
    Denver
    Posts
    2,232
    Quote Originally Posted by sneakyimp View Post
    If your PHP source were compromised, but all your sensitive credentials injected as envrionment variables (e.g., via an apache conf file) then your system would not necessarily be compromised.
    I'll admit, this makes no sense to me. If they can get to the source, does it really matter how the credentials are stored since the source obviously has to use them? They obviously now have the knowledge to know where the credentials come from to look them up?

    Quote Originally Posted by sneakyimp View Post
    Yes this is how most PHP apps work. I'm not trying to be pedantic. I do mean to suggest that I think your CSRF protection is perhaps not providing the protection you think it is.

    I think the token should have something that makes it specific to each visitor. If the visitor is not yet authenticated, you can still maintain a session using a session ID and store something unique for each user so that every user who visits will receive tokens that are only valid for them and no one else. This could be a randomly generated session ID stored in a cookie, for instance.
    I agree, a token should only work for a specific visitor and should have an expiry time less than or equal to session expiry.

    Quote Originally Posted by sneakyimp View Post
    The reason I mention passwords is because MD5 hashing and SHA1 hashing are being deprecated, with more likely to follow -- there's a cautionary tale here. The best-practice of using a salt when hashing passwords and the fairly recent introduction of password_hash is a to improve security. Not only is each password different, but we generate a random salt to hash that password to further insulate our hashed values against attacks. Not only does each password hash to a different value, but the same password, used twice, will never have the same hash thanks to the salt.
    Should say: will LIKELY never have the same hash, thanks to the generated salt. There is always a possibility of collision, that possibility increases with userbase, and decreases with salt length (which IIRC is 17 in password_hash).

    Quote Originally Posted by sneakyimp View Post
    It may be impactical for any given project to invest in CSRF protection if the risk of attack is low, but you only have to do it right once. It is the expiration of a token that introduces the trouble when you have a lot of AJAX, a SPA, or multiple windows open. You can probably relax your expiration times and let your tokens last for hours without much risk. However, I think it's critically important that a token displayed in hidden input in User A's browser should not work at all for User B. You should store a secret random token in session or in a cookie -- a different one generated for each visitor -- so that User A cannot attack User B.
    To that end, I think what you might be looking for is more along the lines of JWT if you're trying to not be session/cookie dependent.
    Sadly, nobody codes for anyone on this forum. People taste your dishes and tell you what is missing, but they don't cook for you. ~anoopmail
    I'd rather be a comma, then a full stop.
    User Authentication in PHP with MySQLi - Don't forget to mark threads resolved - MySQL(i) warning

  6. #21
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,793
    Quote Originally Posted by Derokorian View Post
    I'll admit, this makes no sense to me. If they can get to the source, does it really matter how the credentials are stored since the source obviously has to use them? They obviously now have the knowledge to know where the credentials come from to look them up?
    As weedpacket just pointed out:
    Quote Originally Posted by weedpacket
    Note that under Kerckhoff's principle "compromised" here means "being able to read it", not necessarily alter it
    If an attacker can read ALL of your PHP source, but your credentials are stored somewhere else -- e.g., in an INI file or maybe injected into ENV by an apache configuration file or a .bashrc file or something -- then a well-designed system will resist giving up sensitive information.

    Quote Originally Posted by Derokorian View Post
    I agree, a token should only work for a specific visitor and should have an expiry time less than or equal to session expiry.
    I would say that tokens being unique to a user is more important than expiry. Most exploits by hackers are only cost-effective if you can use them on a lot of people. An exploit of a single person is only worth the time & effort if that one person is really important somehow.

    Quote Originally Posted by Derokorian View Post
    Should say: will LIKELY never have the same hash, thanks to the generated salt. There is always a possibility of collision, that possibility increases with userbase, and decreases with salt length (which IIRC is 17 in password_hash).
    Yes it could happen of course, but the odds are super super long. Even if you had 10^17 users, how many will use exactly the same password? Also, a string with 17 upper and lowercase letters plus numbers presents a LOT of options for a salt. (I'm not sure exactly what salt possibilities are).

    Quote Originally Posted by Derokorian View Post
    To that end, I think what you might be looking for is more along the lines of JWT if you're trying to not be session/cookie dependent.
    I haven't had time yet to look at this in any detail. Looks interesting. I'd also point out that CodeIgniter and Laravel have built-in mechanisms to protect against CSRF. OWASP also offers some advice. Even Wikipedia has a brief section on prevention.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  7. #22
    Pedantic Curmudgeon Weedpacket's Avatar
    Join Date
    Aug 2002
    Location
    General Contact Unit "Coping Mechanism"
    Posts
    22,395
    Quote Originally Posted by sneakyimp
    Even if you had 10^17 users, how many will use exactly the same password?
    A lot. I once worked with a users table that had hashed passwords, but they weren't salted; did you know the MD5 for "password" is "5f4dcc3b5aa765d61d8327deb882cf99"? I saw a lot of that. I also saw a lot of "827ccb0eea8a706c4c34a16891f84e7b" which led me to add an Easter Egg to the registration form, so that in certain cases it would respond with "That's amazing, I've got the same combination on my luggage."

    Quote Originally Posted by sneakyimp
    (I'm not sure exactly what salt possibilities are).
    For password_hash at least it's 128 bits chosen uniformly.
    THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER
    FAQs! FAQs! FAQs! Most forums have them!
    Search - Debugging 101 - Collected Solutions - General Guidelines - Getting help at all

  8. #23
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,793
    Quote Originally Posted by Weedpacket View Post
    A lot. I once worked with a users table that had hashed passwords, but they weren't salted; did you know the MD5 for "password" is "5f4dcc3b5aa765d61d8327deb882cf99"? I saw a lot of that. I also saw a lot of "827ccb0eea8a706c4c34a16891f84e7b" which led me to add an Easter Egg to the registration form, so that in certain cases it would respond with "That's amazing, I've got the same combination on my luggage."

    For password_hash at least it's 128 bits chosen uniformly.
    If I'm doing this right, wolfram alpha tells me that 10^17 users who all choose the exact same password still have a very small chance of randomly getting an identical salt of 128 bits. 10^17 divided by 2^128 is only 2.94x10^-22. My stats muscles are quite rusty, though. I know the actual calculation is much more complicated...n choose k or something like that.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  9. #24
    Pedantic Curmudgeon Weedpacket's Avatar
    Join Date
    Aug 2002
    Location
    General Contact Unit "Coping Mechanism"
    Posts
    22,395
    Ah, well, you asked about "the same password", there; not password/salt combination.
    THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER
    FAQs! FAQs! FAQs! Most forums have them!
    Search - Debugging 101 - Collected Solutions - General Guidelines - Getting help at all

  10. #25
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,793
    Quote Originally Posted by Weedpacket View Post
    Ah, well, you asked about "the same password", there; not password/salt combination.
    Yes, you are correct. I mean to imply that the likelihood of a salt collision was remote -- but even more remote if you took into account the possibility of distinct users choosing the exact same password. That implication is perhaps not quite correct as you've pointed out. Although I think most modern web apps enforce some modicum of password complexity.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  11. #26
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    8,364
    Quote Originally Posted by Derokorian View Post
    I'll admit, this makes no sense to me. If they can get to the source, does it really matter how the credentials are stored since the source obviously has to use them? They obviously now have the knowledge to know where the credentials come from to look them up?
    Quote Originally Posted by sneakyimp View Post
    If an attacker can read ALL of your PHP source, but your credentials are stored somewhere else -- e.g., in an INI file or maybe injected into ENV by an apache configuration file or a .bashrc file or something -- then a well-designed system will resist giving up sensitive information.
    I suppose it depends on "nature of the access". If they just compromise $DOCROOT and FTP the PHP files out, or expose them in the browser and don't have access outside the webroot, then credentials stored in a file outside of $DOCROOT might allow you another layer of protection. But the end goal of most attacks is shell access or its equivalent and rooting of the entire box, and "game over" is a fairly decent description of a box that's had that done to it. I think that's Bonesnap & Derokorian's point there. If an attacker is smart enough to get a shell, or, worse yet, a root shell, you can bet they're smart enough to look for credentials in locations besides the DB class and/or the app's "config.php" file.

    Quote Originally Posted by Weedpacket View Post
    I also saw a lot of "827ccb0eea8a706c4c34a16891f84e7b" which led me to add an Easter Egg to the registration form, so that in certain cases it would respond with "That's amazing, I've got the same combination on my luggage."
    How many digits do they have on luggage down there? I'd expect something more like "e10adc3949ba59abbe56e057f20f883e"?

    Oh, and here are the passwords for a half billion accounts right here.
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

  12. #27
    Senior Member Derokorian's Avatar
    Join Date
    Apr 2011
    Location
    Denver
    Posts
    2,232
    Quote Originally Posted by dalecosp View Post
    I suppose it depends on "nature of the access". If they just compromise $DOCROOT and FTP the PHP files out, or expose them in the browser and don't have access outside the webroot, then credentials stored in a file outside of $DOCROOT might allow you another layer of protection. But the end goal of most attacks is shell access or its equivalent and rooting of the entire box, and "game over" is a fairly decent description of a box that's had that done to it. I think that's Bonesnap & Derokorian's point there. If an attacker is smart enough to get a shell, or, worse yet, a root shell, you can bet they're smart enough to look for credentials in locations besides the DB class and/or the app's "config.php" file.
    Well if they can get to FTP, they can get to ish outside of the web accessible root. None of my config, or even classes, are in web accessible root. I have a public folder, this is the only thing accessible from the web. It contains only: .htaccess, index.php, scripts/ and styles/ literally everything else is not accessible from the web. Only root (or proper sudo privs) and apache user can access the config folder with sensitive credentials. I'm curious what makes that more "unsafe" than env vars? I really need to understand this, so I can determine if changing around my entire configuration scheme is worthwhile. If you mean accessing source on git, I have no problem with that, it doesn't give you anything besides how the app works - keys are still required and only stored on the server itself.

    However, my point was, if you can get to the source on the server, what is stopping you from just reading the files the same way the source does. I mean, either you have access to the box and can just open the files, or you have access to the source on disk and can just change it to dump the data to some file. I feel like I'm missing something.
    Sadly, nobody codes for anyone on this forum. People taste your dishes and tell you what is missing, but they don't cook for you. ~anoopmail
    I'd rather be a comma, then a full stop.
    User Authentication in PHP with MySQLi - Don't forget to mark threads resolved - MySQL(i) warning

  13. #28
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,793
    Quote Originally Posted by Derokorian View Post
    Well if they can get to FTP, they can get to ish outside of the web accessible root. None of my config, or even classes, are in web accessible root. I have a public folder, this is the only thing accessible from the web. It contains only: .htaccess, index.php, scripts/ and styles/ literally everything else is not accessible from the web. Only root (or proper sudo privs) and apache user can access the config folder with sensitive credentials.
    This all sounds like very good practice. Most modern frameworks do try and keep the credentials out of the web root.

    Quote Originally Posted by Derokorian View Post
    I'm curious what makes that more "unsafe" than env vars? I really need to understand this, so I can determine if changing around my entire configuration scheme is worthwhile. If you mean accessing source on git, I have no problem with that, it doesn't give you anything besides how the app works - keys are still required and only stored on the server itself.
    Your setup is sound and I wouldn't bother changing it. In fact, I was complaining about using environment variables just recently. The reason I mentioned kerckhoff's principle and environment variables was really just as a thought exercise to discuss the merits of Bonesnap's token class. If his class relied on randomly generated tokens, it might still work effectively even if someone reads the source code. Since the point of the token class is security, it seemed reasonable if we're talking about security to touch upon how the class might be compromised.

    I hope by FTP access you mean SFTP (or more precisely SSH File Transfer Protocol) as old-fashioned FTP is not encrypted in transit. If someone is able to upload their own PHP source code to your server (or execute arbitrary PHP code as apache somehow), then injecting sensitive credentials as ENV variable provides no security advantage over storing them in a PHP file. If, on the other hand, someone were somehow able to read all of your PHP but not change anything, they probably would not be able to discover the contents of environment variables on your server.

    Quote Originally Posted by Derokorian View Post
    However, my point was, if you can get to the source on the server, what is stopping you from just reading the files the same way the source does. I mean, either you have access to the box and can just open the files, or you have access to the source on disk and can just change it to dump the data to some file. I feel like I'm missing something.
    One example that comes to mind is when an apache adjustment or upgrade breaks your PHP installation and suddenly all of your PHP source code is visible to the entire world. I.e., every PHP file is not parsed as code but rather any visitor to the site will just see the PHP source code. It's been a long time, but this has in fact happened to me. Theoretical security is one thing, but in reality things break in funny ways and sometimes your access is not complete. SQL injection vulnerabilities, for example, don't compromise any of your own system, but attackers can sometimes siphon off your entire user table. The term defense in depth comes to mind. It's a bit like designing a warplane. It's all well and good to make a plane with a gun and bombs, but the A-10 warthog has all kinds of redundancy and armor and is intentionally designed so that it degrades gracefully when damaged. The Death Star, on the other hand, suffers a catastrophic failure once you get a torpedo or two into the exhaust port -- which is as big as a womp rat.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  14. #29
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    8,364
    Quote Originally Posted by Derokorian View Post
    Well if they can get to FTP, they can get to ish outside of the web accessible root.
    That would, of course, depend on the configuration of the FTP root and the HTTPD Docroot. In some server configurations, or even per-user configuration (so depending on whose credentials are stolen(?)) the FTP access is chrooted to the server's DOCROOT, in others HOMEDIR and the HTTPD Docroot is a sub-dir of that, and I hope for goodness' sake no one has any FTP set up higher in the tree than that, but systems do have to be administered (I, for one know too many people who think that their convenience is more important that my security paranoia, and my paranoia is probably not even good enough for some of the companies out there). I must add that I had to smile a little when I read Docker's website, that they're basically just using the Linux equivalent of the FreeBSD jail that's been around since Who Knows When. I also have most of my super-secret stuff quite far away from the webroot, but in some situations I'm in some sort of "jailed" environment and not allowed that sort of access to other filesystem locations.

    (Please also, reader of this thread, note that when I say FTP I mean SFTP; if you are still using plain-text FTP in this day & age you deserve to and should have your server rooted to teach you this lesson the hard way.)
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

  15. #30
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,793
    Quote Originally Posted by dalecosp View Post
    I also have most of my super-secret stuff quite far away from the webroot, but in some situations I'm in some sort of "jailed" environment and not allowed that sort of access to other filesystem locations.
    I am fascinated by the idea of jails and have the rare occasion to use them, but recall that setting them up is a PITA.

    Quote Originally Posted by dalecosp View Post
    (Please also, reader of this thread, note that when I say FTP I mean SFTP; if you are still using plain-text FTP in this day & age you deserve to and should have your server rooted to teach you this lesson the hard way.)
    This kind of thing does indeed cause a lot of soul-searching. Having some SQL injector try and steal all your users' (poorly) hashed passwords feels like a personal violation, as does having your email script abused to send spam. Such a low feeling
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

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