php-general Digest 24 Jan 2012 15:45:52 -0000 Issue 7663
Topics (messages 316375 through 316387):
Re: Update mailing list docs - How to unsubscribe?
316375 by: Geoff Shang
Re: php.net problems?
316376 by: Donovan Brooke
316377 by: Daniel Brown
316378 by: Donovan Brooke
316380 by: Daniel Brown
Re: sql injection protection
316379 by: Alex Nikitin
316387 by: Haluk Karamete
Continued Problems Accessing *.php.net?
316381 by: Daniel Brown
316383 by: Ghodmode
Re: Reading only RGB portion of an image, file_get_conents minus file headers
etc
316382 by: Robert Cummings
316384 by: Alex Nikitin
316385 by: Robert Cummings
316386 by: Alex Nikitin
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 Mon, 23 Jan 2012, Matty Sarro wrote:
I have been trying to unsubscribe from this list. I've gone through the
directions at http://www.ezmlm.org/ezman/ezman1.html as suggested by
http://us.php.net/mailing-lists.php. They don't seem to apply for these
lists as written (the method listed for unsubscribing involves sending an
email to mailinglist-unsubscr...@example.org, which in this case would be
mailinglist-unsubscr...@lists.php.net which sends back a lovely "invalid
email address" response).
list-unsubscribe: <mailto:php-general-unsubscr...@lists.php.net>
Geoff.
--- End Message ---
--- Begin Message ---
Daniel Brown wrote:
2012/1/23 Alex Nikitin<niks...@gmail.com>:
Rasmus confirmed that they are having issues with php.net:
You can use the sk.php.net mirror while they fix their problems, as
well as docs.php.net.
We had a primary system failure at the same time as a migration
was underway, which led to complications and subsequent failures of
the mirroring network. The issues are being resolved and mirrors are
coming back online. In the meantime, you may use one of the following
mirrors:
http://ca2.php.net/
http://sk.php.net/
http://docs.php.net/
And, until the matter is completely resolved, you can temporarily
change your mirror preference at the bottom of this page:
http://php.net/my.php
Good!, thought I went insane there for a moment and couldn't remember
any of the PHP functions... (as nothing was coming up in the search) ;-)
Donovan
--
D Brooke
--- End Message ---
--- Begin Message ---
On Mon, Jan 23, 2012 at 15:59, Donovan Brooke <li...@euca.us> wrote:
>
> Good!, thought I went insane there for a moment and couldn't remember any of
> the PHP functions... (as nothing was coming up in the search) ;-)
Can't it be both? ;-P
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
Daniel Brown wrote:
On Mon, Jan 23, 2012 at 15:59, Donovan Brooke<li...@euca.us> wrote:
Good!, thought I went insane there for a moment and couldn't remember any of
the PHP functions... (as nothing was coming up in the search) ;-)
Can't it be both? ;-P
Purple cucumbers are automobile..
Donovan
--
D Brooke
--- End Message ---
--- Begin Message ---
On Mon, Jan 23, 2012 at 16:30, Donovan Brooke <li...@euca.us> wrote:
>
> Purple cucumbers are automobile..
Mmm. *nods* Giggity.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
Start off with the fact that that article is from 2006, and its
written by a programmer...
> I was simply asking expert opinion with the intention to learn.
> There is so much docs out there (I mean not just out there but at top
> security sites like owasp ) that recommends database specific escape
> solution as one of the viable alternatives.
Escaping can work with a very specific set of circumstances, and it
can be secure, however it fails as a security practice, and thus fails
as a security solution.
> You make it seem like anyone who does not use PDO ( for one reason or
> another ), and rely on the mysql_real_escape_string can be by passed
> and SQL injected.
I can't tell you for sure, however any project that uses it as their
sole mean of sql injection protection can be exploited, yes. Just
because OWASP says that it is a solution, doesn't mean that it's a
good solution. Sometimes it's the only solution, yes, but it should
not be the only security practice.
> So you're saying the mysql_real_escape_string() isn't 100% secure either?
> Crikey, if that's true, then I'm willing to bet A LOT of scripts are
> "vulnerable" to this problem.
Any script that uses escaping as the sole means of protection, or
doesn't do good checking, which is a lot of scripts. But i mean i hope
it's no surprise, a lot of the web is vulnerable...
> Is there a fix that doesn't involve perpared statements? Perhaps a
> function that checks for this problem, and filters it? My
> charset/encoding knowledge is a bit limited, so I'd very much
> appreciate an answer. Thanks!
Sure, i have already mentioned it... The glorious base 64 hack...
> Is it really that simple? It's hard to believe that all these
> implementations out there that honors the recommended filter &
> database specific escape mechanisms would *easily* be vulnerable by
> simply someone sending ut7, is that what you are saying?
A lot are... likewise UTF16, and even UTF8 can often be an issue. The
issue with escaping is knowing what characters are "bad", if you think
you can escape a ' - tick and be safe, think again, in utf there are
dozens if not hundreds of characters that can represent a tick in
various circumstances. Again escaping fails as a security practice.
Yes it can work and make your code uninjectable, but it still fails as
a solution, even if secure...
--- End Message ---
--- Begin Message ---
4 questions... which is basically all it comes to.. After all this
back and forth emails, I think we should nail down these questions
cause they are still not completely covered in my mind.
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.
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?
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?
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.
On Mon, Jan 23, 2012 at 2:35 PM, Alex Nikitin <niks...@gmail.com> wrote:
> Start off with the fact that that article is from 2006, and its
> written by a programmer...
>
>> I was simply asking expert opinion with the intention to learn.
>> There is so much docs out there (I mean not just out there but at top
>> security sites like owasp ) that recommends database specific escape
>> solution as one of the viable alternatives.
>
> Escaping can work with a very specific set of circumstances, and it
> can be secure, however it fails as a security practice, and thus fails
> as a security solution.
>
>> You make it seem like anyone who does not use PDO ( for one reason or
>> another ), and rely on the mysql_real_escape_string can be by passed
>> and SQL injected.
>
> I can't tell you for sure, however any project that uses it as their
> sole mean of sql injection protection can be exploited, yes. Just
> because OWASP says that it is a solution, doesn't mean that it's a
> good solution. Sometimes it's the only solution, yes, but it should
> not be the only security practice.
>
>> So you're saying the mysql_real_escape_string() isn't 100% secure either?
>> Crikey, if that's true, then I'm willing to bet A LOT of scripts are
>> "vulnerable" to this problem.
>
> Any script that uses escaping as the sole means of protection, or
> doesn't do good checking, which is a lot of scripts. But i mean i hope
> it's no surprise, a lot of the web is vulnerable...
>
>> Is there a fix that doesn't involve perpared statements? Perhaps a
>> function that checks for this problem, and filters it? My
>> charset/encoding knowledge is a bit limited, so I'd very much
>> appreciate an answer. Thanks!
>
> Sure, i have already mentioned it... The glorious base 64 hack...
>
>> Is it really that simple? It's hard to believe that all these
>> implementations out there that honors the recommended filter &
>> database specific escape mechanisms would *easily* be vulnerable by
>> simply someone sending ut7, is that what you are saying?
>
> A lot are... likewise UTF16, and even UTF8 can often be an issue. The
> issue with escaping is knowing what characters are "bad", if you think
> you can escape a ' - tick and be safe, think again, in utf there are
> dozens if not hundreds of characters that can represent a tick in
> various circumstances. Again escaping fails as a security practice.
> Yes it can work and make your code uninjectable, but it still fails as
> a solution, even if secure...
--- End Message ---
--- Begin Message ---
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.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
I don't know what all the fuss was about. What's wrong with you
people. That document has been there for so many years... you should
have memorized it by now!
--
Ghodmode
http://www.ghodmode.com
On Tue, Jan 24, 2012 at 7:22 AM, Daniel Brown <danbr...@php.net> 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.
>
> --
> </Daniel P. Brown>
> Network Infrastructure Manager
> http://www.php.net/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
On 12-01-23 01:32 PM, Alex Nikitin wrote:
If you don't mind me asking, if you want performance, which is kind of
essential if you are processing a large number of files, why are you
doing it in PHP?
--
The trouble with programmers is that you can never tell what a
programmer is doing until it’s too late. ~Seymour Cray
Hi Alex,
If you're processing a large number of files, the bottleneck could just
as likely be the hard drive read/write and not so much PHP. And what's a
large number of files? 50? 100? 1000? 1000000? Remember, PHP internal
functions are usually wrappers around compiled C code... the shuffling
around in the PHP engine itself can be quite tiny.
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
Have you done image processing? In my experience, with image
generation, photography and processing, typically you are bound by
resources when processing large amount of files than your connection,
or sometimes even disk io.
--
The trouble with programmers is that you can never tell what a
programmer is doing until it’s too late. ~Seymour Cray
On Mon, Jan 23, 2012 at 7:51 PM, Robert Cummings <rob...@interjinn.com> wrote:
> On 12-01-23 01:32 PM, Alex Nikitin wrote:
>>
>> If you don't mind me asking, if you want performance, which is kind of
>> essential if you are processing a large number of files, why are you
>> doing it in PHP?
>>
>> --
>> The trouble with programmers is that you can never tell what a
>> programmer is doing until it’s too late. ~Seymour Cray
>
>
> Hi Alex,
>
> If you're processing a large number of files, the bottleneck could just as
> likely be the hard drive read/write and not so much PHP. And what's a large
> number of files? 50? 100? 1000? 1000000? Remember, PHP internal functions
> are usually wrappers around compiled C code... the shuffling around in the
> PHP engine itself can be quite tiny.
>
> Cheers,
> Rob.
> --
> E-Mail Disclaimer: Information contained in this message and any
> attached documents is considered confidential and legally protected.
> This message is intended solely for the addressee(s). Disclosure,
> copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On 12-01-23 09:29 PM, Alex Nikitin wrote:
Have you done image processing? In my experience, with image
generation, photography and processing, typically you are bound by
resources when processing large amount of files than your connection,
or sometimes even disk io.
It really depends on what you're doing with images, if it's intensive
processing that's already implemented in the gd or imagick library to
which you can just punt, then how much overhead do you think PHP is
really going to add since these are C implemented libraries? Sure, if
you are manipulating pixels one by one within your PHP code you may be
running into resource issues, but for scaling images, or cropping, or
even clipping and overlaying... you're not usually doing a whole lot
within PHP itself. The love is happening in the C code in these cases.
This is why when working with these libs you get a resource handle and
not a string. The resource handle almost certainly maps to a native GD
or imagick structure.
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
Absolutely agreed. A part of what i was asking deals with what he is
actually doing...
--
The trouble with programmers is that you can never tell what a
programmer is doing until it’s too late. ~Seymour Cray
On Mon, Jan 23, 2012 at 9:37 PM, Robert Cummings <rob...@interjinn.com> wrote:
> On 12-01-23 09:29 PM, Alex Nikitin wrote:
>>
>> Have you done image processing? In my experience, with image
>> generation, photography and processing, typically you are bound by
>> resources when processing large amount of files than your connection,
>> or sometimes even disk io.
>
>
> It really depends on what you're doing with images, if it's intensive
> processing that's already implemented in the gd or imagick library to which
> you can just punt, then how much overhead do you think PHP is really going
> to add since these are C implemented libraries? Sure, if you are
> manipulating pixels one by one within your PHP code you may be running into
> resource issues, but for scaling images, or cropping, or even clipping and
> overlaying... you're not usually doing a whole lot within PHP itself. The
> love is happening in the C code in these cases. This is why when working
> with these libs you get a resource handle and not a string. The resource
> handle almost certainly maps to a native GD or imagick structure.
>
>
> Cheers,
> Rob.
> --
> E-Mail Disclaimer: Information contained in this message and any
> attached documents is considered confidential and legally protected.
> This message is intended solely for the addressee(s). Disclosure,
> copying, and distribution are prohibited unless authorized.
--- End Message ---
