Top Ten PHP Security Hole

**JimC** · Jul 17 '05, 02:57 AM

Re: Top Ten PHP Security Hole

"Chung Leong" <chernyshevsky@ hotmail.com> wrote in message
news:HuKdnfh8I_ cyCbzdRVn-jQ@comcast.com. ..[color=blue]
> Building web sites with PHP is easy. Building secured web sites--in any
> language--is hard. The end result is many PHP sites with security issues. I
> thought therefore it would be a good idea to put together a top ten list of
> mistakes to avoid, so that beginners have something concrete to check their
> work against, instead of fuzzy recommendations like "using session variables
> is more secured."
>
> Here's my nomination:
>
> * Copying an uploaded file into a web-accessible folder without checking its
> extension[/color]

Do you mean setting its permissions, or is there a security issue raised by
giving PHP files (e.g., ones that are included in a "regular" PHP file)
extensions other than ".PHP"?

[color=blue]
> This mistake allows someone to upload a .php file onto your website and gain
> complete control.[/color]

It's a good idea to include a blank index.htm file in auxiliary directories.
It might force a load of the Web site's home page with something
like

<body onload="javascr ipt:window.top. location='my-website.com';">

Jim

Cross-comp.com

https://www.cross-comp.com

404 Not Found

https://www.cross-comp.com/pages/software

for software goodies.

**gmuldoon** · Jul 17 '05, 02:57 AM

Re: Top Ten PHP Security Hole

chernyshevsky@h otmail.com says...[color=blue]
> Building web sites with PHP is easy. Building secured web sites--in any
> language--is hard. The end result is many PHP sites with security issues. I
> thought therefore it would be a good idea to put together a top ten list of
> mistakes to avoid, so that beginners have something concrete to check their
> work against, instead of fuzzy recommendations like "using session variables
> is more secured."
>
> Here's my nomination:
>
> * Copying an uploaded file into a web-accessible folder without checking its
> extension
>
> This mistake allows someone to upload a .php file onto your website and gain
> complete control.[/color]

Suggest it should just read:

* Copying an uploaded file into a web-accessible folder

I now always put uploaded files outside the web server doc root, and use
a function to safely "deliver" (read, not execute/parse) them back to a
browser if required.

Geoff M

**Dan Tripp** · Jul 17 '05, 02:57 AM

Re: Top Ten PHP Security Hole

JimC wrote:
[color=blue]
> "Chung Leong" <chernyshevsky@ hotmail.com> wrote in message
> news:HuKdnfh8I_ cyCbzdRVn-jQ@comcast.com. ..
>[color=green]
>>Building web sites with PHP is easy. Building secured web sites--in any
>>language--is hard. The end result is many PHP sites with security issues. I
>>thought therefore it would be a good idea to put together a top ten list of
>>mistakes to avoid, so that beginners have something concrete to check their
>>work against, instead of fuzzy recommendations like "using session variables
>>is more secured."
>>
>>Here's my nomination:
>>
>>* Copying an uploaded file into a web-accessible folder without checking its
>>extension[/color]
>
>
> Do you mean setting its permissions, or is there a security issue raised by
> giving PHP files (e.g., ones that are included in a "regular" PHP file)
> extensions other than ".PHP"?
>
>
>[color=green]
>>This mistake allows someone to upload a .php file onto your website and gain
>>complete control.[/color]
>
>
>
> It's a good idea to include a blank index.htm file in auxiliary directories.
> It might force a load of the Web site's home page with something
> like
>
>
> <body onload="javascr ipt:window.top. location='my-website.com';">
>
> Jim
> www.cross-comp.com
> www.cross-comp.com/pages/software
> for software goodies.
>
>
>
>[/color]

Maybe it'd be better to have an index.php file that has a redirect
header in it. Kinda like:

<?php
header("Locatio n: http://www.my-website.com/");
?>

That way it'd redirect if the client's browser has javascript disabled.

- Dan

http://blog.dantripp.com/

**Ian.H** · Jul 17 '05, 02:57 AM

Re: Top Ten PHP Security Hole

On Thu, 05 Feb 2004 02:59:05 +0000, Dan Tripp wrote:
[color=blue][color=green]
>> It's a good idea to include a blank index.htm file in auxiliary
>> directories. It might force a load of the Web site's home page with
>> something like
>>
>>
>> <body onload="javascr ipt:window.top. location='my-website.com';">[/color][/color]

[color=blue]
> Maybe it'd be better to have an index.php file that has a redirect header
> in it. Kinda like:
>
> <?php
> header("Locatio n: http://www.my-website.com/");
> ?>
>
> That way it'd redirect if the client's browser has javascript disabled.[/color]

Shouldn't this be done at the server level?

[.htaccess]
RedirectMatch .* http://foobar.com

or if just denying:

[.htaccess]
Order deny,allow
Deny from all
Allow from none

Regards,

Ian

--
Ian.H
digiServ Network
London, UK

http://digiserv.net/

**Manuel Lemos** · Jul 17 '05, 02:57 AM

Re: Top Ten PHP Security Hole

Hello,

On 02/04/2004 10:50 PM, Chung Leong wrote:[color=blue]
> Building web sites with PHP is easy. Building secured web sites--in any
> language--is hard. The end result is many PHP sites with security issues. I
> thought therefore it would be a good idea to put together a top ten list of
> mistakes to avoid, so that beginners have something concrete to check their
> work against, instead of fuzzy recommendations like "using session variables
> is more secured."[/color]

My favourite is leaving the database server accessible for everybody to
connect from outside the server of a site. Even better is to use MySQL
with root account password empty.

If you know a site that uses MySQL, try telneting to port 3306, or just
use a MySQL client specifying as host the address of the site and using
the root user with no password. If you can connect successfully, you can
party in the site database! ;-)

--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

Metastorage - Data object relational mapping layer generator

MetaL - Metastorage - Object persistence API generator

http://www.meta-language.net/metastorage.html

**Cameron** · Jul 17 '05, 02:57 AM

Re: Top Ten PHP Security Hole

Chung Leong wrote:[color=blue]
> Building web sites with PHP is easy. Building secured web sites--in any
> language--is hard. The end result is many PHP sites with security issues. I
> thought therefore it would be a good idea to put together a top ten list of
> mistakes to avoid, so that beginners have something concrete to check their
> work against, instead of fuzzy recommendations like "using session variables
> is more secured."
>
> Here's my nomination:
>
> * Copying an uploaded file into a web-accessible folder without checking its
> extension
>
> This mistake allows someone to upload a .php file onto your website and gain
> complete control.
>
>[/color]

Once took a look at the code for a rather widly used web log script,
noticed that it seemed the developers had written it with the E_ALL
~E_NOTICE error setting, with me having it turned on locally I got a
screen full of notices, should someone be using it with register globals
on who knows what nasty things could happen.

~Cameron

**David Mackenzie** · Jul 17 '05, 02:57 AM

Re: Top Ten PHP Security Hole

On Wed, 4 Feb 2004 19:50:44 -0500, "Chung Leong"
<chernyshevsky@ hotmail.com> wrote:
[color=blue]
>Building web sites with PHP is easy. Building secured web sites--in any
>language--is hard. The end result is many PHP sites with security issues. I
>thought therefore it would be a good idea to put together a top ten list of
>mistakes to avoid, so that beginners have something concrete to check their
>work against, instead of fuzzy recommendations like "using session variables
>is more secured."
>
>Here's my nomination:
>
>* Copying an uploaded file into a web-accessible folder without checking its
>extension
>
>This mistake allows someone to upload a .php file onto your website and gain
>complete control.[/color]

* Never never never never never never never never never trust
client-imputted data (including GET vars - even if they don't come
from a form).

* Be aware of SQL injection attacks. Always use addslashes() when
inserting textual client-entered data into your database. Check that
numeric values really are numeric.

* Don't have links that "do" something (such as deleting a record).
Use a form with a POST action.

The first one is a bit fuzzy.

--
David ( @priz.co.uk )

**Shawn Wilson** · Jul 17 '05, 02:57 AM

Re: Top Ten PHP Security Hole

David Mackenzie wrote:[color=blue]
>
> On Wed, 4 Feb 2004 19:50:44 -0500, "Chung Leong"
> <chernyshevsky@ hotmail.com> wrote:
>[color=green]
> >Building web sites with PHP is easy. Building secured web sites--in any
> >language--is hard. The end result is many PHP sites with security issues. I
> >thought therefore it would be a good idea to put together a top ten list of
> >mistakes to avoid, so that beginners have something concrete to check their
> >work against, instead of fuzzy recommendations like "using session variables
> >is more secured."
> >
> >Here's my nomination:
> >
> >* Copying an uploaded file into a web-accessible folder without checking its
> >extension
> >
> >This mistake allows someone to upload a .php file onto your website and gain
> >complete control.[/color]
>
> * Never never never never never never never never never trust
> client-imputted data (including GET vars - even if they don't come
> from a form).
>
> * Be aware of SQL injection attacks. Always use addslashes() when
> inserting textual client-entered data into your database. Check that
> numeric values really are numeric.
>
> * Don't have links that "do" something (such as deleting a record).
> Use a form with a POST action.[/color]

LOL! I did this last one once and forgot to pw-protect the directory. Every
damn record got deleted. I thought it was odd that someone had guessed at the
directory name and got in. After checking the server logs I realized that an IE
toolbar I had to monitor site popularity reported the address to it's parent
site's bot. The bot then crawled the entire site. Luckily, I was able to get
the records from the backup tapes.

Anyway, lesson learned. I always pw-protect directories right away, even before
they contain real data. I never use links for any actions. And I always check
to make sure a valid user is logged in before executing admin scripts (just
because a directory is password protected today doesn't mean it won't be
accidentally removed in 6 months).

Regards,
Shawn
--
Shawn Wilson
shawn@glassgian t.com

GlassGiant.com - Make free pictures for your Facebook Photos!

http://www.glassgiant.com

**André Næss** · Jul 17 '05, 02:57 AM

Re: Top Ten PHP Security Hole

David Mackenzie:
[color=blue]
> * Don't have links that "do" something (such as deleting a record).
> Use a form with a POST action.[/color]

Uh... A POST action is not any different from a GET request in this respect.
What you shouldn't do is have administration systems that aren't password
protected. If you always make sure users authenticate themselves before
they perform operations like 'delete' then there is no problem.

André Næss

**Robert Downes** · Jul 17 '05, 02:58 AM

Re: Top Ten PHP Security Hole

Chung Leong wrote:[color=blue]
>
> Here's my nomination:
>
> * Copying an uploaded file into a web-accessible folder without checking its
> extension
>
> This mistake allows someone to upload a .php file onto your website and gain
> complete control.[/color]

How about using register-globals, despite being warned of the possible
holes it allows.
--
Bob
London, UK
echo Mail fefsensmrrjyahe eoceoq\! | tr "jefroq\!" "@obe.uk"

**Daniel Tryba** · Jul 17 '05, 02:58 AM

Re: Top Ten PHP Security Hole

Chung Leong <chernyshevsky@ hotmail.com> wrote:[color=blue]
> Building web sites with PHP is easy. Building secured web sites--in any
> language--is hard. The end result is many PHP sites with security issues. I
> thought therefore it would be a good idea to put together a top ten list of
> mistakes to avoid, so that beginners have something concrete to check their
> work against, instead of fuzzy recommendations like "using session variables
> is more secured."[/color]

I'm missing crosssite (java)scripting bugs: always (html)encode output
(don't forget ENT_QUOTES), to avoid session hyjacking...

--

Daniel Tryba

**Chung Leong** · Jul 17 '05, 02:58 AM

Re: Top Ten PHP Security Hole

Yup, that's a big one, while oft overlooked. I would list that as number
one, since it's look easy to exploit.

Uzytkownik "Daniel Tryba" <news_comp.lang .php@canopus.nl > napisal w
wiadomosci news:bvucqc$1n9 $2@news.tue.nl. ..[color=blue]
> Chung Leong <chernyshevsky@ hotmail.com> wrote:[color=green]
> > Building web sites with PHP is easy. Building secured web sites--in any
> > language--is hard. The end result is many PHP sites with security[/color][/color]
issues. I[color=blue][color=green]
> > thought therefore it would be a good idea to put together a top ten list[/color][/color]
of[color=blue][color=green]
> > mistakes to avoid, so that beginners have something concrete to check[/color][/color]
their[color=blue][color=green]
> > work against, instead of fuzzy recommendations like "using session[/color][/color]
variables[color=blue][color=green]
> > is more secured."[/color]
>
> I'm missing crosssite (java)scripting bugs: always (html)encode output
> (don't forget ENT_QUOTES), to avoid session hyjacking...
>
> --
>
> Daniel Tryba
>[/color]

**Chung Leong** · Jul 17 '05, 02:58 AM

Re: Top Ten PHP Security Hole

Thinking that POST is somehow more secured than GET deserves an honorable
mention. Once I was called into the office of this guy who claimed he'd
discovered a huge vulnerability: He could log in by adding
?username=jdoe& password=qwerty to the URL! He was still fiddling with HTTP
authenticating when he lost his job.

Uzytkownik "André Næss" <andrena.spamre allysucks@ifi.u io.no> napisal w
wiadomosci news:bvtkm5$pi$ 1@maud.ifi.uio. no...[color=blue]
> David Mackenzie:
>[color=green]
> > * Don't have links that "do" something (such as deleting a record).
> > Use a form with a POST action.[/color]
>
> Uh... A POST action is not any different from a GET request in this[/color]
respect.[color=blue]
> What you shouldn't do is have administration systems that aren't password
> protected. If you always make sure users authenticate themselves before
> they perform operations like 'delete' then there is no problem.
>
> André Næss[/color]

**Chung Leong** · Jul 17 '05, 02:58 AM

Re: Top Ten PHP Security Hole

Register_global s doesn't create holes. Programmers do. It pointless to say a
feature is somehow not safe when it's its misusage that causes issue. Using
$_GET certainly won't save you if you write something like:

include_once($_ GET['do']);

That's an actual sighting and is a security hole that deserves a place on
the top ten.

* Using a client-provided variable in include/require

This hole allows someone to insert arbitrary PHP code into a script by
linking in a remote script. Prepending the variable with a path doesn't
help, since an attacker can backtrack to a FTP pub folder or to the Apache
log file using ../../../../filename.

Uzytkownik "Robert Downes" <nospamplease@s ee.my.signature .con> napisal w
wiadomosci news:402269fa$0 $29113$65c69314 @mercury.nildra m.net...[color=blue]
> Chung Leong wrote:[color=green]
> >
> > Here's my nomination:
> >
> > * Copying an uploaded file into a web-accessible folder without checking[/color][/color]
its[color=blue][color=green]
> > extension
> >
> > This mistake allows someone to upload a .php file onto your website and[/color][/color]
gain[color=blue][color=green]
> > complete control.[/color]
>
> How about using register-globals, despite being warned of the possible
> holes it allows.
> --
> Bob
> London, UK
> echo Mail fefsensmrrjyahe eoceoq\! | tr "jefroq\!" "@obe.uk"[/color]

Top Ten PHP Security Hole

Top Ten PHP Security Hole

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment