1. Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Dec 2004
    Location
    Toronto, Ontario
    Posts
    511
    Rep Power
    33
    When error occurs on my page, I redirect to errorpage.php and assign error mesage to GET variable $err, which is then displayed on that page, is there any security threat if I do not check content of that GET variable before I display it on the errorpage?

    example:
    page.php
    PHP Code:
    if(!fopen('some.txt') {
    header("Location: errorpage.php?err=File could not be opened");

    errorpage.php
    PHP Code:
    echo $_GET['err']; 
    I enjoy my daily dose of sql injection
  2. Permanently Banned
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2006
    Location
    In a whale
    Posts
    4,147
    Rep Power
    0
    Looks vunrible to XSS to me....
  3. Rocking my php-ness
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Dec 2004
    Location
    Boston, MA
    Posts
    1,968
    Rep Power
    152
    Originally Posted by spilo101
    When error occurs on my page, I redirect to errorpage.php and assign error mesage to GET variable $err, which is then displayed on that page, is there any security threat if I do not check content of that GET variable before I display it on the errorpage?

    example:
    page.php
    PHP Code:
    if(!fopen('some.txt') {
    header("Location: errorpage.php?err=File could not be opened");

    errorpage.php
    PHP Code:
    echo $_GET['err']; 
    Do something more like

    PHP Code:
    if(isset($_GET['err'])) echo htmlentities($_GET['err'], ENT_QUOTES); 
    My new WebComic http://www.jjsunshines.com/
    The Geek Shall Inherit the Earth

    It is NOT ok to IM me with questions unless I told you it was ok via PM
  4. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2004
    Posts
    8
    Rep Power
    0
    Good guide. Some of it is common sense, but most of it can be easily overlooked. Once again, great post.
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2005
    Location
    Boston, MA
    Posts
    398
    Rep Power
    17
    Originally Posted by JeffCT
    6. If you don't want the file contents to be seen, give the file a .php extension
    It was common prattice for awhile to name include files or library files with a .inc extension. Here's the problem: if a malicious user simply enters the .inc file into his browser, it will be displayed as plain text, not parsed as PHP. Even if the browser did not like the file type, an option to download it would most likely be given. Imagine if this file had your database login and password, or even more sensitive information.

    This goes for any other extension other than .php (and a few others), so even a .conf or a .cfg file would not be safe.

    The solution is to put a .php extension on the end of it. Since your include files or config files usually just define variables and/or functions and not really output anything, if your user were to load this, for example, into their browser:

    http://yoursite.com/lib.inc.php

    They would most likely be shown nothing at all, unless of your lib.inc.php outputs something. Either way, the file would be parsed as PHP instead of just displaying your code.

    There are also some reports of people adding Apache directives that will deny access to .inc files, however I do not recommend this, because of the lack of portability. If you rely on .inc files and that Apache directive to deny access to them and one day you move your scripts to another server and forget to place the Apache directive in, you are wide open.
    Actually, an even better strategy is to simply put your include files outside of the web root, and then include them from there. That way there is no way that they can be accessed as web pages. This is more secure than simply changing the extension to PHP, because if PHP support is somehow disabled in Apache (e.g. if you reinstall it and forget to add it), then until you fix that, the source will be sent in plaintext. Not A Good Thing.
  6. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2005
    Location
    Boston, MA
    Posts
    398
    Rep Power
    17
    Originally Posted by JeffCT
    jwynia:

    That makes sense now, I see your point. But I thought you were referring to an exploit I was unaware of. That goes back to my original points in the first post. Include files are no more insecure than your regular scripts then.

    The fact that you Could accidentally write the include file in such a way that it could be exploited doesn't mean they are "bad" or should be avoided. In that same sense everything PHP would be bad.

    My goal with this post is so that you Don't write your script like that.

    I should hope someone's include file doesn't look like this:

    PHP Code:
    eval("$somethingstupid");

    function 
    blahblah()
    {
    }

    function 
    blahblah2 ()
    {

    }

    etc

    But I don't agree with what Rasmus said on the topic (from what I understand). To put your include files out of the docroot to be safe. I say learn to write them correctly and you won't need to. If you follow his advice you might as well put your whole site out of the docroot to be safe :/ What's the difference?

    When you write your script/include file, ask yourself "How can I make this script secure?" not "How can I hide this script?"

    This is a good point. In fact, it could be argued that your code will ultimately be safest if everybody could read it and critique it - after all, this sort of "open source" approach is what many believe makes Linux more secure than Windows, Firefox more secure than IE, etc.

    However, the drawback is that handling those rigors, especially early on, will require a process of making a number of mistakes and following-up on them that many businesses may not be able to afford. And it is undeniable that it is harder to find security holes in a program when you don't know its variable names, etc.

    In those cases, it may still be worthwhile to keep source hidden and to take whatever steps you can to preserve the secrecy of that source. Think of it as a Defense in Depth strategy, to quote Chris Shiflett's "Essential PHP Security," which incidentally is a great book on the topic that those interested in PHP security should read.

    In sum, it's an issue of short-term versus long-term benefits. Many people and businesses can't afford the short-term costs of open source when developing their own software.
  7. Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    May 2006
    Location
    Kent, England
    Posts
    857
    Rep Power
    575
    I'm not sure if this has already been posted here (I haven't read all
    the posts as thoroughly as I should) so I am going to add my own,
    often overlooked security tip.

    If you use hidden fields on a form, validate them too!

    There is nothing to stop me from browsing your site, saving the
    page as HTML and making some edits. I have seen some shopping
    carts where it was possible to order 1000 bottles of wine for 1
    using that technique.

    I was tempted but did the right thing
    It turns out there are stupid questions. And I don't know the answers!
    Over 50? Visit the Saga Zone - Social Networking for the Over 50's





    For every action there is an equal and opposite - government program
  8. Permanently Banned
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2006
    Location
    In a whale
    Posts
    4,147
    Rep Power
    0
    Originally Posted by ElijaTheGold
    I'm not sure if this has already been posted here (I haven't read all
    the posts as thoroughly as I should) so I am going to add my own,
    often overlooked security tip.

    If you use hidden fields on a form, validate them too!

    There is nothing to stop me from browsing your site, saving the
    page as HTML and making some edits. I have seen some shopping
    carts where it was possible to order 1000 bottles of wine for 1
    using that technique.

    I was tempted but did the right thing
    Hehe, that reminds of this site, if you put in -1 they just charge you for shipping and not for the one item. So I did the right thing, after I got some free stuff

    Which is why you should check if the number is less than 0. is_numeric() sees -1 as a number, just a negative.
    Last edited by BlackNine; January 2nd, 2007 at 06:02 AM.
  9. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2004
    Location
    Nasik and Mumbai
    Posts
    371
    Rep Power
    11
    Originally Posted by jdk
    hi,

    check this.


    i found it here.
    pretty interesting !!!
    jd
    This wont work in PHP 5.X.X version....as php engine internally converts " to \" and ' to \'
    ----------------------------------
    http://bytepower.50webs.com
    ----------------------------------
  10. Banned (not really)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 1999
    Location
    Brussels, Belgium
    Posts
    14,650
    Rep Power
    4493
    Originally Posted by bytepower
    This wont work in PHP 5.X.X version....as php engine internally converts " to \" and ' to \'
    Only if magic_quotes_gpc is enabled, which it is by default but may not always be. For performance reasons you should turn it off and handle your requests properly.

    ---John Holmes...
    -- Cigars, whiskey and wild, wild women. --
  11. Web Developer/Musician
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Nov 2004
    Location
    Tennessee Mountains
    Posts
    2,423
    Rep Power
    1032
    Actually, an even better strategy is to simply put your include files outside of the web root
    A good suggestion but unfortunately, not always possible. My includes are always php, unless they just contain html. If they have anything that executes in them I set a constant in the page that includes that file which the included file checks. If it's not there or an incorrect value than nothing gets executed.
    Coder Central Tutorials, news and information for the programming community at large.
  12. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2006
    Location
    UK
    Posts
    460
    Rep Power
    68
    Originally Posted by Hammer65
    My includes are always php
    As are mine, yet I still place the includes folder parent to webroot. No problems executing anything.
  13. Web Developer/Musician
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Nov 2004
    Location
    Tennessee Mountains
    Posts
    2,423
    Rep Power
    1032
    It should be noted however that, some web hosts allow limited account access to areas off the web root.
    Coder Central Tutorials, news and information for the programming community at large.
  14. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2007
    Posts
    17
    Rep Power
    0
    GET & POST reverse magic quotes:
    PHP Code:
    if (get_magic_quotes_gpc()) {
        if (isset(
    $_GET)) $_GET array_map('stripslashes'$_GET);
        if (isset(
    $_POST)) $_POST array_map('stripslashes'$_POST);

  15. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    london
    Posts
    63
    Rep Power
    12
    To protect your includes from being accessed via the browser why not just put them in a .htaccess protected directory. that way the scripts can still include them and the browser can't see them.

IMN logo majestic logo threadwatch logo seochat tools logo