Re: Re: sql injection protection

On 01/26/2012 06:46 AM, Haluk Karamete wrote:

when we do b64e and then back b64d, you are saying. we get the org input all as clear text but this time as a string. because it is now a string, "(which by definition can not be executed)" what's the difference between b64e+b64d vs (string) casting then? if you were to cast the original input into string using (string), wouldn't you be in the same shoes?

Re-read his example. He encodes the data in PHP. But decodes the data in SQL. So, if you echo the SQL statement, you would see a base64 encoded string that SQL then decodes.

also on another note, if you know the userinput is in UTF-8, ( you verify that by running mb_detect_encoding($str, 'UTF-8', true); ), is there a situation where you think mysql_real_escape_string would fail in SQLINjection against string based user input ? The reason I ask this about specifically for strings is because it is fairly easy to validate againsts integers,floats,booleans using the built in validation filters.... my biggest issue is on strings... also what do you think about filter_sanitize_string.

read this: http://www.php.net/manual/en/filter.filters.sanitize.php Then read this: http://www.php.net/manual/en/filter.filters.flags.php It seems to me that filter_sanitize_string does not deal with anything other then ASCII. YMMV

and finally, where do you think PHP community plus Rasmus is having a hard time implementing what you have in mind - that is a one liner that will do the inline string interpolation you are talking about.. what's the issue that it hasn't been done before? On Tue, Jan 24, 2012 at 1:45 PM, Alex Nikitin<niksoft@gmail.com> wrote:

You don't need to store it in the database as b64, just undo the encoding into your inputs for the purpose of the explanation, this is language independent b64e - encoding function b64d - decoding function pseudo code given: bad_num = ') union select * from foo --' bad_str = "" good_num = 123456 good_str = "some searchable text" the b64 way: bad_num=b64e(bad_num) ... good_str=b64e(good_str) inserts: query("insert into foo (num, str) values (b64d(\""+bad_num+"\"), b64d(\""+bad_str+"\"))"); query("insert into foo (num, str) values (b64d(\""+good_num+"\"), b64d(\""+good_str+"\"))"); Can you see that this will safely insert clear text into the database? This is because when you convert anything from b64, it will return from the function as a string and will not be executed as code... Now let's try a search: bad_num= '1 or 2 not like 5' bad_str = "' or \"40oz\" like \"40oz\"" again we: bad_num=b64e(bad_num) bad_str=b64e(bad_str) then we can do a full text search: query("select * from foo where match(str) against(b64d(\""+bad_str+"\"))") or even a number search query("select * from foo where num=b64d(\""+bad_num+"\")") again this is possible because no matter what you put in bad num, it will never be able to make post b64e bad_num look like code, just looks like junk, until b64d converts it to a string (which by definition can not be executed) make sense now? by check i mean, run utf8_decode for example... Problem is, that i can tell you how to write the most secure code, but if it's hard, or worse yet creates more problems than it solves (seemingly), nobody other than a few individuals with some passion for security will ever find the code useful. We need to fix this on the language level, then we can go around and tell programmers how to do it right. I mean imagine telling a programmer, that something that takes them 2 lines of code now, can be done much more securely in 5-7, and it creates code that doesn't read linearly... Most programmers will just ignore you. I want to say, "hey programmer, what you do in 2 lines of code, you can do in 1 and make it impossible to inject into", then, then people will listen, maybe... This is where inline string interpolation syntax comes in, but it is not implemented in any programming languages, sadly actually. This is what i want to talk to Rasmus about.

-- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ http://www.bendsource.com/