Re: [PHP] hacks we should know about
Richard Lynch replied: ... - Kills file upload completely I *think* safe_mode can be on and files can be uploaded if the ISP works at it... But they have to want it bad enough to do some configuration. Most ISPs want to just install stuff as-is and not take the time to find out how to really configure it for optimum safety/functionality. ... Just curious about all of this. How many of these various security issues go away if you are hosting your own site and there are no user logins on the box other than your own and no services running except the web server? -- Bill Rausch, Software Development, Unix, Mac, Windows Numerical Applications, Inc. 509-943-0861 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] hacks we should know about
I don't host my own site so how can I put include files outside of the web root? I log on ftp and my top level IS the web root (htdocs), I can't go any higher. - seb -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: 17 August 2001 05:01 To: Bob Cc: [EMAIL PROTECTED] Subject: Re: [PHP] hacks we should know about hi i found it very helpful to know about hacks such as the below list and was wondering if anyone had any more dumb mistakes they could tell us before we make them. 1. http://www.somesite.com/source.php3?url=/etc/passwd 2. http://www.somesite.com?page=../../../../etc/passwd 3. not setting .inc files to be parsed by php This is the wrong solution to securing include files. The correct solution is to block any direct access to .inc files by either putting them outside your document root or by using an Apache deny rule. -Rasmus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] hacks we should know about
So sprach »Seb Frost« am 2001-08-21 um 18:25:08 +0100 : I don't host my own site so how can I put include files outside of the web root? I log on ftp and my top level IS the web root (htdocs), I can't go any higher. In this case you can't. Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 1 hour 29 minutes -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] hacks we should know about
Alexander Skwar wrote: So sprach »Seb Frost« am 2001-08-21 um 18:25:08 +0100 : I don't host my own site so how can I put include files outside of the web root? I log on ftp and my top level IS the web root (htdocs), I can't go any higher. In this case you can't. Dumb question: Can't he create a new folder under his web root (let's call it 'incs') and setup an .htaccess file that denies requests to files within that? -- W | I haven't lost my mind; it's backed up on tape somewhere. + Ashley M. Kirchner mailto:[EMAIL PROTECTED] . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6 http://www.pcraft.com . . .. Boulder, CO 80303, U.S.A. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] hacks we should know about
So sprach »Ashley M. Kirchner« am 2001-08-21 um 11:46:29 -0700 : Dumb question: Can't he create a new folder under his web root (let's call it 'incs') and setup an .htaccess file that denies requests to files within that? Yes, he might be able to do so - but it's also possible that the provider has disabled parsing of the .htacess file. Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 4 hours 36 minutes -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] hacks we should know about
There *SHOULD* be some directory outside htdocs you can get to... Talk to your ISP to see if there is. If not, create a directory and add Apache directives to Deny All access to that directory. Not as good, but better than nothing. -- WARNING [EMAIL PROTECTED] address is an endangered species -- Use [EMAIL PROTECTED] Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm Volunteer a little time: http://chatmusic.com/volunteer.htm - Original Message - From: Seb Frost [EMAIL PROTECTED] Newsgroups: php.general To: Rasmus Lerdorf [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 21, 2001 12:25 PM Subject: RE: [PHP] hacks we should know about I don't host my own site so how can I put include files outside of the web root? I log on ftp and my top level IS the web root (htdocs), I can't go any higher. - seb -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: 17 August 2001 05:01 To: Bob Cc: [EMAIL PROTECTED] Subject: Re: [PHP] hacks we should know about hi i found it very helpful to know about hacks such as the below list and was wondering if anyone had any more dumb mistakes they could tell us before we make them. 1. http://www.somesite.com/source.php3?url=/etc/passwd 2. http://www.somesite.com?page=../../../../etc/passwd 3. not setting .inc files to be parsed by php This is the wrong solution to securing include files. The correct solution is to block any direct access to .inc files by either putting them outside your document root or by using an Apache deny rule. -Rasmus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] hacks we should know about
just found this article and the author recommends the following for secure
php
scripting. what do the expects think?
This article has been discussed in excruciating detail on
[EMAIL PROTECTED] and the expert's opinions are archived...
http://php.net/support.php should lead you to this archive.
- Set register_globals off
This option will stop PHP creating global variables for user input. That
is,
if a user submits the form variable 'hello' PHP won't set $hello, only
HTTP_GET/POST_VARS['hello']. This is the mother of all other options and
is
best single option for PHP security, it will also kill basically every
third
party application available and makes programming PHP a whole lot less
convenient.
Expect to see register_globals off as the default setting in PHP 4.1, I
*THINK*.
*** - Set safe_mode on
I'd love to describe exactly what safe_mode does but it isn't documented
completely.
I dunno what more documentation he *WANTS* than what is on the web-site...
Not that I claim to *UNDERSTAND* it all :-^
- Kills file upload completely
I *think* safe_mode can be on and files can be uploaded if the ISP works at
it... But they have to want it bad enough to do some configuration. Most
ISPs want to just install stuff as-is and not take the time to find out how
to really configure it for optimum safety/functionality.
** - Set open_basedir
This option prevents any file operations on files outside specified
directories. This can effectively kill a variety of local include() and
remote file attacks.
Caution is still required in regards to file upload and
session files.
Which is why safe_mode exists.
** - Set display_errors off, log_errors on
This prevents PHP error messages being displayed in the returned web page.
This can effectively limit an attackers exploration of the function of the
script they are attacking. It can also make debugging very frustrating.
Not really.
First of all, you *OUGHT* to be developing on a different, non-public box
than your live server. Throw PHP on your laptop or desktop and write your
new code there, where you have display_errors on. Only on the live site do
you need display_errors off, and hopefully your code is mostly debugged by
that point.
Even so, you just open up another window and tail -f your error log file if
you need to debug something.
For any particularly tricky debugging, you can use something like this:
if ($REMOTE_ADDR == 'your.IP.address.here'){
echo whatever;
}
Only you want to use $HTTP_ENV_VARS['REMOTE_ADDR'] or whatever it is.
* - Set allow_url_fopen off
This stops remote files functionality. Very few sites really need this
functionality, I absolutely recommend every site set this option.
Well, I use it, but I suppose it's up to you. The things that go wrong with
this being on are (I think) the result of stupid code like:
include $foo;
which is already problematic, regardless of whether $foo is hacked to be a
remote file or a local one... Anybody else can weigh in on this, go ahead.
I think the *REAL* issues raised here is that far too many PHP scripters,
self included, are pushing code out to make it work and not focussing on
security enough. It's *POSSIBLE* to write more safe code, and the PHP Dev
team is working to make it easier. But for now, the onus is on *YOU* to
figure out what's safe enough and what's not for *YOUR* application.
--
WARNING [EMAIL PROTECTED] address is an endangered species -- Use
[EMAIL PROTECTED]
Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] hacks we should know about
On 17 Aug 01, at 0:08, [EMAIL PROTECTED] wrote: Not that I particularly want to turn this thread into a debate about unix security, but... Anyone with a clue doesn't use /etc/passwd anymore *shadow password file*, so thats kind of depreciated... While this is true a great deal of damage can still be started with access to your passwd file - gaining access to this file will, at the very least, disclose a list of valid system users, their home directory and default shell. This sort of information is useful when it comes to compromising a system - just imagine the circumstance where someone has development work sitting in their home directory - you now know the home directory. Of course, security through obscurity is never a valid approach but it's also worth trying to avoid the more obvious stuff if you can. CYA, Dave --- Outback Queensland Internet - Longreach, Outback Queensland - Australia http://www.outbackqld.net.au mailto:[EMAIL PROTECTED] --- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] hacks we should know about
just found this article and the author recommends the following for secure php scripting. what do the expects think? - Set register_globals off This option will stop PHP creating global variables for user input. That is, if a user submits the form variable 'hello' PHP won't set $hello, only HTTP_GET/POST_VARS['hello']. This is the mother of all other options and is best single option for PHP security, it will also kill basically every third party application available and makes programming PHP a whole lot less convenient. *** - Set safe_mode on I'd love to describe exactly what safe_mode does but it isn't documented completely. It introduces a large variety of restrictions including: - The ability to restrict which commands can be executed (by exec() etc) - The ability to restrict which functions can be used - Restricts file access based on ownership of script and target file - Kills file upload completely This is a great option for ISP environments (for which it is designed) but it can also greatly improve the security of normal PHP environments given proper configuration. It can also be a complete pain in the neck. ** - Set open_basedir This option prevents any file operations on files outside specified directories. This can effectively kill a variety of local include() and remote file attacks. Caution is still required in regards to file upload and session files. ** - Set display_errors off, log_errors on This prevents PHP error messages being displayed in the returned web page. This can effectively limit an attackers exploration of the function of the script they are attacking. It can also make debugging very frustrating. * - Set allow_url_fopen off This stops remote files functionality. Very few sites really need this functionality, I absolutely recommend every site set this option. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] hacks we should know about
hi i found it very helpful to know about hacks such as the below list and was wondering if anyone had any more dumb mistakes they could tell us before we make them. 1. http://www.somesite.com/source.php3?url=/etc/passwd 2. http://www.somesite.com?page=../../../../etc/passwd 3. not setting .inc files to be parsed by php This is the wrong solution to securing include files. The correct solution is to block any direct access to .inc files by either putting them outside your document root or by using an Apache deny rule. -Rasmus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] hacks we should know about
my 2 cents Anyone with a clue doesn't use /etc/passwd anymore *shadow password file*, so thats kind of depreciated... Your php process should not be running as root - typically you will give apache its own group, and apache + php will only be able to access files which that group has permission for. If you are running IIS on Windows, you are pretty screwed. More holes than a sieve. Change to apache or zeus. .htaccess files or apache.conf can set .inc or other files not to be passed to the webbrowser. You can set it to be restrictive, so only files you specify can get opened in a browser. turn off directory browsing in apache for directories without a default page. any data passed via the browser interface is suspicious. sanitize it for your data. eg if expecting a numeric value, check its numeric and zero it if not. error checking in the code is good, but try not to show too much info about the server. initialise all variables before using them. (in case someone passes something via get/post that may get used). if you use any common scripts, change the default passwords - there are a gazillion sites out there with the default script passwords out there. use an include file for database access passwords. keep this out of the webserver directory if possible. eg (sample example, not a functional one!) website is in /home/website /home is out of webservers directories. db.ini saved in /home ?php $db_pass=my password; $db_user=username; ? myphppage in /home/website ?php require /home/db.ini; mysql_connect ($db_pass,$db_user); ? common sense gets 99% of things. If the usual holes aren't there the script kiddies will go to another site with more holes. Don't forget to also keep up to date with recommended patches for your OS. Bugtraq.com and securityfocus.com are good places to keep up with both ends of the stick. -Original Message- From: Bob [mailto:[EMAIL PROTECTED]] Sent: August 17, 2001 11:43 AM To: [EMAIL PROTECTED] Subject: [PHP] hacks we should know about hi i found it very helpful to know about hacks such as the below list and was wondering if anyone had any more dumb mistakes they could tell us before we make them. 1. http://www.somesite.com/source.php3?url=/etc/passwd 2. http://www.somesite.com?page=../../../../etc/passwd 3. not setting .inc files to be parsed by php 4. setting directory ownership to nobody _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] hacks we should know about
rasmus, if password.inc is being parsed by php then how would you get the code??? won't it just be a blank page??? oh i thought up one more ... 4. checking for html tags and php scripting when accepting data from text boxes Rasmus Lerdorf wrote: hi i found it very helpful to know about hacks such as the below list and was wondering if anyone had any more dumb mistakes they could tell us before we make them. 1. http://www.somesite.com/source.php3?url=/etc/passwd 2. http://www.somesite.com?page=../../../../etc/passwd 3. not setting .inc files to be parsed by php This is the wrong solution to securing include files. The correct solution is to block any direct access to .inc files by either putting them outside your document root or by using an Apache deny rule. -Rasmus _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] hacks we should know about
rasmus, if password.inc is being parsed by php then how would you get the code??? won't it just be a blank page??? oh i thought up one more ... Include files are written to be included. They are tested and debugged in the scope of the file that is including it. Parsing such an include file outside of that scope can lead to security issues. 4. checking for html tags and php scripting when accepting data from text boxes HTML tags sure, but PHP tags? Unless you are doing an eval() on the text, the PHP tags will never get parsed by PHP. -Rasmus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] hacks we should know about
/ might be a correct path not a hack attempt. here's something normalizes a
directory for a given path passed to it.
eg /index.txt
eg ../../../ will get parsed out. such as in the
http://www.somesite.com?page=../../../../etc/passwd
Originally written for a directory browse script i use for a /pics directory
on www.shanghaiguide.com/pics
I used to use realpath, but it started working differently on my box in the
4.0.6 release, so I wrote this
function TruePath ($path){
//Not really optimized but it does work.
$patharray = explode (/, $path);
$path=;$count=count($patharray);//We have multiple count($patharray) so a
minor bit faster.
for ($i=0;$i$count; $i++){
if ( $patharray[$i] == . || $patharray[$i]== .. || ( (($i+1) $count)
($patharray[$i+1]== ..)) ) {
//If the current pos is a . ignore, if pos+1 == .. ignore, lastly if current
= .. ignore.
}
else {
$path .= $patharray[$i]./;
}
}
//Trim trailing slash
$path = substr($path,0,-1);
return ($path);
}
May or may not be useful for someone. I welcome an optimized one using a
regex, this was my non regex attempt ;)
Cheers,
Lawrence.
-Original Message-
From: ReDucTor [mailto:[EMAIL PROTECTED]]
Sent: August 17, 2001 1:42 PM
To: Bob; Rasmus Lerdorf
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] hacks we should know about
?php
if(ereg(/, $file))
{
$file = file(loggedips.txt);
$fp = fopen(loggedips.txt, w);
fwrite($fp, \r\n.$REMOTE_ADDR. to .$file);
for($i=0;$isizeof($file);$i++)
fwrite($fp, $file[$i]);
fclose($fp);
die(Hack attempt...IP Logged);
}
else
showsource($file);
?
- Original Message -
From: Bob [EMAIL PROTECTED]
To: Rasmus Lerdorf [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, August 17, 2001 2:17 PM
Subject: Re: [PHP] hacks we should know about
rasmus, if password.inc is being parsed by php then how would you get the
code??? won't it just be a blank page??? oh i thought up one more ...
4. checking for html tags and php scripting when accepting data from text
boxes
Rasmus Lerdorf wrote:
hi i found it very helpful to know about hacks such as the below list
and was wondering if anyone had any more dumb mistakes they could tell
us before we make them.
1. http://www.somesite.com/source.php3?url=/etc/passwd
2. http://www.somesite.com?page=../../../../etc/passwd
3. not setting .inc files to be parsed by php
This is the wrong solution to securing include files. The correct
solution is to block any direct access to .inc files by either putting
them outside your document root or by using an Apache deny rule.
-Rasmus
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
