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?
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.
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@xxxxxxxxx> 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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
