#31
  1. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41

    Re: why not use sessions


    Originally posted by Messner
    [B[PHP]<?php

    session_start();

    // Is the session variable set ?

    if (!isset($HTTP_SESSION_VARS['UserStatus'])) {
    header ("Location: LoginU.php");
    exit;

    }
    [/B]
    That particular tip about validating the login everytime mostly applied to user sessions that weren't based on PHP4's session functions. I am not familiar with session backdoors and security hazards but I do know that if you were to reference $HTTP_SESSION_VARS[] before calling session_start(); then it could be set to whatever the user wanted.

    yourscript.php?HTTP_SESSION_VARS[UserStatus]=true


    Edit: The above will not work.. setting logged in status as a session variable is secure as far as I know.
  2. #32
  3. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41
    Just wanted to bring this back up since I am seeing a lot of new people coming in and asking about writing scripts that go against some of the basic security rules.. I think we need to make sure all PHP programmers are aware of these simple yet deadly mistakes... New programs containing these simple security holes are being released every day....
  4. #33
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Posts
    35
    Rep Power
    15
    yep!!!
    yesterday a friend of mine asked how he could do some login stuff (simply including another file if they were a valid user). i pointed out that someone could just enter that filename, and he seemed suprised that he had made somthing so insecure!

    perhaps you ought to rewrite your origional message and some of the replies as an article on secure scripting in php (and other languages).
  6. #34
  7. No Profile Picture
    Newbie forever
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2001
    Location
    UK
    Posts
    20
    Rep Power
    0
    ouch, thankyou all for your posts i have found them extremely eye-opening, especially;

    include $page.php

    which i have used on many of my earlier projects!

    is anyone prepared to discuss the

    "admin'--" thing in detail ?

    i understand the effect, but dont fully understand an effective way of stopping it,

    thanx for reading,

    jonny

    15/male/uk
  8. #35
  9. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41
    Originally posted by pezzer

    perhaps you ought to rewrite your origional message and some of the replies as an article on secure scripting in php (and other languages).
    That would be a good idea, I wonder if I could actually get ahold of any of the people at devshed. I've emailed them before about writing articles and received no reply.
  10. #36
  11. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Location
    St. George, Utah
    Posts
    63
    Rep Power
    37
    Sorry, sometimes some e-mails slip through when you are as busy as we are.
    Lucas Marshall
  12. #37
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Posts
    35
    Rep Power
    15
    In reply to Jonny's question:

    Incase anyone else hadn't got the idea, i'll explain the problem again using another example:

    say you have a form that sends a username and password:
    Code:
    <input type="text" name="username">
    <input type="password" name="password">
    and say that your target php script works somthing like:
    PHP Code:
    $query="select from users where username='$username' and password='$password'"
    Well if you entered bob as the username, and 123 as the password, the resultant value of $query would be:
    Code:
    select from users where username='bob' and password='123'
    now, what could happen is someone enters anything as the password, and the username as:
    Code:
    bob' --
    so that the value of query becomes:
    Code:
    select from users where username='bob' -- ' and password='123'
    this is interpreted as:
    Code:
    select from users where username='bob'
    as the rest is treated as a comment.
    To solve this problem, simply change the php code to:
    PHP Code:
    $username2=addslashes($username);
    $password2=addslashes($password);
    $query="select from users where username='$username2' and password='$password2'"
    thus if someone entered the 'bad' username, it would make a query string:
    Code:
    select from users where username='bob\\' -- ' and password='123'
    the slash after bob is a way of escaping the next character, ie it tells the database that the ' after it is part of the text string, and not the end of it, so the -- is treated as part of the username it is looking for, ie: bob' --
    As this entry doesnt exist it wont find anything!
    Note that you only need to worry about this if magic_quotes_gpc isnt enabled (which it seems to be on about 50% of servers). if it is enabled then php will do it for you!

    Hope this helps!
  14. #38
  15. No Profile Picture
    Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2001
    Posts
    2
    Rep Power
    0
    Hi Jeff,

    That was a superb post and I think it's something that everyone should definitely read. I've actually saved the whole page to my HDD so I can refer to it in the future.

    I think it's very difficult for newbies to understand just how wide open some sites because of silly mistakes, purely because they are still trying to grasp the concepts of server-side scripting.

    When I first started with ASP and I found out about using the query string, I used it for near enough everything I could as it was just so convenient. I've totally changed that ever since I built my first security features into my sites and now most things are either hidden in variables that don't need to access the query string, or within encrypted cookies and by using session variables.

    Some web site exploits are so unbelievably lame that a 5 year old could get in without any trouble so for those of you who don't think it is that easy, here's an example.

    In IIS 3.0, there was a very simple exploit which allowed an attacker to view your ENTIRE source code! How? Too simple to comprehend. Say there was a page on an IIS 3 server called index.php. An attacker could simply type in index%2Ephp and view the ENTIRE source!!! %2E is the hexadecimal value for a full stop.

    I hope that demonstrates just how easy some exploits are. That one should be obsolete now, but you never know. That proves another point also. As secure as your scripts are, if the server you are serving them on isn't, it can all be completely fruitless.

    All servers should have the latest patches and hotfixes installed on them and you should take the time to secure your scripts in ways like Jeff has suggested. Remember, simplicity isn't necessarily secure.

    Great post Jeff

    hellz.
  16. #39
  17. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2001
    Posts
    7
    Rep Power
    0

    Re: Security Notes (Everyone should read)


    Newb question... brace yourselves

    script.php?input=;passthru("cat /etc/paswd");
    What does "cat" do in that case?
  18. #40
  19. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2000
    Location
    Minneapolis, MN
    Posts
    8
    Rep Power
    0

    included.php is WORSE than included.inc


    6. IF YOU DON'T WANT PEOPLE TO SEE IT, GIVE IT A .PHP EXNTESION. It became common for

    After hearing Rasmus rant about this at a talk last week, I need to chime in with his advice on this. He basically admitted to possibly having started the convention of included.inc files. His statement, however, was that most folks didn't realize that his Apache conf files had the following directive in them.

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

    That basically stops everything but his script from being able to access his *.inc files.

    He then commented that most folks when they realize that the *.inc files can be sent in the clear as ASCII text, they switch them to *.php files. This doesn't fix the problem. If someone knows your API, they can still use the functions in your included file.

    His rule is that if you're going to use included files, they should be outside the docroot or restricted with a Deny from all directive to keep them safe.

    Sorry if I didn't make his reasoning clear, but he was pretty adamant on this point.
  20. #41
  21. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41
    how exactly is someone going to include your include.php file if they don't have their script running on the same server?
  22. #42
  23. No Profile Picture
    wuz here
    Devshed Novice (500 - 999 posts)

    Join Date
    May 2001
    Location
    FL
    Posts
    648
    Rep Power
    14
    Hey JeffCT, I read through your list of security possibilities and are good for the new ones at PHP, but I think it was mistake posting it in a forum. If you may be thinking why, well, topics that are posted in one week are gone the next. I haven't check devshed articles on PHP security but I would encourage you to post your thoughts in an article and submit it to devshed, so it has a longer duration of being recognized.
    z-lite was here
  24. #43
  25. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2000
    Location
    Minneapolis, MN
    Posts
    8
    Rep Power
    0

    Using API in PHP files


    They don't need to be able to include a *.php file to exploit the API. All they'd need to do is call the file directly and pass appropriate variables into it. Rasmus' main point was that *.inc files may be displayed, but *.inc.php files are parsed. Often, running an included set of functions outside the expected scope can result in unexpected consequences.
  26. #44
  27. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41
    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?"
  28. #45
  29. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41
    .

IMN logo majestic logo threadwatch logo seochat tools logo