At 4:34 PM -0500 5/23/06, Richard Lynch wrote:
On Tue, May 23, 2006 9:52 am, tedd wrote:
At 9:45 AM +0100 5/23/06, Rory Browne wrote:
I'm not disagreeing with you, but how would that work? The file would
still have a suffix of ".gif" and as such wouldn't be recognized as
code to execute.
Unless you have ANOTHER bug somewhere in those million lines of PHP
code...
Which might maybe let you eval() that, or manage to include it or...
Why risk it?
Defense in depth.
It's not like a call to http://getimagesize is gonna kill you.
Even moving the image out of web tree and using readfile is fine for
all but the busiest servers.
[shrug]
I don't understand why people are so resistant to something so simple
that adds a layer of defense.
Again, I'm not disagreeing with anyone! Instead I'm simply trying to
understand how this might work.
Understanding a risk is one step closer to providing a proper
defense. Just placing an additional step is not necessary adding
another layer of defense and in fact goes against the "Simple is
Beautiful" security level that Chris Shifett addresses in his
Essential PHP security book.
As for using eval(), that function ranks number one on his "list to
pay the most attention to" with regard to security. I hope that no
programmer would use an evalu() on an uploaded image -- but, that
might be a way to make an image with embedded code do bad things.
However, the programmer would have to be an accomplice in the attack
by using eval() incorrectly.
In the past, I have used headers of jpg files to store information --
there's a lots of unused space there -- however, at some point, the
program that deals with the image has to switch from "this is an
image" to "this is an executable piece of code" for this to work. I'm
trying to understand how that would happen.
If this is something that is real, then I am also suggesting that
doing something with the "image" should screw-up any embedded code.
But, before providing a defense, one should understand the threat.
My $0.02.
tedd
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
