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