php-general Digest 26 Jan 2012 14:44:09 -0000 Issue 7664
Topics (messages 316388 through 316394):
Re: Continued Problems Accessing *.php.net?
316388 by: Al
316390 by: Daniel Brown
316391 by: Stuart Dallas
Re: sql injection protection
316389 by: Alex Nikitin
316392 by: Haluk Karamete
316393 by: Alex Nikitin
Autoloading
316394 by: Floyd Resler
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 1/23/2012 6:22 PM, Daniel Brown wrote:
ALL:
As you may have noticed, early this morning we got bored and
decided to delete php.net from the Internet. After getting an
estimated sixteen-point-four trillion complaints, we became
overwhelmed and aggravated by your incessant need to RTFM that we
pressed CTRL+Z and brought it back. You're welcome.
In earnest, a catastrophic failure on one of our systems coincided
with a migration effort being headed by some very talented folks.
This led to a domino effect of issues that resulted in a temporary -
but widespread - impact on the online version of the documentation and
downloads. Things are nearly back to "normal" now across the network
--- or so it seems. If you come across any issues on your favorite
*.php.net mirror, please let us know at https://bugs.php.net/ or via a
reply to this thread and we'll check it out.
As a result, a list of the top ten reasons PHP had an outage today:
10.) We installed an experimental PECL module named "Invisible Ink."
9.) We learned our indoor solar panels don't work when the
lights get turned off.
8.) We had our mobile bandwidth slowed to a crawl because we
exceeded 2GB for the month.
7.) A Groupon swarm for two free downloads for the price of
one killed our network.
6.) We whited out this time to protest another
Patriots/Giants Superbowl, while the BC Lions never even got a phone
call.
5.) Our build of mod_expires runs on the Mayan calendar, and
attempting to do a 60-day expire segfaulted.
4.) The $25.90 check we wrote to cover the server's AOL
dial-up bounced.
3.) It's Chinese New Year, but it was too cold to set off the
fireworks outside today, so.... sorry.
2.) As it turned out, all our base truly were belong to them.
1.) We needed 7,500,001 signatures on the petition against SOPA/PIPA.
Thanks to all for your patience and such. And, of course, apologies to
all.
Now, how about having the "some very talented folks" fix the severely restricted
access to the NNTP server. Rarely can I download more than about 10 topics
without a time out.
Per your request several times over at least 2 years, I've filed bug reports.
The problem still exists. Though until about a week ago, it was a little better.
Al............
--- End Message ---
--- Begin Message ---
On Tue, Jan 24, 2012 at 11:53, Al <n...@ridersite.org> wrote:
>
> Now, how about having the "some very talented folks" fix the severely
> restricted access to the NNTP server. Rarely can I download more than about
> 10 topics without a time out.
>
> Per your request several times over at least 2 years, I've filed bug
> reports. The problem still exists. Though until about a week ago, it was a
> little better.
>
> Al............
I've also said several, several times over the last 5+ years that
this is intended as a mailing list. The news server is actually just
a byproduct of our archival system. Yes, I've said that I would work
on improving it, and I will.... but it'll never be more priority than
any of the regular required operations. Sorry that it causes you such
grief, Al.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
On 24 Jan 2012, at 16:53, Al wrote:
> Now, how about having the "some very talented folks" fix the severely
> restricted access to the NNTP server. Rarely can I download more than about
> 10 topics without a time out.
>
> Per your request several times over at least 2 years, I've filed bug reports.
> The problem still exists. Though until about a week ago, it was a little
> better.
>
> Al.........…
If it's that important to you, offer up some cash and I'm sure one or more of
those very talented folks will jump on making it better according to your
timescale. In the meantime please understand that nobody is getting paid to
improve the NNTP server, and since it's in no way a priority it lives at the
bottom of a very large pile of things to do.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
> 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.
--- End Message ---
--- Begin Message ---
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 <niks...@gmail.com> 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.
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
I am using __autoload for my site which is conflicting with the autoloading of
PHPExcel. I tried using spl_autoload_register thinking that might be the way
to go but when I tried I got a "cannot be redeclared" error. I include my
autoload script (include_once "../../lib/autoload.php";) and my autoload.php
script looks like this:
<?
function __autoload($class_name) {
$path="../../lib/class.$class_name.php";
if(file_exists($path)) {
require_once $path;
}
}
?>
As stated, when I change __autoload to spl_autoload_register I get the can't be
redeclared error. Any ideas?
Thanks!
Floyd
--- End Message ---
