Andrew Ballard wrote:
> On Wed, Jul 8, 2009 at 11:53 AM, PJ<> 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<>
>>>> 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,
It's always open... I think.. do you mean within the active script (the
one I'm working on) ? Yes. yes, it's open.
the user_name was just plain alphabet soup... no special characters...
the password, though, had some uppercase weirdos... like @$$
(backslashing doesn't seem to help)... oh, well.... :-\
>  because it
> uses that connection to figure out what character encoding 
Ohmygod.... not character encoding... it's such a mess for me. I try to
only use utf8 but theres so much confusion with that that I have stopped
thinking about it until a problem occurs... like in Firefox ... iget
emails with the Western encoding and the utf8 so I often have to
switch... and the prinouts don't follow either... lots of little black
diamonds... a reat pita.
> 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.
Frankly, I don't know either. I borrowed the code somewhere; but I
usually just 86 those @ts so I can see errors.
> Otherwise, nothing in there should mangle the input.
mangle does as mangle can mangle... :-D
> Andrew

Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
Phil Jourdan ---

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to