Friday, November 17, 2006

Php and security ...

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...



Technorati tags: ,

2 comments:

perlun said...

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.

Per Persson (md2perpe) said...

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!