My reply is in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> delims.
> question 1
>
> If you use the PHP filters & sanitizations, and you plan on using PDO
> with binded params, are you absolutely safe? And if not, why? What are
> the other ways for them to still make it in - even with PD0 and binded
> params properly in place? Just curious.
There are no known exploits or techniques on injecting into
parameterized queries.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
that's very good know.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> question 2
>
> If you use the PHP filters & sanitizations, and for some reason, you
> CANNOT use PDO, what do you do against those situations where the user
> input is expected to be coming as a string and it's perfectly OK for
> it to be in say, around 1000 chars! For example, you are receiving a
> guest book comment. Use b64? But isn't with b64 search capability go
> down the drain? So we basically give up on search? Can we not come up
> with a solution which allows the search but yet still safe? What do we
> do?
Search depends on your search, for example if i have 1000 chars, i may
not want to search on all the words, only some key words, in which
case b64 doesn't mean that you can't search. Doing full text index on
a 1000char field in a decently large database can be quite hazardous
to performance... On another note, you can still insert as clear text:
insert into foo (bar, pub) values(b64d("c2hvdHM="), b64d("YmVlcg=="))
it doesnt matter what is encoded in the b64, what matters is that it
is NOT code that SQL will execute, you see what i'm saying?
You can be decently secure with escaping, but again, it fails as a
security solution. If you can do neither, then set the default char
set on the page, database and even in php do a utf8_decode or
something, validate, check, escape and you will be reasonably secure.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
I'm not getting this one, in fact, I am totally lost in it. that's
because I am not familiar with b64 encoding... look, I supplied the
user input "; drop table members" and then did a b64 on it, it gave me
back "OyBkcm9wIHRhYmxlIG1lbWJlcnM=". When I decode that back, I ended
up with what I started that is "; drop table members". Knowing that,
are you suggesting we do the following then?
take the user input. example "; drop table members"
b64 it . now it's OyBkcm9wIHRhYmxlIG1lbWJlcnM=
then store it like that in the db.
and when you need to output back to screen, b64d to it ( that is b64 decode )
Well, If that's true, how do we allow user to search for say "drop
table" for example? All you got in the db is
OyBkcm9wIHRhYmxlIG1lbWJlcnM=. For a moment, I thought, if I do b64 on
the user's search string that is "drop table", search would work. But
when I tested, the b64 of the partial string "drop table" is
ZHJvcCB0YWJsZQ== and it is not part of the full string
OyBkcm9wIHRhYmxlIG1lbWJlcnM=. Can you elaborate then how the searching
would work? Any PHP sample may help where you used b64 trick in an
implementation.. Otherwise, I'm still lost in this one.
Also. when you say "set the default char set on the page.. ", do you
mean this? <meta http-equiv="content-type" content="text/html;
charset=UTF-8"> and when you say "set the default char set on the
page.. ", do you mean this? header("Content-Type: text/html;
charset=UTF-8");
Isn't "page" and "php" here in this context the same thing? In other
words, isn't header("Content-Type: text/html; charset=UTF-8");
produces on the resulting page <meta http-equiv="content-type"
content="text/html; charset=UTF-8">? What is that going to do to me if
the user supplied the evil string right from the browser bar - where
the referer is blank. I don't see how "setting the default char set"
by page or php is of any help.
And on the other hand when you say "set the default char set on the
database.. ", do you mean to use SET NAMES 'utf8';? By doing so, we
would make sure mysql_real_escape_string won't be get fooled. Is this
understanding correct?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> question 3
>
> is there really no way to stop the user input's if char set is not
> utf8? Can we not enforce the userinput to be in UTF8 only and reject
> all input? If there is such a way, wouldn't we better of using
> mysq-_real_escape to allow both search and be safe? Or is there really
> no way to understand the incoming user input char set by PHP?
Set the default encoding on page and db, check in php
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
when you say "check in php", do you check it with
mb_detect_encoding($str, 'UTF-8', true);
Is that your way of checking too?
And if you determine that it is UTF-8, are you completely fine with
the "mysql_real_escape_string" for your non PDA insert/select/updates?
yes/no.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> question 4
>
> do you have any white paper or any article that covers your most
> recommended solution against lengthy user input while you still want
> the search to work? you seem to know a lot and I think you should have
> at at least an article where we people can discuss the article at the
> bottom? It's always useful. If you don't have one, I strongly
> recommend you come up with one cause I'm sure it will be useful.
I do not, however i am thinking about talking to Rasmus, to see if
maybe i can get him to see the same issue with regards to the language
that i am seeing, I'll go from w/e comes out of that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
you seemed to have spent lots of time on the issue security and have a
passion in that. that's very good. therefore, you should put together
all your ideas and come up with an article that covers most down to
earth practical suggestions with code samples. Cause that's the only
way I see it effective. Mailing group emails are all fine but they are
scattered bits and pieces... in order to be thorough and efficient, I
think an article from your side is a long due one. Then you can just
refer people to your article. It would cut down the basic, discovery
issues.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
On Tue, Jan 24, 2012 at 9:01 AM, Alex Nikitin <niksoft@xxxxxxxxx> wrote:
>> question 1
>>
>> If you use the PHP filters & sanitizations, and you plan on using PDO
>> with binded params, are you absolutely safe? And if not, why? What are
>> the other ways for them to still make it in - even with PD0 and binded
>> params properly in place? Just curious.
>
> There are no known exploits or techniques on injecting into
> parameterized queries.
>
>> question 2
>>
>> If you use the PHP filters & sanitizations, and for some reason, you
>> CANNOT use PDO, what do you do against those situations where the user
>> input is expected to be coming as a string and it's perfectly OK for
>> it to be in say, around 1000 chars! For example, you are receiving a
>> guest book comment. Use b64? But isn't with b64 search capability go
>> down the drain? So we basically give up on search? Can we not come up
>> with a solution which allows the search but yet still safe? What do we
>> do?
>
> Search depends on your search, for example if i have 1000 chars, i may
> not want to search on all the words, only some key words, in which
> case b64 doesn't mean that you can't search. Doing full text index on
> a 1000char field in a decently large database can be quite hazardous
> to performance... On another note, you can still insert as clear text:
>
> insert into foo (bar, pub) values(b64d("c2hvdHM="), b64d("YmVlcg=="))
>
> it doesnt matter what is encoded in the b64, what matters is that it
> is NOT code that SQL will execute, you see what i'm saying?
>
> You can be decently secure with escaping, but again, it fails as a
> security solution. If you can do neither, then set the default char
> set on the page, database and even in php do a utf8_decode or
> something, validate, check, escape and you will be reasonably secure.
>
>> question 3
>>
>> is there really no way to stop the user input's if char set is not
>> utf8? Can we not enforce the userinput to be in UTF8 only and reject
>> all input? If there is such a way, wouldn't we better of using
>> mysq-_real_escape to allow both search and be safe? Or is there really
>> no way to understand the incoming user input char set by PHP?
>
> Set the default encoding on page and db, check in php
>
>> question 4
>>
>> do you have any white paper or any article that covers your most
>> recommended solution against lengthy user input while you still want
>> the search to work? you seem to know a lot and I think you should have
>> at at least an article where we people can discuss the article at the
>> bottom? It's always useful. If you don't have one, I strongly
>> recommend you come up with one cause I'm sure it will be useful.
>
> I do not, however i am thinking about talking to Rasmus, to see if
> maybe i can get him to see the same issue with regards to the language
> that i am seeing, I'll go from w/e comes out of that.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
