#16
  1. Lurker - in your bushes
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2000
    Location
    .be
    Posts
    494
    Rep Power
    116

    Thumbs up


    I'd just like to say that I found this a usefull reminder, and I'd like to thank you for taking your time posting it. (I wouldn't know 50% of what I know today if it wasn't for this board)

    Am still totaly clueless when it comes to apache security though, but any info is always welcome
    Saintaw

    pending.
  2. #17
  3. 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
  4. #18
  5. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2001
    Location
    Slovenia
    Posts
    32
    Rep Power
    13

    Question authentification


    Why can't I use $HTTP_SESSION_VARS with my authentification ?
    PHP Code:
    session_start();
    if(
    $HTTP_SESSION_VARS['admin'] == "true")
    {
       
    // let them in
    }
    else
    {
       
    // kick them out

    If someone comes from another server (with admin variable set in his session), then his session variable isn't valid anymore on my server (I tought so, till now ). A new session is generated on my page (with new vars) and he cann't break in.

    I am new in this stuff, plizz explain this to me
  6. #19
  7. phpkid ~~~~~~ :o)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Nov 2000
    Location
    NJ, USA
    Posts
    2,534
    Rep Power
    16
    hi,

    check this.
    On sites using user login, we have to be very careful with our SQL. Lets say we have a login page like this:



    <form action="login.php" method="post">
    User name:
    <input type="text" name="Username"/>
    Password:
    <input type="password" name="Password"/>
    <input type="submit" value="OK" />
    </form>




    We can assume that $Username and $Password are used in an SQL command like this: "SELECT * FROM UserTable WHERE Username='$Username' AND Password='$Password'". The application will then check if the SQL command returned one record and then log in.

    Many of these sites have thousands of users, and we can guess that there is a user called "john", "smith", "boss" or even "admin". If we type "admin';--" in the Username field and just some rubbish in the Password field this SQL command would be executed: "SELECT * FROM UserTable WHERE Username='admin'; --' AND Password='fdgd'". As many of you know -- is the SQL syntax for a comment, causing the database to ignore everything behind --. In this example the database will not check the password and return one record of we have a valid user name. In other words: We're in.

    There are several ways to avoid this. We could check for -- and ' in Username and ignore there requests. But the best way is probably to escape the string causing ' and -- to be treated like every other character.

    i found it here.
    pretty interesting !!!
    jd
    _____________________________
    d.k.jariwala (JD)
    ~ simple thought, simple act ~
    I blog @ http://jdk.phpkid.org
  8. #20
  9. No Profile Picture
    Code Junky
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Location
    Central Missouri
    Posts
    358
    Rep Power
    0

    Re: Security Notes (Everyone should read)


    Originally posted by JeffCT
    6. IF YOU DON'T WANT PEOPLE TO SEE IT, GIVE IT A .PHP EXNTESION.

    yoursite.com/lib.inc
    Actually, this "can" be changed (on Apache) at least..

    here's a "simple" yet effective solution, that makes sure "any" file
    you are using on the Apache server (that is PHP) is sent to the
    PHP interpreter..

    such as ".inc" files..

    basically, I simply added an AddType line to my .htaccess file, which tells Apache to pass .inc files through PHP.

    AddType application/x-httpd-php .php
    AddType application/x-httpd-php .php3
    AddType application/x-httpd-php .inc

    -------------------------------------------------------------------------------
    So, in my case, if you call one of my .inc files... you will most likely get "nothing" but a blank a browser window.. (this depends on the include file, of course.. if the includes does some type of "execution" - then whatever output is delivered.. )
    -------------------------------------------------------------------------------

    In short, "if your on Apache, and your host allows "overrides".. then you can set up an htaccess file and establish this type of thing.

    Call it a security feature if you wish, to me "it" just makes sense.

    I think it's actually a bennie of Apache.. allows you to pretty much use an file extension as a PHP document.. This "isn't recommened!".. i.e. you don't want to set up .htm or .html as an PHP file extension.. you "could" be wasting server processes.

    I do recommend checking with your provider before implementing, 1 - they may have some restrictions.
    2 - they may "already" have this set.
    3 - they may not have Allow Override enabled.

    I must admit.. after reading this post, I just "smiled".. going he he.. I know that.. I know that.. I know that .. "cool" more security minded than I thought

    Maybe this comes from authoring Perl scripts for so long.. Frankly, I've seen "too" many Perl scripts have "major" wholes in them.. probably the most infamous one (as of late) has been thrid parties exploiting a hole in the "famous" formmail.pl script.. which, did not prevent third parties from using it to send email remotely...

    i.e. with FormMail.pl you could pass a query string to it, and it would send email.. so unscroupulous spammers can use your formmail script to send spam...
  10. #21
  11. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Posts
    35
    Rep Power
    14

    internal security vs external security


    I've also worked most of this out before, both in my code, and others, and this seems a fairly good guide.

    I think JeffCT makes a very good point about the script security being a bigger risk that the webserver's security bugs. I think this has been proven to be the case in the last couple of years, with the biggest security botch ups shown in the media, haveing been discovered by people with very little knoledge of hacking, and mostly by changing things in the url query string.

    One of the biggest problems i have come accross is where sites check usernames and passwords, and then give a list of orders etc, and these can be viewed/edited by clicking on them. Although these often check that you are a valid user of the system, they quite often neglect to check if the order you are trying to view is yours! eg you get links to:
    www.test.com/order.php?id=1234
    www.test.com/order.php?id=5678
    and you type:
    www.test.com/order.php?id=4321
    (which isnt your's)and it works!

    Also, another method i have used for including files, is to only take the filename, and not the extension, so:
    PHP Code:
    include $filename ".jpg"
    this is fine, unless you are including files with .php,asp,etc extensions!
  12. #22
  13. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41

    Re: Re: Security Notes (Everyone should read)


    Originally posted by Robert_J_Sherman


    Actually, this "can" be changed (on Apache) at least..

    here's a "simple" yet effective solution, that makes sure "any" file
    you are using on the Apache server (that is PHP) is sent to the
    PHP interpreter..

    such as ".inc" files..

    basically, I simply added an AddType line to my .htaccess file, which tells Apache to pass .inc files through PHP.

    AddType application/x-httpd-php .php
    AddType application/x-httpd-php .php3
    AddType application/x-httpd-php .inc


    Yeah I know. But that's not practical and I don't recommend anyone does that. Why? If you plan on running it on any servers other than your own, you should assume people aren't going to edit their .htaccess or httpd.conf just for your program when all you need to do is rename it to .php or .php3. I can't honestly see any reason why you would have to name it .inc, you don't get any benefit from doing that as opposed to .php or .php3.

    There's a workaround for one of my other points, the global variables one. You can turn those off in PHP. But *always* assume your users are going to have the default configuration. Don't setup your own special workarounds in your PHP configuration or web server configuration - not everyone will hae those. Just write careful PHP code to being with.
  14. #23
  15. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2001
    Posts
    1
    Rep Power
    0

    Important note to users of Dreamweaver


    a security issue related to your topic #6--

    IF someone directly codes a database connection in a Dreamweaver Template file or Library Item, AND uploads the template or library item files to the server, the php will be readable as plain text in the source, because the files have a .dwt or .lbi file extension and aren't parsed.

    So, if you use dreamweaver and php, check your site for uploaded Template files. Any thing in them you don't want seen? then remove them from the server.

    Dreamweaver will upload the Templates folder if you choose "upload dependant files" or syncronize the entire site.

    macromedia has been made aware of this, and the behavior of Dreamweaver 5 will be changed somehow when it comes to uploading templates and library items.
  16. #24
  17. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2001
    Location
    Slovenia
    Posts
    32
    Rep Power
    13

    Exclamation why not use sessions


    5. For protected areas, VALIDATE THE LOGIN EVERY TIME!What am I talking about here? Well, there are some cases where programmers will only use some sort of login.php script to first validate their username and password (entered through a form), test if they're an admin, and actually set an admin variable through a cookie!
    I don't get it

    It still think that the right way to do it, is to use session variables :
    PHP Code:
    <?php

    session_start
    ();

    // Is the session variable set ?

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

      }

    // Am I authorizzed ?
    // ------------------------------

          
    if ($HTTP_SESSION_VARS['UserStatus'] != "true")

             {
               
    header ("Location: LoginU.php"); 
              exit;
             }
    Your solution whit checking pass and username everytime is time and server consuming. I will agree to check it every time, if you convince me that there is a posibility to break in my script

    I know that session work with cookies, but aren't sessions made for such problems ? How can this be overriden ? Answer plizzz .... I need to know if my scripts using sessions are secure (I can't sleep at nights because of that discussion )

    Messner
  18. #25
  19. 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
    Your solution whit checking pass and username everytime is time and server consuming.
    Good point, I woule recommend sessions instead.
    (the original article was updated)
  20. #26
  21. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2001
    Location
    Slovenia
    Posts
    32
    Rep Power
    13

    Arrow session's and authenthication


    That about server resources wasn't meant in abslolute values.

    My point is, if you have two equally secure options and one is faster then the other, then you should go for the faster one .

    But my question that still bothers me a lot is:

    Is my script using authenthication check as desribed above secure or not ?
  22. #27
  23. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Posts
    35
    Rep Power
    14
    After thinking about it, i cant see any problems (but there may well be) with storing the logged-in variable in a session var.

    However:
    1. there is the overall problem with sessions, that they are hijackable, by another user using the same session id from the same or another machine. although the effort involved with this would probably be equivilent to that required to snoop the username/password.
    2. remember that when using sessions that the session data is stored in a file. On a system with many users, a properly indexed database may even respond quicker than session functions.
    3. depending on the isp's setup, a shared server will probably use the same tmp directory to store session files, so anyone with access to the system may be able to view your session data!

    Ofcourse security of a site is only as good as it's weakest point. If you are sending the username and password through unencrypted http requests, then they are prone to snooping (and caching - i have used so many sites that think i'm already logged in as someone else, because i access them through a proxy server).

    Another point here, is that you cant get round the problem of snooping etc by checking ip addresses. my current internet connection uses dynamic (hidden) proxy servers. And there are more than one, and my requests go through different ones for each request, giving the webserver varying ips for me.
  24. #28
  25. No Profile Picture
    aHVoPw==
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,058
    Rep Power
    15
    for some of my includes that come from the url:
    page.php?page=page1

    i try to make the actual file name harder to guess or different.

    in my directory of include files for example:
    blah_page1.php
    blah_page2.php

    and no one can see the files in this dir (hopefully).

    and the code could be like:

    PHP Code:
    if (file_exists(blah_$page.php)) {
      include(
    "$DOCUMENT_ROOT/director/blah_$page.php");
    }
    else { echo 
    "does not exist"; } 
    like someone said, the .php does restrict the file somewhat. also having a directory set in the include() can limit the files included, and files before that dir can't be accessed (right?)
    Visit my new IIS Tutorial Series!
  26. #29
  27. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Posts
    35
    Rep Power
    14
    Can anyone see any problems with the following security model for communication between 2 systems through http requests?

    system 1 and system 2 both know the password, which is never passed through a http request.

    system1 requests a unique id from system2. system2 generates an id, stores this id in a database, and returns it to system1.

    system 1 then can either:
    1. perform a request to do somthing (such as delete entrys) by an http request, passing the unique id and a password that is formed by :
    PHP Code:
    $request_password=md5($password.$unique_id); 
    or
    2. pass some data by an http request, passing the unique id and the data that is encrypted using a key that is formed by :
    PHP Code:
    $key=md5($password.$unique_id); 
    Upon either of these requests being made, system 2 will only allow requests to be made if the unique id is in the database, and will delete this id after the request has been made.

    I believe that in the first instance:
    -someone cant get the password from a request.
    -they also cant reuse the password/unique id from that request because they will no longer be valid

    In the second instance:
    -the cant obtain the password from the request.
    -they cant reuse the uniqueid for another type of request.
    -they cant make a fake request by obtaining another unique id, because they wont be able to encrypt the data with the right key (assuming the data is validated on system 2)
    -they cant decrypt the data being passed because they only know half the encryption key.

    Ofcourse at any time, anyone can obtain a unique id. however i cant see a way of them obtaining the secret password to go with it to do anything, without getting into either of the stytems to obtain the password stored in the php file, and if they manage this then they will have access to the information on those systems, so the security system is no longer of concern!
  28. #30
  29. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41
    Originally posted by Keiichi
    also having a directory set in the include() can limit the files included, and files before that dir can't be accessed (right?)
    Nope, that actually won't stop anything

    If you use ../ the in filename it assumes you mean the directory above the current one. So if the path to include was something like:

    /home/jeffct/public_html/include/$page

    They could set $page to:

    ../../../../../etc/passwd

    And if they didn't know how high your directory was they could just do something like this:

    ../../../../../../../../../../../../../../../../../../etc/passwd

    Just to make sure I was all the way at the root directory.

    Now, putting .php onto the end of $page does limit what can be included, but then any PHP file on the server could be included. If the server had something like anonymous FTP then someone could simply upload the code they want included and call it from your script.

IMN logo majestic logo threadwatch logo seochat tools logo