Prev: linux admin needed in israel
Next: Advice on maintaining public and private files
From: Dotan Cohen on 19 Feb 2010 08:18
In order to prevent SQL injection, can one simply base64 encode the
data and store that? Then it can be decoded when I need to display it
on a website. I understand that this means that the data will not be
searchable, and that I still must sanitize it before printing it on
the site. Are there any other drawbacks or things to be aware of?
Thanks.

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

Please CC me if you want to be sure that I read your message. I do not
read all list mail.
From: Andrew Ballard on 19 Feb 2010 10:20
On Fri, Feb 19, 2010 at 8:18 AM, Dotan Cohen <dotancohen(a)gmail.com> wrote:
> In order to prevent SQL injection, can one simply base64 encode the
> data and store that? Then it can be decoded when I need to display it
> on a website. I understand that this means that the data will not be
> searchable, and that I still must sanitize it before printing it on
> the site. Are there any other drawbacks or things to be aware of?
> Thanks.
>
> --
> Dotan Cohen
>

One would be storage space, as base64 requires more space to store the
same data. For a single data element that might not be much, but when
multiplied over all the values stored in your table it makes a
difference.

Also, don't forget to validate/filter non-character data, which you
can't do with base64. Something like this is still vulnerable to SQL
injection even though it 'sanitizes' the expected character input:

<?php
// user_id expects an integer value
$user_id = $_POST['user_id'];

$comment = base64_encode($_POST['comment']);


$sql = "INSERT INTO `comments` (user_id, comment) VALUES ($user_id,
'$comment')";

?>



Andrew
From: Dotan Cohen on 19 Feb 2010 10:43
On 19 February 2010 16:27, tedd <tedd.sperling(a)gmail.com> wrote:
> At 3:18 PM +0200 2/19/10, Dotan Cohen wrote:
>>
>> In order to prevent SQL injection, can one simply base64 encode the
>> data and store that? Then it can be decoded when I need to display it
>> on a website. I understand that this means that the data will not be
>> searchable, and that I still must sanitize it before printing it on
>> the site. Are there any other drawbacks or things to be aware of?
>> Thanks.
>>
>> --
>> Dotan Cohen
>
>
> Dotan:
>
> You're a smart guy, why reinvent the wheel? The entire problem set has
> already been solved.
>
> Understand there are two issues here: 1) filtering input into a database; 2)
> escaping output to a browser.
>
> Use mysql_real_escape_string() to filter data before it's stored in a
> database (input).
>

I was under the impression that mysql_real_escape_string() was not a
100% solution. Is it? Note that I serve my pages as UTF-8 and also
declare them as such in the header and meta tag, but that does not
mean that a malicious entity won't return a request in a different
encoding.


> Use htmlentities() to retrieve data from the database to be displayed via a
> browser (output).
>

This I do. I'm not sure if it's enough, so I'd like some reassurance
on the matter. :)


> An excellent book on this (and much more) is Chris Shiflett's Essential PHP
> Security. You can pick it up on Amazon for less than $20 -- well worth the
> cost.
>

They don't ship to Israel! I have looked for it locally, but not found
it. I'm sure that I could "acquire" a copy on some p2p service but I
really don't like doing that. Maybe I could Paypal $20 to Chris
himself if that remains my only option! Chris, what say you? (CCed)


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
From: Dotan Cohen on 19 Feb 2010 10:45
> One would be storage space, as base64 requires more space to store the
> same data. For a single data element that might not be much, but when
> multiplied over all the values stored in your table it makes a
> difference.
>

That is a good point, thanks.


> Also, don't forget to validate/filter non-character data, which you
> can't do with base64. Something like this is still vulnerable to SQL
> injection even though it 'sanitizes' the expected character input:
>
> <?php
> // user_id expects an integer value
> $user_id = $_POST['user_id'];
>
> $comment = base64_encode($_POST['comment']);
>
>
> $sql = "INSERT INTO `comments` (user_id, comment) VALUES ($user_id,
> '$comment')";
>
> ?>

I see what you mean. In fact, userIDs are stored, and indeed I ensure
that they are integers!


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

Please CC me if you want to be sure that I read your message. I do not
read all list mail.
From: Dotan Cohen on 19 Feb 2010 12:57
> What about eBook ($23.99)?
>
> http://oreilly.com/catalog/9780596006563
>
> If you can get this, you can get that.
>

That may be a good idea. Certainly better than the pirate bay.

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

Please CC me if you want to be sure that I read your message. I do not
read all list mail.
 | 
Pages: 1
Prev: linux admin needed in israel
Next: Advice on maintaining public and private files