1. (retired)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2003
    Location
    The Laboratory
    Posts
    10,101
    Rep Power
    0
    Yeah, POST is JUST as easy to spoof using telnet as GET is. Don't think POST is any safer than GET at all.
  2. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2004
    Posts
    30
    Rep Power
    0
    Originally Posted by jdk
    hi,

    check this.


    i found it here.
    pretty interesting !!!
    jd

    Good catch, however an easy way of fixing this problem would be to reverse it, especially if you have a hashed/encrypted password which you check.

    So instead of
    Code:
    login = '$login' AND password = '$pass'
    we would have
    Code:
    password = '$pass' AND login = '$login'
    where $pass value is already changed, so it shouldn't be affected and just spit out an unsuccessful result.
  3. Banned (not really)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 1999
    Location
    Brussels, Belgium
    Posts
    14,645
    Rep Power
    4492
    Originally Posted by duniyadnd
    an easy way of fixing this problem would be to reverse it, especially if you have a hashed/encrypted password which you check.

    So instead of
    Code:
    login = '$login' AND password = '$pass'
    we would have
    Code:
    password = '$pass' AND login = '$login'
    where $pass value is already changed, so it shouldn't be affected and just spit out an unsuccessful result.
    That doesn't fix anything if the security issue of an unescaped $login value is still put in the query. It just changes what value you'd use for $login, because SELECT 0 AND 0 OR 1 is still going to return TRUE.

    ---John Holmes...
    -- Cigars, whiskey and wild, wild women. --
  4. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    miami
    Posts
    151
    Rep Power
    13
    should either strip or escape the following chars from $_GET and $_POST:
    <
    >
    '
    "
    \
    /

    re: sepodati

    as i said, either strip them or escape them... different versions of php and your db server (oracle, mysql, mssql, postgresql) handle things differently. with my current php 4.1 and mysql 4.1 single quotes in queries are automatically escaped apparently. however on 2 other servers i dev with (php 4.x but 1 mysql one oracle) the single quotes are def not escaped (and oracle even bitches with errors while running the exact same code save changing the db class)

    furthermore, wouldnt u have to change the < and > to the html special chars? seems to me like someone could do some nasty stuff with forms right on your page <form action=somepage.php method=get>

    however for hacking forms i prefer a better technique of copying their html form and then writing my own form for it
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    london
    Posts
    63
    Rep Power
    12
    I'm not entirely sure if this has at all been covered, but there was a post regarding username and password snooping with sending them over http and not https. Well why not encrypt the username and password before sending them through any method using javascript....

    http://pajhome.org.uk/crypt/md5/

    I have never actually tested this script. however the developers site mentions usage on yahoo and vbulletin... so must be worth a look.

    Also another pointer i think is fairly secure is to encode your GET values into one reversable encrypted string along with a random string that acts like a digital id to ascertain the strings validity. assign that string to one value for instance

    ?ENC=YjE3NDQ2YWYwNWQ4aY6X7f0PLewhOndJB0f1xT+EVVV6bQ8WAFfjsQCvNatm5FVUQ8qWcxzOYKXrkrlbJy6aR6ysozSwBHO IxVSCv05flJfms7DQboHIc0d+

    instead of

    ?WELCOME=1&CHECK_SESSION=1&2Zu9dlsd8wh9R7388267=1&GO=../galleries&TASK=browse

    note the 2Zu9dlsd8wh9R7388267. This is the would be random digital id you would check for when decoding your ENC value. if it doesn't exist abort the script.

    Also you can ignore all other GET properties as they are all contained and hidden in the ENC string.

    From my understanding this is fairly secure way of passing important vars. Especially when using a hask key that is in an encoded php file. However please correct me and remove my post if i am wrong. I am still learning security techniques in php and am really still a beginner in these things.
  6. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    london
    Posts
    63
    Rep Power
    12
    oh dear oh dear oh dear.... having jsut mentioned javascript md5 it appears md5 is now defunct

    http://www.schneier.com/blog/archives/2005/03/more_hash_funct.html
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    london
    Posts
    63
    Rep Power
    12
    while i'm on it....
    http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
  8. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2005
    Posts
    1
    Rep Power
    0
    Originally Posted by JeffCT
    There are two good solutions to this problem. One is on the same track as setting an $admin variable, but this time set $admin as a session variable. In this case, it is stored on the server and is much less likely to be forged. On subsequent calls to the same script, your user's previous session information will be available on the server, and you will be able to verify if the user is an administrator like so:

    if( $_SESSION['admin'] )

    The second solution is to only store their username and password in a cookie, and with every call to the script, validate the username and password and verify if the user is an administrator. You could have 2 functions - one called validate_login($username,$password) that verified the user's login information, and one called is_admin($username) that queried the database to see if that username is an administrator. The code would be placed at the top of any protected script:
    I would like to add another solution when you set the cookie, set it where username = username and pass = sha1($sitesecret.sha1('password')); then when you get the data back (this could be used even on the cookie that says admin=yes), check it by doing:
    if (sha1($sitesecret.sha1($realpass)) == $_COOKIE['pass']) {
    that way they cant set it without knowing the $sitesecret (which should be secret)
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2005
    Posts
    5
    Rep Power
    0

    restricting access to pages procedure


    Hi all,
    I 've found this thread very useful since I am just starting with php. I want to ask you if the following strategy is secure for restricting access to pages:

    1) In the restricted access pages, first I check if a cookie is set. If it's set I try to login with the username and password (which are stored in the cookie). If login is successfull I set session variables loggedin and accesslevel, accordingly.

    2) Check for the above session variables. If they are not set, transfer him to login page. If they are set allow him access to page

    Does this sound secure?
    Now that I am thinking about it, this solution wouldn't scale well, because for the users who have set a cookie, it would check the database for every page. So are there any suggestions?
  10. Banned (not really)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 1999
    Location
    Brussels, Belgium
    Posts
    14,645
    Rep Power
    4492
    Good article on SQL Injection here: http://www.unixwiz.net/techtips/sql-injection.html
    -- Cigars, whiskey and wild, wild women. --
  11. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2005
    Posts
    76
    Rep Power
    10
    Is the security information on this page, since Page 1 up to date? It was started in 2001, and I know PHP itself has evolved since then.

    For example, the PHP Injection methods I tried to run on the first page on my own site was not successful (which is good, right?), even though I am not using any strip/addalshes() on sending variables through MySQL to get data added or returned.

    So how much of talk about security from the older pages in this topic is still valid to 2005?
  12. (retired)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2003
    Location
    The Laboratory
    Posts
    10,101
    Rep Power
    0
    Good question. Also - who's going to read all 207 posts in this thread?

    --Simon
  13. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Oct 2004
    Posts
    556
    Rep Power
    0
    I read most of it. I tell you what - 99% of it is 100% useless, because it's conversation and not a direct outlined way of handling things, like it began.

    I've been working on security as the last step in my v1.0 release.

    Here's a checklist - if anyone knows major things I am missing let me know:


    1. Control sessioned variables

    2. Control (or in my case disallow) anything in $_GET

    3. Make sure all forms are submitted from the proper URL

    4. Check all form values to be sure they contain only allowed choice

    5. Check unique input type=text values with multiple functions - strip slashes, htmlentities etc.. to be sure they are not malicious

    6. Use intval and mysql_real_escape_string to further check all values entering into mysql, which have already been checked previously for sanitization.

    7. Put single quotes around values going into mysql db - big safety!

    I believe that is the major things I'm doing - simply put, i control possible values, and sanitize any value to be sure it is allowed.

    If anything comes up as "out of bounds" all the users information is sent to me, with a list of the rules broken and relevant variables, so I can see the problem or know of someone being sneaky


    Let me know from there if I've missed major steps, or even little ones. Perhaps I forgot something on the list
  14. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Oct 2004
    Posts
    556
    Rep Power
    0
    THIS TOPIC IS VALUABLE AS HELL. HERE'S MY SUGGESTION

    Why don't we make the first post in this - or a new thread - a simplistic outline of major and minor security advisement.

    While the thread continues discussion, any valuable security suggestion should always be in the first post.

    I can be edited once someone notices that it no longer refers to a valid version

    I think again this thread needs lots of attention because it is so valuable!

    I will type up explanations of how I dod the above 7 steps to add to it if wanted!
  15. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Oct 2004
    Posts
    556
    Rep Power
    0
    Here's a list of functions often used to sanitize data.

    [phpnet=htmlspecialchars]htmlspecialchars()[/phpnet]
    [phpnet=stripslashes]stripslashes()[/phpnet]
    [phpnet=trim]trim()[/phpnet]
    [phpnet=n12br]n12br()[/phpnet]
    [phpnet=htmlentities]htmlentities()[/phpnet]
    [phpnet=strip_tags]strip_tags()[/phpnet]
    [phpnet=intval]intval()[/phpnet]
    [phpnet=mysql_real_escape_string]mysql_real_escape_string()[/phpnet]
    Last edited by codergeek42; October 12th, 2005 at 11:03 PM. Reason: Made each function name a hyperlink to the corresponding php.net reference for convenience.

IMN logo majestic logo threadwatch logo seochat tools logo