I recently had the "opportunity" to look for security problems in an inherited php application. I found the following seemingly innocent line of code:
require($_GET['menu'].'.inc');
Well let's think about it a little..
- Imagine there is somewhere one or more users that are not all that friendly ...
- Imagine $_GET['menu'] is something that comes from a user ...
- Imagine that php treats the include():d/require():d code as php and not html
- Imagine that the include():d/require():d file would not have to exist on the same server
- Imagine that there somewhere on the Internet exists text/plain file containing php code
If that was true, then we would have a $h*tload of problems, right? Fortunately that's not true... ..right?
..oh, wait.. *all* of those are true. Oops...
_1098.png){kind=small}
2 comments:
Hehe, you found code qualifying on dailywtf.com. :-)
To me, I'd say that part of the problem is PHP is over-intelligent in a bad sense. Of course, being able to fopen() http/ftp/whatever URLs is good. But since it can make your code be insecurity if you are not very aware of what you're doing, it should have to be enabled on a per-application basis. Oh, I forgot, PHP doesn't have support for applications... ;-)
A pile of junk is what it is. But it is a more stable pile of junk than ASP.NET on Linux so far so the junk will prevail.
The PHP configuration allow_url_fopen is not always turned on. When it is not, the fourth point isn't true.
But I do agree - this is a HUGE security problem!
Post a Comment