Re: Simple login form with cookies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 8, 2009 at 11:53 AM, PJ<af.gourmet@xxxxxxxxxxxx> wrote:
> Michael A. Peters wrote:
>> Daniel Brown wrote:
>>>     First, a reminder to several (including some in this thread) that
>>> top-posting is against the law here.
>>>
>>> On Wed, Jul 8, 2009 at 09:48, Martin Scotta<martinscotta@xxxxxxxxx>
>>> wrote:
>>>> $sql = 'SELECT * FROM your-table WHERE username = \''. $username .'\'
>>>> and passwd = md5( concat( \'' . $username .'\', \'@\', \'' . $password
>>>> .'\'))';
>>>
>>>     Second, another, more important reminder:
>>>
>>> <?php
>>> $username = '" OR 1 OR "';
>>> ?>
>>>
>>>     Since the first rows in a database are usually the default
>>> administrator logins, the first to match what is basically a 'match if
>>> this is a row' statement will be logged in.  The moral of the story:
>>> don't forget to clean your input (which I'm sure ya'all were doing....
>>> but with top-posters, you never know ;-P).
>>>
>>
>> prepared statements really do a pretty good job at neutering sql
>> injection. But one shouldn't be lazy with input validation anyway.
>>
> I have a couple of questions/comments re all this:
>
> 1. Doing the login and processing through https should add a bit more
> security, it seems to me.

It does add security between your user's web browser and the web
server. It's up to you to keep it secure once you receive it.

> 2. Cleaning is another bloody headache, for me anyway. I have found that
> almost every time I try to do some cleaning with trim and
> mysql_real_escape_string and stripslashes wipes out my usernames and
> passwords. I havent' been able to use them when doing the crypt and
> encrypt stuff with salt. Without cleaning it works fine... so, I'm a bit
> lost on this.
> Specifically, this wipes out my login and password... (I know, this is
> old code, but it is supposed to work, no? )
> //Function to sanitize values received from the form. Prevents SQL injection
>    function clean($str) {
>        $str = @trim($str);
>        if(get_magic_quotes_gpc()) {
>            $str = stripslashes($str);
>        }
>        return mysql_real_escape_string($str);
>    }
>
>    //Sanitize the POST values
>    $login = clean($_POST['login']);
>    $password = clean($_POST['password']);
>
> When I echoes the cleaned $login and $password, they looked like they
> had just gone through an acid bath before being hit by katerina
> (hurricane)... ;-) rather whitewashed and empty. There was nothing left
> to work with.

One thing to check - I'm pretty sure that mysql_real_escape_string
will only work if you have an open connection to mysql, because it
uses that connection to figure out what character encoding is being
used so it can escape the string accordingly. (If unable to connect,
it should raise an E_WARNING.)

I'm not sure why you would need to use @ with trim(), but that shouldn't matter.

Otherwise, nothing in there should mangle the input.

Andrew

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux