| Re: is mysqli_real_escape_string bullet proof with binary data? [message #182345 is a reply to message #182344] |
Mon, 29 July 2013 18:01   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 7/29/2013 12:17 PM, Daniel Pitts wrote:
> On 7/28/13 5:46 PM, Jerry Stuckle wrote:
>> On 7/28/2013 3:16 PM, Luuk wrote:
>>> On 28-07-2013 21:05, Jerry Stuckle wrote:
>>>> On 7/28/2013 11:25 AM, Luuk wrote:
>>>> > On 28-07-2013 15:39, Jerry Stuckle wrote:
>>>> >> On 7/28/2013 8:54 AM, Luuk wrote:
>>>> >>>>>> ..and hope that the file 'upArrow.png' does not contain a ['] or
>>>> >>>>>> three?
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>> luuk@opensuse:~/public_html/temp> grep "'" upArrow.png
>>>> >>>>> Binary file upArrow.png matches
>>>> >>>>>
>>>> >>>>> luuk@opensuse:~/public_html/temp> hexdump -C upArrow.png | grep
>>>> >>>>> "'"
>>>> >>>>> 00000110 53 00 a0 04 00 60 cb 63 62 e3 00 50 2d 00 60 27
>>>> >>>>> |S....`.cb..P-.`'|
>>>> >>>>> 00000260 00 b0 6a 3e 01 7b 91 2d a8 5d 63 03 f6 4b 27 10
>>>> >>>>> |..j>.{.-.]c..K'.|
>>>> >>>>> 000003a0 51 c2 27 22 93 a8 4b b4 26 ba 11 f9 c4 18 62 32
>>>> >>>>> |Q.'"..K.&.....b2|
>>>> >>>>> 000003c0 37 24 12 89 43 32 27 b9 90 02 49 b1 a4 54 d2 12
>>>> >>>>> |7$..C2'...I..T..|
>>>> >>>>> 00000530 fb 81 0e 41 c7 4a 27 5c 27 47 67 8f ce 05 9d e7
>>>> >>>>> |...A.J'\'Gg.....|
>>>> >>>>> 00000720 0e 85 50 7e e8 d6 d0 07 61 e6 61 8b c3 7e 0c 27
>>>> >>>>> |..P~....a.a..~.'|
>>>> >>>>> 000007c0 91 bc 35 79 24 c5 33 a5 2c e5 b9 84 27 a9 90 bc
>>>> >>>>> |..5y$.3.,...'...|
>>>> >>>>> 000009e0 dd bd f3 7a 6f f7 c5 f7 f5 df 16 dd 7e 72 27 fd
>>>> >>>>> |...zo.......~r'.|
>>>> >>>>> 000009f0 ce cb bb d9 77 27 ee ad bc 4f bc 5f f4 40 ed 41
>>>> >>>>> |....w'...O._.@.A|
>>>> >>>>>
>>>> >>>>>
>>>> >>
>>>> >> It doesn't make any difference. The png could contain one or more
>>>> >> delimiters, i.e. an apostrophe, which will cause a syntax error in a
>>>> >> non-prepared statement.
>>>> >
>>>> > It DOES contain single-quotes (that is an apostophe?).
>>>> > and that DOES NOT cause a syntax error,
>>>> > because i'm using a prepared statement.
>>>> >
>>>> >>
>>>> >> Escaping strings is not just to prevent security leeks - it is
>>>> >> also to
>>>> >> ensure valid SQL.
>>>> >>
>>>> >
>>>> > I dont see any errors in the query.log or error.log of my MySQL
>>>> > installation (about updating this `testpng`-table).
>>>> > Therefore i dont see a point in ensuring validity of an already valid
>>>> > SQL.
>>>> >
>>>> > Can you give an example an file that would break my script?
>>>> > The script is here: http://pastebin.com/5D8ZGEhy
>>>> > My emailadress is: luuk34(at)gmail(dot)com
>>>> >
>>>> > I think i have shown that this script is working OK, and that there is
>>>> > no reason to do something with escaping string here.
>>>> >
>>>>
>>>> You're not reading my replies, Luuk. I said if it contains delimiters
>>>> and YOU ARE NOT USING PREPARED STATEMENTS. For instance:
>>>>
>>>> "INSERT INTO MyTABLE (bin_column) VALUES ('$png_data');
>>>>
>>>> Prepared statements are good for some things - but you have to also be
>>>> aware of the additional processing required when you use them.
> If you're concerned about additional processing, then you shouldn't be
> using PHP in the first place :-) Chances are there are aspects of the
> program which use more resources than prepared statements.
>
> I would posit that one should use prepared statements for everything,
> *unless* there is a critical performance requirement which cannot be met
> with them *and* you can provide for safe data.
>
> Profiling is necessary for determining performance penalty, and rigorous
> analysis is required for the safety. So, only highly skilled
> professionals with the appropriate tools should consider eschewing
> prepared statements. It seems to be an unfortunate reversal, where most
> highly skilled professionals always use prepared statements, and
> amateurs and students unwittingly use unsafe alternatives.
>
>>>>
>>>>
>>>
>>> From my code (at: http://pastebin.com/5D8ZGEhy):
>>> $stmt = $link->prepare("INSERT INTO testpng (image) VALUES (?)");
>>> $file = file_get_contents('upArrow.png');
>>> echo "Size before: ".strlen($file)."<br>\n";
>>> $stmt->bind_param('s', $file);
>>>
>>> Is above not a prepared statment?
> Luuk, I understand why you think Jerry was criticizing your code, but I
> don't believe he was. Your code is fine WRT SQL injection.
>
>>
>> Luuk, yes it is. But READ WHAT I'VE BEEN SAYING!
>>
>> I NEVER SAID YOU WERE NOT USING PREPARED STATEMENTS!
> Jerry, I understand why you are making a point about SQL injection, but
> in the context, it comes across as a criticism of Luuk's code, which
> actually is correct, and escaping would actually cause problems.
>
Sorry, I do not mean to criticize Luuk's code - in fact, I have
specifically tried NOT to criticize his code. I was only referring to
code which does NOT use prepared statements. It has nothing to do with
how he's writing his code.
--
==================
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
]