FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » is mysqli_real_escape_string bullet proof with binary data?
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: is mysqli_real_escape_string bullet proof with binary data? [message #182344 is a reply to message #182341] Mon, 29 July 2013 16:17 Go to previous messageGo to previous message
Daniel Pitts is currently offline  Daniel Pitts
Messages: 68
Registered: May 2012
Karma:
Member
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.
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Major trouble with PhpDocumentor
Next Topic: Education Path to become a PHP developer using free online courses
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Nov 28 09:06:35 GMT 2024

Total time taken to generate the page: 0.23171 seconds