PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Mon Dec 11, 2017 12:52 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 60 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: Sun Aug 14, 2005 8:33 pm 
Offline
Forum Contributor
User avatar

Joined: Sun Feb 06, 2005 12:22 pm
Posts: 124
onion2k wrote:
In general, unless I'm going to have millions of different include files, I use a switch

This is an excellent approach and one I often recommend. It's very clear, plus it doesn't depend on any variables. Hard coded strings are very safe and obvious.

In contrast, look at how unclear the other suggestions are in comparison.

nielsene wrote:
Well you aren't stripping out "../"s so its possible that a file could escape the sandbox.

One security principle to which I adhere (or try to) is to never try to correct invalid data. When you do, you create an opportunity for you to make a mistake that yields a security vulnerability. For example, here is an approach I have observed quite frequently:

Syntax: [ Download ] [ Hide ]
$string = str_replace('..', '.', $tainted_string);

Can you think of a way around this?

nielsene wrote:
It is forced to be a php file so they couldn't show the passwd file.

That's not true. The way include works is the file (or resource) you reference is treated just like any other PHP file. If there are no PHP blocks, it's treated as raw output.

Roja wrote:
Thats why statements like "I've never had any problems" have no place in a discussion about security.

Roja++

Roja wrote:
Correct, because you are going above the root - which makes no sense.

What he said isn't correct, because going above root doesn't fail. Maybe it does on Windows or something, but the parent directory of root is root.

Todd_Z wrote:
If you tried to include /home/blah/public_html/../../index.php", you would get an error for file not being found.

I have no idea what you think you've proven, but try this:

/home/blah/public_html/../../../../../../../../../../etc/passwd

If you're on Windows, that won't work either, but maybe you get the idea.

Roja wrote:
They can't VIEW them, they can cause them to be included/executed.

Includes are treated just like any other PHP file. The only code that is executed is within PHP blocks. Everything else is just raw output.

So, if you're referring to his example of index.php, you're right. If this is the case, just be careful to qualify your statements. :-)

Hope that helps.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 14, 2005 9:05 pm 
Offline
Tutorials Group

Joined: Sun Jan 04, 2004 11:30 pm
Posts: 2692
shiflett wrote:
Roja wrote:
Correct, because you are going above the root - which makes no sense.

What he said isn't correct, because going above root doesn't fail. Maybe it does on Windows or something, but the parent directory of root is root.

Actually, going above the root does fail. If you use the correct number of parents, you can explore to directories next to the directory in question.

shiflett wrote:
Todd_Z wrote:
If you tried to include /home/blah/public_html/../../index.php", you would get an error for file not being found.

I have no idea what you think you've proven, but try this:

/home/blah/public_html/../../../../../../../../../../etc/passwd

If you're on Windows, that won't work either, but maybe you get the idea.

My code sample shows that you can use parent dirs (../), which previous posts claimed you couldn't do ("You can't access anything but the directory"). It allows you to go above, sideways, and below. By using the absolute value from the root, you can go all the way up, and all the way down.

From my reading, we actually agree, but your phrasing seems to indicate that you didn't quite understand what I meant. :)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 14, 2005 9:09 pm 
Offline
Forum Contributor
User avatar

Joined: Sun Feb 06, 2005 12:22 pm
Posts: 124
Roja wrote:
Actually, going above the root does fail.

On what platform? I'm not aware of any platform that has this behavior.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 14, 2005 9:57 pm 
Offline
DevNet Resident
User avatar

Joined: Fri Aug 16, 2002 8:57 am
Posts: 1834
Location: Watertown, MA
shiflett wrote:
In contrast, look at how unclear the other suggestions are in comparison.

nielsene wrote:
Well you aren't stripping out "../"s so its possible that a file could escape the sandbox.

One security principle to which I adhere (or try to) is to never try to correct invalid data. When you do, you create an opportunity for you to make a mistake that yields a security vulnerability. For example, here is an approach I have observed quite frequently:

Syntax: [ Download ] [ Hide ]
$string = str_replace('..', '.', $tainted_string);

Can you think of a way around this?

Yes I can. And yes normally I wouldn't correect the data, only detect and reject. (Ie check if filename = basename or reject) slightly strong versions can check for forward/backward slashes under a somewhat long set of encodings and reject in those as well.

Quote:
nielsene wrote:
It is forced to be a php file so they couldn't show the passwd file.

That's not true. The way include works is the file (or resource) you reference is treated just like any other PHP file. If there are no PHP blocks, it's treated as raw output.

Not true in this case. The OP was concatenating ".php" onto the user-provided name. That's what I mean by a PHP file, not a parsed file, but I can see the opportunity for confusion. Even if they asked for /etc/passwd it would end up being /etc/passwd.php


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 14, 2005 9:58 pm 
Offline
DevNet Resident
User avatar

Joined: Fri Aug 16, 2002 8:57 am
Posts: 1834
Location: Watertown, MA
shiflett wrote:
Roja wrote:
Actually, going above the root does fail.

On what platform? I'm not aware of any platform that has this behavior.

Same here... The only exception I'm aware of is if you've mada chroot/jail.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 14, 2005 10:07 pm 
Offline
Forum Contributor
User avatar

Joined: Sun Feb 06, 2005 12:22 pm
Posts: 124
nielsene wrote:
Not true in this case. The OP was concatenating ".php" onto the user-provided name. That's what I mean by a PHP file, not a parsed file, but I can see the opportunity for confusion.

I see now. Thanks.

An attacker can get around the .php concatenation on many platforms by using a NUL byte. For example:

http://example.org/test.php?p=../../../ ... /passwd%00

Try it - you might be surprised by the results.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 14, 2005 10:13 pm 
Offline
DevNet Resident
User avatar

Joined: Fri Aug 16, 2002 8:57 am
Posts: 1834
Location: Watertown, MA
Yup I've seen that too...

All these little exceptions is why I don't do user-provided includes. If I had to, I'd use the basename function, coupled with a regexp ([-A-Za-z0-9_]), with forced ending (.php or .inc depending on your preference, etc‚). The null-byte, full stops. and slashes wouldn't survive that.

As always, state what you'll accept, not what you'll reject. Its too easy to miss something if you only list the bad stuff.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 14, 2005 11:22 pm 
Offline
Forum Regular
User avatar

Joined: Thu Nov 25, 2004 10:53 pm
Posts: 708
Location: U Michigan
Oh, i see the security holes now. But no - I keep my server as clean as possible.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 15, 2005 10:13 am 
Offline
DevNet Master

Joined: Tue Jan 20, 2004 12:11 am
Posts: 4897
Location: Leuven, Belgium
http://www.php.net/realpath can come in quite handy ;)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 17, 2005 10:02 am 
Offline
Forum Newbie

Joined: Wed Aug 17, 2005 9:53 am
Posts: 1
how's this when you are simply including basic pages?
Syntax: [ Download ] [ Hide ]
$_GET['page'] = ereg_replace("[^[:alnum:] ]","-",$_GET['page']);


also, I was wondering if there is any way around
Syntax: [ Download ] [ Hide ]
include 'myPrefix_'.$_GET['page'].'.php';
I have tried to ../ my way out of it, but it seems secure.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 17, 2005 12:42 pm 
Offline
DevNet Resident
User avatar

Joined: Fri Aug 16, 2002 8:57 am
Posts: 1834
Location: Watertown, MA
Well the null byte can stop the .php. I'm not sure if an attacker could get a series of ^H control code in to delete the prefix, but that might be possible via some encoding or another.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 20, 2005 7:02 pm 
Offline
Forum Newbie

Joined: Wed Aug 03, 2005 10:47 am
Posts: 24
Location: NW Louisiana
I'm completely inexperienced regarding security issues and still very new to using PHP. From what I've read so far, am I in better shape for using an array of approved includes? This is the method I read about and it is the one I am using. Should I be using a different method? (I am using a testbed server at home for the time being.) :roll: :?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 20, 2005 7:16 pm 
Offline
DevNet Resident
User avatar

Joined: Fri Aug 16, 2002 8:57 am
Posts: 1834
Location: Watertown, MA
Yes, an explicit list of approved includes is a much more secure starting point. Its still possible to "mess it up" but its generally much safer.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 10, 2005 8:28 am 
Offline
DevNet Master
User avatar

Joined: Mon Sep 19, 2005 6:24 am
Posts: 3587
Location: London
Bit of forum Necromancy here, I sometimes use the following:
Syntax: [ Download ] [ Hide ]
<?php

$files = array('main', 'accounts', 'page2', 'blahblah', 'etc');



@include('/path/to/includes/' . $files[intval($_GET['pid'])] '.inc') or include('/path/to/includes/default.php');



?>


on my front controller(s) :)


Last edited by Jenk on Tue Oct 11, 2005 4:39 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 10, 2005 8:08 pm 
Offline
Forum Regular
User avatar

Joined: Sat Mar 12, 2005 8:13 pm
Posts: 703
Location: US
and that has to be the best way I've ever seen. ;)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 60 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group