> Thanks Paul, that was a much better explanation than the one I was
> attempting. I'm guessing the OP was being thrown off by the colons in
> the SELECT statement above. I can see how those could look like
> comments to someone not familiar with PDO and named parameters.
>
It wasn't the colons be
>> > That said, I would recommend binding parameters if you can. It's a
>> > cleaner way of separating the logic of a query from its data, and
>> > theoretically more reliable than mysql_real_escape_string():
>> >
>> > http://en.wikipedia.org/wiki/SQL_injection#Parameterized_statements
>> >
>>
>> I
>> $stmt = $db->prepare("SELECT priv FROM testUsers WHERE
>> username=:username AND password=:password");
>> $stmt->bindParam(':username', $user);
>> $stmt->bindParam(':password', $pass);
>> $stmt->execute();
[8<]
> I haven't followed this thread, so I don't know what you mean by, "I
> do not see h
On Mon, Aug 17, 2009 at 10:10:47PM +0300, Dotan Cohen wrote:
> >> Logically, it does _not_ mean the same thing.
> >
> > Definitely not -- it would be a bit presumptuous to claim "If you do
> > X, the query is not vulnerable to SQL injection attacks" for just
> > about any value of X.
> >
>
> That
>> Logically, it does _not_ mean the same thing.
>
> Definitely not -- it would be a bit presumptuous to claim "If you do
> X, the query is not vulnerable to SQL injection attacks" for just
> about any value of X.
>
That is what I though: no magic bullet.
> That said, I would recommend binding p
> "Note: If this function is not used to escape data, the query is
> vulnerable to SQL Injection Attacks."
>
> Does that necessarily imply this:
> "If this function is used to escape data, the query is not vulnerable
> to SQL Injection Attacks."?
>
> Logically, it does _not_ mean the same thing.
D
2009/8/16 Caner Bulut :
>
> Hi Dotan,
>
> You can use htmlentities(), htmlspecialchars() and strip_tags() functions
> when you show your saved data on your web pages. mysql_real_escape_string
> function saved data into mysql DB with a secure way. But when you try to
> show data you still have to co
> You should in pretty much all cases be safe with just using the
> mysql_real_escape_string, which takes care of the - for you as well.
>
If I remember correctly, TFM once stated that mysql_real_escape_string
does not prevent SQL injection attacks, though I am hard pressed to
think of what it _is
What you are doing here is potentially altering valid user information
coming into MySQL. For example, if someone legitimately enters in --
or ; into some string that is going to be put into MySQL, some comment
or such, then what is put in, and then put out if you display it,
won't be the same.
Yo
.
-Original Message-
From: Dotan Cohen [mailto:dotanco...@gmail.com]
Sent: Sunday, August 16, 2009 9:43 PM
To: php-general.
Subject: [PHP] Sanitizing mysql inserts of user data
I am sanitizing user-entered data before storing in mysql with this
function:
function clean_mysql ($dirty) {
$dirty
I am sanitizing user-entered data before storing in mysql with this function:
function clean_mysql ($dirty) {
$dirty=trim($dirty);
$dirty=str_replace ("--", "", $dirty);
$dirty=str_replace (";", "", $dirty);
$clean=mysql_real_escape_string($dirty);
return $clean;
}
Is this goo
11 matches
Mail list logo
