PHP Security Warning....

nashirak

I was reading the lwn.net site (Linux Weekly News) and came accross this article. I think that everybody that does any includes() or requires() should read this.

http://lwn.net/2001/1004/a/php-vulnerabilities.php3

It basically states that you need to be careful when you include files... in particular make sure you give a set include path:

Insecure:

include("$path/file.inc");

What would happen if you left it like this? Well I could come along and do something like:

http://www.somesite.com/script?$path=http://mysite.com

you could then have an file.inc that does something really bad.

the more secure way is:

      include("somepath/file.inc");

The article delves more into it.
Just found the article while I was surfing the web, thought you guys might enjoy it as well.

[deleted]

Pretty far-fetched if you ask me.

If I were to use

include("$path/file.inc");

That would only work if I defined $path first. And once I define it in the script, you cannot overwrite it with anything.

Second, if I did take the $path var from the URL, you would still not know which file I was including, so how are you going to prepare your 'hacked' file?

Anon

$path would be overwritten if you supply a path argument to the URL, unless $path was a constant.

An open source PHP project would have its code available to anyone, so you could indeed know which file was being included.

[deleted]

"$path would be overwritten if you supply a path argument to the URL, unless $path was a constant. "

Care to show me how?
Try it and you'll find that they never overwrite anything. That's part of PHP's basic security. Much the same way as a POST or GET var will never overwrite any var that's in a session.

dannys

Not really much of an issue IMO, it assumes that:

The hacker knows the filename
The hacker knows the path variable-name
The variable is not defined as a constant
That nothing in the script assigns a value to that variable (thus over-writing the hacker's value).

In most of my files, config.inc.php is loaded at the top of each file - this contains all of the include paths etc, which will over-write any value held in the querystring.

Even if this was a big problem, ir would affect every scripting language, not just PHP

[deleted]

Not an issue at all if you ask me, unless the author of the script is a complete idiot.

The POST and GET variables cannot override anything you put in your script. That's because they are created first. They exist already when your script starts, so whatever you do in your script will override whatever came through the POST or GET.

nashirak

The only reason I posted this was FYI and to get your opinions on this article. Clearly in any language if you don't make sure that a variable is set or has some intial value in the script then you could possibly be suceptible to an attack. Granted the hacker must know the varable in question. However with a lot of opensource sites out there (this isnt as big of a deal with commercial sites). This can be a problem. (Or if you have something like phpnuke or something where the source code is avalable. )

Clearly this is a problem for a lot of scripting languages and not just PHP. But the article was on PHP in particular, so I thought you guys might enjoy it. :-) .

smileyq

As far fetched as it may seem there are probes out there that will simply scan your entire website for each and every file. I know I've used them on my servers to see how good they are. Just make sure to authenticate first before any file that you don't want anybody to get their hands on its that simple.

[deleted]

"As far fetched as it may seem there are probes out there that will simply scan your entire website for each and every file. "

Uhm.. ok, time to stop now.
So you can probe for each and every file on a server. That would have to be through brute-force, and with subdirectories and filenames averaging more 10 characters a piece, you'll be busy for quite some time.
And meanwhile the system admin sees his error-log get flooded with requests from your server. You'll soon be locked out/traced banned by your ISP.

Second, knowing which files are on a server does not help because you still have no clue as to which files are used by which scripts.
You could check some variables that are sent throuhg the URL or used in forms, but you still have no clue what they do. Then it's down to brute-force again, hoping that the programmer made a mistake.

In short: pretty flipping extremely nearly impossibly far fetched.

Authentication is hardly a solution, because you can't make all your visitors authenticate all the time.