| Re: is mysqli_real_escape_string bullet proof with binary data? [message #182304 is a reply to message #182297] |
Sat, 27 July 2013 23:52   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 7/27/2013 2:10 PM, Pierre Jaury wrote:
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>
>> On 7/27/2013 5:45 AM, Luuk wrote:
>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>>> The target is to create and store thumbnail PNG images in a Mysql
>>>> table. Also any tips on actually getting the thumbnail data into a
>>>> variable - which package is recommended? I've always used GD, but
>>>> never been 100% happy with it
>>>>
>>>
>>> As far as the subject goes, i would say: DO NOT TOUCH binary
>>> data.....
>>>
>>> Simply store it, or not, in your database.....
>>
>> Bull. Binary data works fine in a database - and storing it there has
>> many advantages. Easy backup and improved data integrity are just two
>> of them.
>>
>> A file system is just a database with a different means of access.
>> They both store bytes.
>
> Well, there is no harm in *storing* binary data. However, binary data is
> no text string and should not be handled as text (first of all, most of
> text processing relies on encoding standards, which binary data
> obviously do not comply with).
>
> Storing binary data inside a database is perfectly fine. You should not,
> however:
> * use blobs or large text fields as table indexes, even if text indexing
> techniques have been improved
> * as a consequence, use them as key for selecting/sorting
> * embed them directly in a text request.
>
Yes and no. There is no means of identifying binary data by itself.
SQL inserts it as a string. You can use prepared statements (extra
overhead because it requires an extra call to the server), or you can
just insert it as a string using mysql_real_escape_string() (which
should be handled by the client library on the local machine instead).
> Prepared statement have multiple advantages when dealing with
> parameters:
> * there is no known database-related security issue when dealing with
> user supplied parameters as prepared statements bound parameters
> (whatever the data encoding or contents)
Properly escaped and handled, there are no database-related security
issues with direct selects, either.
> * the php overhead is reduced when dealing with large or numerous
> parameters (no complex/long string is concatenated inside php)
Actually, PHP overhead is INCREASED due to multiple statements making
calls which have to go all of the way to the server. This overhead is
much less than string concatenation.
> * the database processing is also usually faster because the lexer is
> released of most of the request length.
>
See above about database processing requiring more overhead.
> Prepared statements are a best practice, both for performance and
> security reasons, go for them ;)
>
There is no "best practice" for all occasions, and anyone who claims
there are does not understand all of the issues involved. What is
"best" is very dependent on the individual situation.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]