1. Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    Netherlands
    Posts
    14
    Rep Power
    0
    You should also be carefull when uploading files to a directory: allways check the extention, or make sure the directory is locked (ie: not open for .php script executions).
    Someone could upload myevilscript.php and do serious harm to your server.
    (I found such a whole in a site once, so i created a script to put a warning .txt message on their windows desktop. I recieved a friendly email message a few days later).

    - Bas Joosten
    http://ace.axis.nl/ace/playground/
  2. No Profile Picture
    Gödelian monster
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Jul 1999
    Location
    Central Florida, USA
    Posts
    2,307
    Rep Power
    61
    Originally posted by sjcjoosten
    You should also be carefull when uploading files to a directory: allways check the extention, or make sure the directory is locked (ie: not open for .php script executions).
    Someone could upload myevilscript.php and do serious harm to your server.
    (I found such a whole in a site once, so i created a script to put a warning .txt message on their windows desktop. I recieved a friendly email message a few days later).
    You are lucky you received a friendly email message and not an unfriendly knock on the door from your local police department. Sometimes just finding a vulnerability and notifying the owner through regular means makes you automatically a suspect . But, exploiting the vulnerability just to notify the owner puts you on dangerous legal grounds, given the modern hysteria over "hackers".
    The real n-tier system:

    FreeBSD -> PostgreSQL -> [any_language] -> Apache -> Mozilla/XUL

    Amazon wishlist -- rycamor (at) gmail.com
  3. Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    Netherlands
    Posts
    14
    Rep Power
    0
    Nah, the guy was from holland and so was I, and there was no other way for me to notify him (except for browsing thrugh his private data to find out his number, wich would NOT be appreciated).
    It turned out that I DID recieve a message from the police department caus' the guy was system admin for the police (this he told me).

    - Bas Joosten,
    http://ace.axis.nl/ace/playground/

    ---
    disclaimer: I am not suggesting in any way that hacking or whatsoever is legal in the Netherlands or in any other country, nor am I advertising you to hack.
  4. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Posts
    13
    Rep Power
    0
    Here's a thought for those concerned about .inc.php files being executed directly. If the file began with something like
    PHP Code:
    if (eregi(".inc.php"$_SERVER['PHP_SELF'])) {
        die (
    "You can't access this file directly...");

    ...wouldn't that prevent direct access?

    Adapted from something I found in PHPnuke.
  5. Gogo Google.
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2002
    Location
    Adelaide, Australia
    Posts
    226
    Rep Power
    12
    Here's an even simpler means:

    PHP Code:
    if (!defined("ACCESS"))
    {
        die (
    "Not likely.");

    That goes at the top of each page you don't want accessed directly. So, before you include the protected page, you do the following:

    PHP Code:
    define("ACCESS",1);
    include_once(
    "myProtectedFile.inc.php"); 
    I used to use that method from PHP-Nuke as well, but I was then let on to this method, which is even quicker and simpler.
  6. No Profile Picture
    Banned
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2003
    Posts
    122
    Rep Power
    0
    This thread has been very helpful, and I have a few questions


    1) How does HTTP_*_VARS[] differ from $_GET[]/$_POST[] etc. (or are they identical)

    2) I wrote small script that required a login and password system. What I did was set a cookie to the username and to the hashed password. The cookie expires when the user either logouts, closes the window or quits the browser. On any page that requires you to be a member, I check to ensure that a username and a hashed password are valid (both must be there). Now I was thinking this has to be insecure, because what if I'm on another site and they create an identical cookie, but someone told me that cookies can only be used if they were set on that page. So I believe the only way for someone to gain access to that account is to copy the cookie file (which would require access to that users computer).


    The other thing is, even if the above method is secure, (which I know its not 100% secure), if someone gains access to your local computer, well then even the securest of methods (aside from always asking for a password) won't work.

    Anyways, if I'm wrong please let me know
  7. Mobbing Gangster
    Devshed Demi-God (4500 - 4999 posts)

    Join Date
    Sep 2001
    Location
    "Best City" 2002 and 2003- Melbourne, Australia
    Posts
    4,912
    Rep Power
    32
    >>1) How does HTTP_*_VARS[] differ from $_GET[]/$_POST[] etc. (or are they identical)
    $_POST et al are superglobals, which means you don't have to do global $_POST in your functions (as you do with $HTTP_*_VARS. $HTTP_*_VARS are older version which means your code will be more backwards compatible ($_* was introduced in 4.1)

    re 2:
    nothing is 100% secure and cookies have their problems. As a rule of thumb - you can't win if intruder has local access, so yes cookies could be copied/spoofed. And yes cookies can only be used on the same domain (/path) what they were set for (well... not counting browser security problems some time ago that is)
    And you know I mean that.
  8. No Profile Picture
    i'm nothing
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    70
    Rep Power
    11

    Talking


    For me, this post was also extremely useful. Thank you for sharing this with us. I also have the same question, because i did not understand your answer.


    How does HTTP_*_VARS[] differ from $_GET[]/$_POST[]?
  9. No Profile Picture
    Banned
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2003
    Posts
    122
    Rep Power
    0
    Originally posted by hockeyrocksca
    For me, this post was also extremely useful. Thank you for sharing this with us. I also have the same question, because i did not understand your answer.


    How does HTTP_*_VARS[] differ from $_GET[]/$_POST[]?
    I think he's saying that if you use the older HTTP*VARS you still need to global the variable inside the []. Using those though allowed your program to run on systems without GLOBALS ON. Today, you can just use the POST/GET method and you don't need to global the variable in the []
  10. /(bb|[^b]{2})/

    Join Date
    Nov 2001
    Location
    Somewhere in the great unknown
    Posts
    5,163
    Rep Power
    792
    Actually, this is a matter of scope.
    The older HTTP_*_VARS variables are not in the same scope as $_POST/GET/etc...

    i.e.
    To access a HTTP_*_VARS inside of a function you would have to global it.
    PHP Code:
    function foo() {
        global 
    $HTTP_POST_VARS;

        echo 
    $HTTP_POST_VARS['bar'];

    Where as the superglobals are like defined constants where they are available everywhere in your program reguardless of what scope your in.
    PHP Code:
    function foo() {
        echo 
    $_POST['bar'];

  11. No Profile Picture
    i'm nothing
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    70
    Rep Power
    11

    Thumbs up woohoo. i understand.


    <b>Thanks a lot. I understand now.</b>
  12. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    Ontario
    Posts
    24
    Rep Power
    0
    This is an awsome post, i really appreciate all the help and advice you guys have given, i am a newbie, and messages like this make me aware of issues that i had no clue about. Thanx
  13. Moderator Emeritus
    Devshed Supreme Being (6500+ posts)

    Join Date
    Feb 2002
    Location
    Austin, TX
    Posts
    7,186
    Rep Power
    2265
    Another group of articles concerning PHP Security, this time from the source. Some valid points are raised in these articles not already covered by this post (amazingly enough).

    PHP.net - Security
    DrGroove, Devshed Moderator | New to Devshed? Read the User Guide | Connect with me on LinkedIn
  14. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2003
    Location
    Berlin/Germany
    Posts
    4
    Rep Power
    0
    that's a whole bunch of extremely useful information... i'm a trainee in the second year right now and after reading this thread i guess i've gone at least 2 steps forward.

    thanks everyone!
  15. No Profile Picture
    <? unset($sanity) ?>
    Devshed Novice (500 - 999 posts)

    Join Date
    Jul 2003
    Posts
    613
    Rep Power
    11
    Reading over that PHP.net article.. It says,
    Another way to stop a user from looking at or executing the files read by include() or require() is to use a different file extension for them (i.e. *.inc) and add the following to your apache configuration:

    <Files ~ "\.inc$">
    Order allow,deny
    Deny from all
    Satisfy All
    </Files>

    They won't execute unless used in a include() or require() since they don't have the *.php extension, and the server won't serve them up as text/plain with the directive above.
    Is there another work around for the people who are being hosted by someone else, and don't have access to the apache configuration?
    "I haven't failed, I've found 10,000 ways that won't work."
    - Thomas Edison

    -=Rick=-

    Chat Refinance Loans

IMN logo majestic logo threadwatch logo seochat tools logo