Re: [PHP] security issus
On Wed, 15 Sep 2004 12:47:05 -0400, H. Ch. Esperer [EMAIL PROTECTED] wrote: I have an apaci 1.3 and php 5.0.1 running on my machine and when I enter a url in a browser without a slash at the end of it I get the php script(!) instead of its output. When I add a slash, it works all right. Has anyone experienced this before? Did I just misconfigure something? This may be of some help: http://httpd.apache.org/docs/mod/mod_dir.html -- Greg Donald http://gdconsultants.com/ http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security - Semi OT
--- Dan Joseph [EMAIL PROTECTED] wrote: I am in the process of wrapping up a site for a friend of mine. It has logins, searching, account information, etc. I am wondering, does anyone on the list do any security auditing on the side? Chris, maybe you? Yes, but I might not be a good choice, because: 1. I'm pretty booked until mid to late October. 2. I value my time, so I'm not cheap. :-) Do you have any friends who know PHP? Peer reviews are always a good idea, regardless of whether your peers are security experts. There's a lot of information on PHP security readily available on the Web - I've been trying to provide as much as I can, including the PHP Security Workbook: http://shiflett.org/php-security.pdf You can get a few peers to educate themselves prior to review. Hope that helps. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming December 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security vulerability, any more detail info than this???
Scott Fletcher wrote: Saw a website about security vulerability and there's no info on php.net that can describe more about it. So, anyone know? http://pcworld.co.nz/news.nsf/0/4D6AE0157B37ACDCCC256ED200693BB3?OpenDocument One more reason to not use strip_tags... like I really needed another, though. -- ---John Holmes... Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/ php|architect: The Magazine for PHP Professionals www.phparch.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security/Web tree/db connect and select
John W. Holmes mailto:[EMAIL PROTECTED]
on Friday, May 28, 2004 11:25 PM said:
You're right. Option 2 offers more security in that no one will ever
be able to reach the file directly with a web browser. You don't need
to use file() or file_get_contents(), though... A simple
include('../includes/db.inc'); wil work (where ../ takes you outside
of the webroot and into an includes/ directory for the db.inc file).
Or use an absolute path include('/home/user/includes/db.inc'); where
/home/user/www/ is your webroot (for example).
how about just calling 'db.php' so that when someone does request it via
a web browser it will be parsed and end up not sending any data to the
client?
chris.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security/Web tree/db connect and select
Chris W. Parker on Tuesday, June 01, 2004 8:12 AM said: how about just calling 'db.php' so that when someone does request it via a web browser it will be parsed and end up not sending any data to the client? that should read, just calling *it* 'db.php', regarding the name of the file used to store the username/password info. c. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security/Web tree/db connect and select
From: Chris W. Parker [EMAIL PROTECTED]
You're right. Option 2 offers more security in that no one will ever
be able to reach the file directly with a web browser. You don't need
to use file() or file_get_contents(), though... A simple
include('../includes/db.inc'); wil work (where ../ takes you outside
of the webroot and into an includes/ directory for the db.inc file).
Or use an absolute path include('/home/user/includes/db.inc'); where
/home/user/www/ is your webroot (for example).
how about just calling 'db.php' so that when someone does request it via
a web browser it will be parsed and end up not sending any data to the
client?
We'll call that Option 3, which is a viable option if you cannot do Option 2
(store outside of webroot). The problems with this method is that if PHP
ever fails for any reason, the file may be delivered as plain text. It can
also be run out of context. For a db connection script, this could mean
that someone could program a bot to hit this script multiple times and use
up your database connections and slow things down. If the file runs normal
PHP code, depending upon how it's written, it could be run out of context
and perhaps generate useful errors to people profiling your application or
possibly show data that wasn't intended to be shown by itself (imagine an
.inc file that generates a table from the database that's normally protected
by surrounding PHP code, but now it can be run by itself).
Option 4 would be to place the files in an .htaccess protected directory.
Again, though, if Apache were to fail for any reason, the file could be
served as plain text. This option is also not portable to other web servers,
so that could be an issue.
---John Holmes...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security/Web tree/db connect and select
John W. Holmes mailto:[EMAIL PROTECTED] on Tuesday, June 01, 2004 8:29 AM said: We'll call that Option 3, which is a viable option if you cannot do Option 2 (store outside of webroot). The problems with this method is that if PHP ever fails for any reason, the file may be delivered as plain text. It can also be run out of context. [snip other useful info] yes this all makes sense. good to know John. thanks, chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security/Web tree/db connect and select
Dennis Seavers wrote:
Option 1: Include the mysql_connect and mysql_select_db
commands within the script that manipulates the data from
the database.
Option 2: Include the mysql_connect and mysql_select_db
commands (along with usernames and passwords) outside the
Web tree, but have the script run from within the Web tree.
The script would use a command like file() or file_get_contents()
to get the information from a text file outside the Web tree.
My belief is that Option 2 affords a higher level of security
than Option 1, but I wanted to make sure.
You're right. Option 2 offers more security in that no one will ever be
able to reach the file directly with a web browser. You don't need to
use file() or file_get_contents(), though... A simple
include('../includes/db.inc'); wil work (where ../ takes you outside of
the webroot and into an includes/ directory for the db.inc file). Or use
an absolute path include('/home/user/includes/db.inc'); where
/home/user/www/ is your webroot (for example).
--
---John Holmes...
Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/
php|architect: The Magazine for PHP Professionals www.phparch.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security on shared servers
From: Andy B [EMAIL PROTECTED] im writing this admin system for a website and need to have it write system logs to its own log files... the only problem i can really see is that its on a shared webserver and all files are restricted to your own domain/vhost dirs (whatever those happen to be). the admin wont let anybody put syslogs anywhere outside there vhost section of the server and .htaccess support is disabled and wont be able to be turned on (so i cant deny browser requests to a certain dir). anybody have any idea how i can protect the admin syslogs this program has to create (that way browsers cant download the logs)?? You don't have access to anything outside of the webroot? If /home/user/www/ is your webroot, then write them to /home/user/. If you're saying you can't do that and they have to be put under the webroot, then give them .php extensions and make the first line ?php exit(); ? Then they can't be viewed through the browser, but PHP can still read them (fopen, etc) or they can be opened with text editors. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security on shared servers
You don't have access to anything outside of the webroot? If /home/user/www/ is your webroot, then write them to /home/user/. If you're saying you can't do that and they have to be put under the webroot, then give them .php extensions and make the first line ?php exit(); ? Then they can't be viewed through the browser, but PHP can still read them (fopen, etc) or they can be opened with text editors. ---John Holmes... ok heres what i found out: the place where the admin service is supposed to go at doesnt have mysql/php high enough versions to run it so i had to temporarly move it (the admin service) to another site server with some people that i know... the server where the actual admin service will be running at doesnt have /home/user/www/ setup... instead it has public_html/ and a symlink to htdocs... since the server where it is supposed to be running at has /home/user/www access and there is an apache-access.log file outside of www i was just wondering if its possible to have error_log() or syslog() be able to write a log file on a different site or something like that -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security Question
On 20 February 2004 22:29, Ed Lazor wrote: PHP include statements default to the current directory. If the path to my PHP files is /home/osmosis/public_html, why would users visiting my site occasionally get an error that the include file wasn't found in /home/budguy/public_html? It's like PHP is somehow confused and running my script with the account settings (and permissions, possibly) for another user on my host provider's server. If that's true, wouldn't this quality as a security issue? They use open_basedir for security. Isn't that part of PHP? They're running the latest version of PHP (4.3.4). This looks like http://bugs.php.net/bug.php?id=25753 to me, which has only recently been marked as fixed and I don't believe has made it into an official release yet. Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security Question
Ed Lazor mailto:[EMAIL PROTECTED] on Friday, February 20, 2004 2:29 PM said: It's like PHP is somehow confused and running my script with the account settings (and permissions, possibly) for another user on my host provider's server. If that's true, wouldn't this quality as a security issue? not wanting to sound rude or anything, but have you emailed your host about this yet? chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security Question
You're not being rude. I contacted them immediately about the script errors and described what seemed to be a security hole. The tech I spoke with didn't know what I was talking about, so I asked them to notify the owner of the problem and that I'd research it more and let them know of anything I find. I received email shortly thereafter saying that they disabled open_basedir on the server in response. -Ed -Original Message- It's like PHP is somehow confused and running my script with the account settings (and permissions, possibly) for another user on my host provider's server. If that's true, wouldn't this quality as a security issue? not wanting to sound rude or anything, but have you emailed your host about this yet? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security issues
Hi Chris, First of all, thanks a lot for sharing your modus operandi with us. On 14 Jan 2004 at 7:32, Chris W wrote: I then verify that every character in the string is with in the ascii range of a space to the ~ which is basically all the characters on the key board. How exactly are you performing this check? Regular expression matching? If so, what regular expression are you using? Thanks, Erik -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security issues
[EMAIL PROTECTED] wrote:
Hi Chris,
First of all, thanks a lot for sharing your modus operandi with us.
On 14 Jan 2004 at 7:32, Chris W wrote:
I then verify that every character in the string is with in the ascii
range of a space to the ~ which is basically all the characters on the
key board.
How exactly are you performing this check? Regular expression matching? If so, what
regular expression are you using?
function validStr($s, $len)
{
if(strlen($s) $len){
return false;
}
for($i = 0;$i strlen($S);$i++){
if($s[$i] ' ' or $s[$i] '~'){
return false;
}
}
return true;
}
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Question
On Thu, 18 Dec 2003 10:43:14 -0500, you wrote: I'm trying to develop a secure web based application and my only tools are php, mysql, and a SSL connection. Does anyone know of any good references for this kind of development? What I really need to do is to make sure that given users only gain access to the parts of the application they are given rights to. I'm not sure if I need to pass their user information along from page to page or if I should set a cookie or whatever else would be appropriate. Read up about sessions. Essentially, a session is a random token which is sent to the client (normally as a cookie), and is associated with a collection of data server-side. You can safely store sensitive data (userids, privilege levels, etc) in the session because they never leave the server. http://www.php.net/manual/en/ref.session.php I also want people to be bounced back to the login page if they enter a direct URL to part of the application without logging in first, and I also want people to be able to log out. include() a file at the top of every page that checks for the existence of a valid session. If no session is present, use header(Location:) to bounce the user back to the login page and exit(). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security of php_auth_pw ?
If you want this type of level security, you should work under SSL connection, that works with crypted data between browser and server. Javier Tacón -Mensaje original- De: Neale Yates [mailto:[EMAIL PROTECTED] Enviado el: lunes, 15 de septiembre de 2003 7:47 Para: [EMAIL PROTECTED] Asunto: [PHP] Security of php_auth_pw ? Importancia: Baja Is anyone able to advise me on the security of the password when using PHP authentication. My specific concern is whether the password can be intercepted between the browser and server when submitted. thanks Neale -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security- ports, your comments will be appreciated
Nabil [EMAIL PROTECTED] wrote: I have an Linux server running Apache/PHP/MySQL. and I need to connect to another server running MSSQL server 7 THE POINT IS the only way I have to connect is throu ODBC connection because the network administrator only allowed me to connect thru port 1433 that ODBC uses.. I tried to make it direct connection, but this way uses many ports that the firewall won't allowed.. He said for security reasons that he can't open those ports to prevents hackers to use them ... do u think this is a true ? any advice what port the direct connection uses??? does it uses NetBIOS? MySql uses port 3306 by default. if he was right ... so I have to change to ODBC I heard about FreeDTS and iODBC, but I need some advice and notes to make it easy for me.. odbc does work with php although I'm not sure if there is a mysql odbc driver for unix, the discussion of configuring freetds or iODBC is a bit off topic here. Please HELP.. and your valuable comments will be appreciated.. Nabil Curt. -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security conundrum ....
Justin,
Tks for your reply -- you're partially correct in how it works, and thus
far I've not used session id's. Cool.
Login is built into the Flash movie and calls a PHP script to authenticate,
which returns appropriate success/fail data to the movie. Everything is
buried in the Flash movie to solve a serious pass-around problem we had
when using PDF's. If the Flash .swf file gets passed, then the login is the
first thing encountered. Passwords shared you say? we limit logins to a
fixed number per week.
I thought of sessions, but when I tried to set them in the authentication
script called from the .swf, the .swf gobbled them, they did not go to the
browser.
What I've done is call a script which opens a window, passing it the ckval
and issue date to display. It's only function is to start a session and
call a second window, which actually displays the story. That window closes
its parent. (Too much JavaScript for my liking.)
This scheme is only working on a test site now. If you want to, check out
http://www.allnovascotia.com/test_flash/feed_print_story.php , which a
person might do if they figured they will get the news for free, a rude
message appears. (Which will be changed for production, as we would rather
encourage, not discourage, potential subscribers.)
To see how this scheme works legally, have a look at
http://www.allnovascotia.com/test_flash/index.php?pgget=1
and login using flasher in all the boxes.
So it's not a PHP solution, I'm popping up an intermediate window and
closing it, which is ugly - flicker. And I've not been able to figure out
a way to have that intermediate window open at a small size -- everything
in JS seems to operate on children.
Regards - Miles Thompson
At 01:30 PM 6/23/2003 +1000, you wrote:
Ok, I'm trying to get a grip on what happens here:
1. i visit your site, see a flash movie, which enables me to log-in
2. after i log in, I see a link called news
3. I click on it, which pops open a HTML window through javascript, with a
URL like example.com/print_news.php
[At this point, the news page should only be available to authenticated
users, but it isn't -- right?]
The answer appears to be sessions. When you log in, you should be able to
pass a session ID back to the flash movie, along with the user's ckval
(whatever that is), and add a session variable like 'logged_in' to the
session.
When the flash movie uses javascript to pop open the news window, you should
be able to pass the session id as a GET variable in the URL, eg:
example.com/print_news.php?PHPSESSID=x
print_news.php needs to have this at the top:
?
session_start();
if($_SESSION['logged_in'])
{
?
html
...
Your news
...
/html
?
}
else
{
?
html
...
Sorry, you must be logged in baby!
...
/html
?
}
?
You don't NEED cookies to have session work... it can be done with URLs.
Justin
on 23/06/03 5:18 AM, Miles Thompson ([EMAIL PROTECTED]) wrote:
This does have to do with PHP, but bear with me.
We're using a Flash movie, which calls various PHP scripts to authenticate
users retrieve news articles, to display a daily business digest. As
Flash's printing capabilities are pathetic, we use JavaScript to popup a
chromeless window in which runs print_news.php. (This is a small window,
with selection, resizing, etc. all disabled, and which calls the print
dialog on load; all that is really visible is its Close button.)
It won't be too long before some bright spark realizes that our site could
be visited and the URL for print_news.php fed in; that person would then
have free access - not good.
What I planned to do is add authentication to print_news.php, by passing
the user's ckval (obtained when first authenticated by user_logon.php)
back to the browser in a session var. That does not work, as Flash
apparently gobbles the cookie.
The apparent alternative is to call an intermediate script from Flash,
passing the ckval, and having that script set the session and then redirect
to print_news.php, using the header( Location: ... ). The problem is that
opens in the same window, and I need a new one.
I obviously can't pass ckval in the URL, and I don't have any way, that I
know of, to fake a form POST.
Suggestions or nudges in the right direction will be appreciated.
Regards - Miles Thompson
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security conundrum ....
Ok, I'm trying to get a grip on what happens here:
1. i visit your site, see a flash movie, which enables me to log-in
2. after i log in, I see a link called news
3. I click on it, which pops open a HTML window through javascript, with a
URL like example.com/print_news.php
[At this point, the news page should only be available to authenticated
users, but it isn't -- right?]
The answer appears to be sessions. When you log in, you should be able to
pass a session ID back to the flash movie, along with the user's ckval
(whatever that is), and add a session variable like 'logged_in' to the
session.
When the flash movie uses javascript to pop open the news window, you should
be able to pass the session id as a GET variable in the URL, eg:
example.com/print_news.php?PHPSESSID=x
print_news.php needs to have this at the top:
?
session_start();
if($_SESSION['logged_in'])
{
?
html
...
Your news
...
/html
?
}
else
{
?
html
...
Sorry, you must be logged in baby!
...
/html
?
}
?
You don't NEED cookies to have session work... it can be done with URLs.
Justin
on 23/06/03 5:18 AM, Miles Thompson ([EMAIL PROTECTED]) wrote:
This does have to do with PHP, but bear with me.
We're using a Flash movie, which calls various PHP scripts to authenticate
users retrieve news articles, to display a daily business digest. As
Flash's printing capabilities are pathetic, we use JavaScript to popup a
chromeless window in which runs print_news.php. (This is a small window,
with selection, resizing, etc. all disabled, and which calls the print
dialog on load; all that is really visible is its Close button.)
It won't be too long before some bright spark realizes that our site could
be visited and the URL for print_news.php fed in; that person would then
have free access - not good.
What I planned to do is add authentication to print_news.php, by passing
the user's ckval (obtained when first authenticated by user_logon.php)
back to the browser in a session var. That does not work, as Flash
apparently gobbles the cookie.
The apparent alternative is to call an intermediate script from Flash,
passing the ckval, and having that script set the session and then redirect
to print_news.php, using the header( Location: ... ). The problem is that
opens in the same window, and I need a new one.
I obviously can't pass ckval in the URL, and I don't have any way, that I
know of, to fake a form POST.
Suggestions or nudges in the right direction will be appreciated.
Regards - Miles Thompson
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security flaw?
It should not be too difficult to change the delphi utility to post a sql or csv file to a php script, in the script you can check the sql commands and then execute them or parse the csv file respectively. The password is not really hidden, maybe it is not even scrambled in the binary, and can be seen by sniffing the connection anyway. Edward Peloke wrote: Hello all, As part of my website, I need to allow the users to upload data from an access db to my mysql db. This is all done with a small delphi utility by way of odbc. The problem is, my webhost will only allow me to have one user set up for the db so when I set up the odbc connection for the client (by way of an install), I have to set up the main username to the db and the main password. When I go back into odbc, the password appears to be hidden from the user but is it really? How can I give them access into this table without such a security risk? Thanks, Eddie -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security issues on shared servers
Thanks. Looks like a properly configured safe mode could eliminate a lot of problems. A few follow-up questions: 1. I see in the PHP doc comments a patch for Apache (http://luxik.cdi.cz/~devik/apache/) that runs different virtual hosts as different users. Anyone know anything about it, in terms of safety, effectiveness, stability, speed? 2. With safe mode enabled and all shell-access functions disabled through disabled_functions, it looks like most to all of problem (1) in my original email would be eliminated. But how do you specify the backtick operator in disabled_functions? --Dave On Tuesday, February 18, 2003, at 09:27 PM, Jason Sheets wrote: If your hosting provider has enabled safe mode then others can not include scripts that have a different uid than the owner of the current script, that prevents them from including your code. As far as the files go you could checksum them or if you are honestly concerned about them being changed store them in your database where only you have write access, the problem with that is that for your application to connect to your database it must know the db password, if the other users have shell access they can read your applications source code and connect to your db as your application. Bottom line, safe mode makes PHP a lot safer in multi user environments but you are always going to be exposed when you go with a multi user environment. Any programming language/application encounters these problems when introduced into a large multi user environment, switching programming languages would not alleviate these security issues. On Tue, 2003-02-18 at 15:49, David Feldman wrote: I run a PHP-based Web site hosted on a shared UNIX server provided by a pretty standard Web hosting company -- as I imagine do many people. There are a lot of users on this server, and I know nothing about them. Apache (and thus PHP) generally runs as www or nobody, so although each user on this shared server has a separate account, all PHP scripts run as the same user. As such, I have a few security concerns: 1. I restrict access to certain portions of my site, either with ..htaccess/.htpasswd files or with a PHP equivalent. This works fine for anyone using a Web browser, but it leaves a security hole: One can write a PHP script that circumvents the Apache access restrictions, either by calling a UNIX shell command (using passthru(), backticks, etc., only some of which are blocked on my server), or, more disturbingly, by using the include command. Using either of these methods in a publicly available page can circumvent htaccess- or PHP-based authorization and output the contents of a supposedly restricted file, _including_ a file in another user's Web site. 2. I am working on a PHP script that allows users to upload images, view them, and ultimately send them over email. All the problems listed in (1) apply, but in addition, these images' owner is www or nobody, the user PHP runs as. As such, not only could other users on the same shared server view these uploaded files, they could modify or delete them through a PHP script, and it doesn't matter what I set the access privileges to with chmod(), since they can call chmod() on the files themselves. Now, I can run a checksum at upload time and verify it later on to ensure that uploaded files haven't been changed. But that might still leave a few seconds (between upload and checksum) during which a file could be altered, and doesn't protect against deletions. Both (1) and (2) are disturbing to me, since if I'm protecting a portion of my site I don't want several hundred random people (whose only qualification is that they purchased Web space at the same company I did) to have access to it. Is there any way, short of a dedicated server or a wholesale switch to another server-side language, to avoid these problems? Thanks. --Dave -- -- -- David Feldman User Interface Designer -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security issues on shared servers
OK, my question #2 below is answered by the docs: Safe mode disabled the backtick operator. But having turned on safe mode on my local test server, I have another question: Suddenly my include statements that user relative paths don't work. For example: include /absolute/path/to/include/file.php; works fine, but include include/file.php doesn't. I don't see anything in the docs about this...what's going on? Thanks again, --Dave On Wednesday, February 19, 2003, at 08:03 AM, David Feldman wrote: Thanks. Looks like a properly configured safe mode could eliminate a lot of problems. A few follow-up questions: 1. I see in the PHP doc comments a patch for Apache (http://luxik.cdi.cz/~devik/apache/) that runs different virtual hosts as different users. Anyone know anything about it, in terms of safety, effectiveness, stability, speed? 2. With safe mode enabled and all shell-access functions disabled through disabled_functions, it looks like most to all of problem (1) in my original email would be eliminated. But how do you specify the backtick operator in disabled_functions? --Dave On Tuesday, February 18, 2003, at 09:27 PM, Jason Sheets wrote: If your hosting provider has enabled safe mode then others can not include scripts that have a different uid than the owner of the current script, that prevents them from including your code. As far as the files go you could checksum them or if you are honestly concerned about them being changed store them in your database where only you have write access, the problem with that is that for your application to connect to your database it must know the db password, if the other users have shell access they can read your applications source code and connect to your db as your application. Bottom line, safe mode makes PHP a lot safer in multi user environments but you are always going to be exposed when you go with a multi user environment. Any programming language/application encounters these problems when introduced into a large multi user environment, switching programming languages would not alleviate these security issues. On Tue, 2003-02-18 at 15:49, David Feldman wrote: I run a PHP-based Web site hosted on a shared UNIX server provided by a pretty standard Web hosting company -- as I imagine do many people. There are a lot of users on this server, and I know nothing about them. Apache (and thus PHP) generally runs as www or nobody, so although each user on this shared server has a separate account, all PHP scripts run as the same user. As such, I have a few security concerns: 1. I restrict access to certain portions of my site, either with ..htaccess/.htpasswd files or with a PHP equivalent. This works fine for anyone using a Web browser, but it leaves a security hole: One can write a PHP script that circumvents the Apache access restrictions, either by calling a UNIX shell command (using passthru(), backticks, etc., only some of which are blocked on my server), or, more disturbingly, by using the include command. Using either of these methods in a publicly available page can circumvent htaccess- or PHP-based authorization and output the contents of a supposedly restricted file, _including_ a file in another user's Web site. 2. I am working on a PHP script that allows users to upload images, view them, and ultimately send them over email. All the problems listed in (1) apply, but in addition, these images' owner is www or nobody, the user PHP runs as. As such, not only could other users on the same shared server view these uploaded files, they could modify or delete them through a PHP script, and it doesn't matter what I set the access privileges to with chmod(), since they can call chmod() on the files themselves. Now, I can run a checksum at upload time and verify it later on to ensure that uploaded files haven't been changed. But that might still leave a few seconds (between upload and checksum) during which a file could be altered, and doesn't protect against deletions. Both (1) and (2) are disturbing to me, since if I'm protecting a portion of my site I don't want several hundred random people (whose only qualification is that they purchased Web space at the same company I did) to have access to it. Is there any way, short of a dedicated server or a wholesale switch to another server-side language, to avoid these problems? Thanks. --Dave - --- -- David Feldman User Interface Designer -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security issues on shared servers
If your hosting provider has enabled safe mode then others can not include scripts that have a different uid than the owner of the current script, that prevents them from including your code. As far as the files go you could checksum them or if you are honestly concerned about them being changed store them in your database where only you have write access, the problem with that is that for your application to connect to your database it must know the db password, if the other users have shell access they can read your applications source code and connect to your db as your application. Bottom line, safe mode makes PHP a lot safer in multi user environments but you are always going to be exposed when you go with a multi user environment. Any programming language/application encounters these problems when introduced into a large multi user environment, switching programming languages would not alleviate these security issues. On Tue, 2003-02-18 at 15:49, David Feldman wrote: I run a PHP-based Web site hosted on a shared UNIX server provided by a pretty standard Web hosting company -- as I imagine do many people. There are a lot of users on this server, and I know nothing about them. Apache (and thus PHP) generally runs as www or nobody, so although each user on this shared server has a separate account, all PHP scripts run as the same user. As such, I have a few security concerns: 1. I restrict access to certain portions of my site, either with ..htaccess/.htpasswd files or with a PHP equivalent. This works fine for anyone using a Web browser, but it leaves a security hole: One can write a PHP script that circumvents the Apache access restrictions, either by calling a UNIX shell command (using passthru(), backticks, etc., only some of which are blocked on my server), or, more disturbingly, by using the include command. Using either of these methods in a publicly available page can circumvent htaccess- or PHP-based authorization and output the contents of a supposedly restricted file, _including_ a file in another user's Web site. 2. I am working on a PHP script that allows users to upload images, view them, and ultimately send them over email. All the problems listed in (1) apply, but in addition, these images' owner is www or nobody, the user PHP runs as. As such, not only could other users on the same shared server view these uploaded files, they could modify or delete them through a PHP script, and it doesn't matter what I set the access privileges to with chmod(), since they can call chmod() on the files themselves. Now, I can run a checksum at upload time and verify it later on to ensure that uploaded files haven't been changed. But that might still leave a few seconds (between upload and checksum) during which a file could be altered, and doesn't protect against deletions. Both (1) and (2) are disturbing to me, since if I'm protecting a portion of my site I don't want several hundred random people (whose only qualification is that they purchased Web space at the same company I did) to have access to it. Is there any way, short of a dedicated server or a wholesale switch to another server-side language, to avoid these problems? Thanks. --Dave -- David Feldman User Interface Designer -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] RE: PHP Security Advisory: CGI vulnerability in PHP version 4.3.0
Remove me from your list -Original Message- From: Jani Taskinen [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 12:01 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: PHP Security Advisory: CGI vulnerability in PHP version 4.3.0 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 PHP Security Advisory: CGI vulnerability in PHP version 4.3.0 Issued on: February 17, 2003 Software: PHP/CGI version 4.3.0 Platforms: All The PHP Group has learned of a serious security vulnerability in the CGI SAPI of PHP version 4.3.0. Description PHP contains code for preventing direct access to the CGI binary with configure option --enable-force-cgi-redirect and php.ini option cgi.force_redirect. In PHP 4.3.0 there is a bug which renders these options useless. NOTE: This bug does NOT affect any of the other SAPI modules. (such as the Apache or ISAPI modules, etc.) Impact Anyone with access to websites hosted on a web server which employs the CGI module may exploit this vulnerability to gain access to any file readable by the user under which the webserver runs. A remote attacker could also trick PHP into executing arbitrary PHP code if attacker is able to inject the code into files accessible by the CGI. This could be for example the web server access-logs. Solution The PHP Group has released a new PHP version, 4.3.1, which incorporates a fix for the vulnerability. All users of affected PHP versions are encouraged to upgrade to this latest version. The downloads web site at http://www.php.net/downloads.php has the new 4.3.1 source tarballs, Windows binaries and source patch from 4.3.0 available for download. You will only need to upgrade if you're using the CGI module of PHP 4.3.0. There are no other bugfixes contained in this release. Workaround None. Credits The PHP Group would like to thank Kosmas Skiadopoulos for discovering this vulnerability. Copyright (c) 2003 The PHP Group. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+USOr/HlsOzK2WlERAtLKAJ9GPbPt6Vg77zIcPTGKh78WofmmeACgneDV tUERfwp/RXtcH13vdv0CGGY= =rYm5 -END PGP SIGNATURE- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PHP-DEV] RE: PHP Security Advisory: CGI vulnerability in PHPversion 4.3.0
On Mon, 17 Feb 2003, McKinney, Rod ERM wrote: Remove me from your list See the footer of this email: -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php Derick -- Stop mad cowboy disease! - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security question with PHP on Unix / Linux.
Ananth Kesari [EMAIL PROTECTED] wrote... : Thanks for your inputs. Will proceed from here. Well, if you did not know, NetWare is an operating system brought out by Novell. I know :) We are working on porting PHP onto NetWare. In fact, we already have ported PHP 4.2.3 onto NetWare and we have synched up our souces for the 4.3 branch. Interesting. Are you working with the php-dev team or on your own? -- Maxim Maletsky [EMAIL PROTECTED] Maxim Maletsky [EMAIL PROTECTED] 02/04/03 08:45PM Ananth Kesari [EMAIL PROTECTED] wrote... : I am working on porting PHP onto NetWare. What exactly do you mean? I am newbie to Unix / Linux systems and at this point of time, I am trying to understand the way security is implemented for PHP on Unix / Linux. I mean, how are the different users distinguished from Unix / Linux. From PHP's point of view, every PHP process will run as apache's process, with apache's user. Most often `nobody' or `apache'. Do they get to login into the Unix / Linux system? No. Do they have separate data space for each user? No. Only sessions, if you use them. Sessions have their own unique IDs and are stored in a certain directory by default. A database solution can also be implemented. What is the API that is used to login to Unix / Linux. There is no login to the Unix / Linux. You might write one on your own, if you wish, but that would be your thing. PHP as it is, logs nobody to the Linux, it runs everybody's request as Apache's user. User may enter his username and password on the browser, but how do they get translated onto the Unix / Linux box? Whatever inputted to the broswer, is send to your script. Stays up to you to decide what to do with the user/pass. Basically, you would usually store the credentials in a database and then authenticate the users against the database, not Linux Shell itself. Since I am a newbie, I may have misunderstood some concepts here. Most of them. PHP is a programming language, not a shell interface or something. Stays up to you what to do once user runs your PHP script. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security question with PHP on Unix / Linux.
Ananth Kesari [EMAIL PROTECTED] wrote... : I am working on porting PHP onto NetWare. What exactly do you mean? I am newbie to Unix / Linux systems and at this point of time, I am trying to understand the way security is implemented for PHP on Unix / Linux. I mean, how are the different users distinguished from Unix / Linux. From PHP's point of view, every PHP process will run as apache's process, with apache's user. Most often `nobody' or `apache'. Do they get to login into the Unix / Linux system? No. Do they have separate data space for each user? No. Only sessions, if you use them. Sessions have their own unique IDs and are stored in a certain directory by default. A database solution can also be implemented. What is the API that is used to login to Unix / Linux. There is no login to the Unix / Linux. You might write one on your own, if you wish, but that would be your thing. PHP as it is, logs nobody to the Linux, it runs everybody's request as Apache's user. User may enter his username and password on the browser, but how do they get translated onto the Unix / Linux box? Whatever inputted to the broswer, is send to your script. Stays up to you to decide what to do with the user/pass. Basically, you would usually store the credentials in a database and then authenticate the users against the database, not Linux Shell itself. Since I am a newbie, I may have misunderstood some concepts here. Most of them. PHP is a programming language, not a shell interface or something. Stays up to you what to do once user runs your PHP script. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security question with PHP on Unix / Linux.
Ananth, For starters, you are probably on the wrong list - the PHP developers list is probably where you should be asking this question. Second, PHP runs through the web server, so the user is the same user the web server, usually nobody, although that depends on the how the web server is installed. No one is encouraged to all access to the underlying system through the web server, although the exec() function allows execution of some commands. I can't help you much more than that, and I believe the other list will be more fruitful. Regards - Miles Thompson At 07:54 AM 2/4/2003 -0700, Ananth Kesari wrote: Hi, I mailed this earlier, but got no response. Maybe it went unnoticed. So, resending it again. Please read below. Your help in this is appreciated. Thanks, Ananth. Hi, I am working on porting PHP onto NetWare. I am newbie to Unix / Linux systems and at this point of time, I am trying to understand the way security is implemented for PHP on Unix / Linux. I mean, how are the different users distinguished from Unix / Linux. Do they get to login into the Unix / Linux system? Do they have separate data space for each user? What is the API that is used to login to Unix / Linux. User may enter his username and password on the browser, but how do they get translated onto the Unix / Linux box? Since I am a newbie, I may have misunderstood some concepts here. Can someone help me in understanding this correctly? Also, can you point me to any documentation on PHP security on Unix systems. I want some in-depth technical stuff upto what calls are made etc. Your help in this is appreciated. Thanks, Ananth. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security question with PHP on Unix / Linux.
--- Miles Thompson [EMAIL PROTECTED] wrote: Ananth, For starters, you are probably on the wrong list - the PHP developers list is probably where you should be asking this question. Please do not go around saying this. We have enough problems with these types of posts winding up on php-dev as it is. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security question with PHP on Unix / Linux.
Thanks for your inputs. Will proceed from here. Well, if you did not know, NetWare is an operating system brought out by Novell. We are working on porting PHP onto NetWare. In fact, we already have ported PHP 4.2.3 onto NetWare and we have synched up our souces for the 4.3 branch. Thanks, Ananth. Maxim Maletsky [EMAIL PROTECTED] 02/04/03 08:45PM Ananth Kesari [EMAIL PROTECTED] wrote... : I am working on porting PHP onto NetWare. What exactly do you mean? I am newbie to Unix / Linux systems and at this point of time, I am trying to understand the way security is implemented for PHP on Unix / Linux. I mean, how are the different users distinguished from Unix / Linux. From PHP's point of view, every PHP process will run as apache's process, with apache's user. Most often `nobody' or `apache'. Do they get to login into the Unix / Linux system? No. Do they have separate data space for each user? No. Only sessions, if you use them. Sessions have their own unique IDs and are stored in a certain directory by default. A database solution can also be implemented. What is the API that is used to login to Unix / Linux. There is no login to the Unix / Linux. You might write one on your own, if you wish, but that would be your thing. PHP as it is, logs nobody to the Linux, it runs everybody's request as Apache's user. User may enter his username and password on the browser, but how do they get translated onto the Unix / Linux box? Whatever inputted to the broswer, is send to your script. Stays up to you to decide what to do with the user/pass. Basically, you would usually store the credentials in a database and then authenticate the users against the database, not Linux Shell itself. Since I am a newbie, I may have misunderstood some concepts here. Most of them. PHP is a programming language, not a shell interface or something. Stays up to you what to do once user runs your PHP script. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security question with PHP on Unix / Linux.
Thanks for your inputs. Will proceed from here. Well, I first posted this query on this list. But seeing no response, I thought probably it should have gone into PHP-dev list. When I posted there, I was discouraged to post such mails there. So, I came back to the general list. Thanks, Ananth. Miles Thompson [EMAIL PROTECTED] 02/04/03 08:32PM Ananth, For starters, you are probably on the wrong list - the PHP developers list is probably where you should be asking this question. Second, PHP runs through the web server, so the user is the same user the web server, usually nobody, although that depends on the how the web server is installed. No one is encouraged to all access to the underlying system through the web server, although the exec() function allows execution of some commands. I can't help you much more than that, and I believe the other list will be more fruitful. Regards - Miles Thompson At 07:54 AM 2/4/2003 -0700, Ananth Kesari wrote: Hi, I mailed this earlier, but got no response. Maybe it went unnoticed. So, resending it again. Please read below. Your help in this is appreciated. Thanks, Ananth. Hi, I am working on porting PHP onto NetWare. I am newbie to Unix / Linux systems and at this point of time, I am trying to understand the way security is implemented for PHP on Unix / Linux. I mean, how are the different users distinguished from Unix / Linux. Do they get to login into the Unix / Linux system? Do they have separate data space for each user? What is the API that is used to login to Unix / Linux. User may enter his username and password on the browser, but how do they get translated onto the Unix / Linux box? Since I am a newbie, I may have misunderstood some concepts here. Can someone help me in understanding this correctly? Also, can you point me to any documentation on PHP security on Unix systems. I want some in-depth technical stuff upto what calls are made etc. Your help in this is appreciated. Thanks, Ananth. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security question regarding including files..
I guess you use some webserver, let's take apache. Apache's mime.conf has set several extensions, also php extensions. So only .php, .php3, .php4 files will be parsed by php. Chad Day wrote: I want to give my users the ability to submit a URL to a database, then when they pull up their page, their photo is included .. what I'm worried about is them pointing the link to some malicious code or something.. Obviously I can validate the file extension (.gif or .jpg) .. and I'm going to force the files to be stored offsite - they dont get to upload anything to the server. I'm just a bit paranoid about this, so I'm hoping someone more security-minded can tell me what to watch out for, what to check, if I'm missing anything.. Thanks, Chad -- IPv6 + TCPA + wrecked Palladium server = NO COFFE! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security question regarding including files..
--- Chad Day [EMAIL PROTECTED] wrote: I want to give my users the ability to submit a URL to a database, then when they pull up their page, their photo is included .. what I'm worried about is them pointing the link to some malicious code or something.. Your instincts serve you well. There are two types of attacks to worry about in this situation, depending on who can see this image. If only the user who submitted the URL can see it, then your users only risk CSRF attacks, which are not very common (yet) but are very dangerous. If everyone can see the image, then your application is also at risk of XSS. If you realize that an embedded image is requested separately by a Web client, you can see that this basically allows an attacker the opportunity of forcing another user to visit a URL of the attacker's choice. For example, consider an image that looks like this: img src=http://bookstore.xxx/buy.php?book=httphandbook; A browser will try to load that image by sending a request for that URL to bookstore.xxx. So, every user who happens to have a prior relationship with bookstore.xxx (maybe they have one-click ordering) will unknowingly purchase HTTP Developer's Handbook. All the victim will see is a broken image. Even if you check for file extensions, the attacker can have a URL that looks legitimate but is really a PHP script in disguise (their Apache treates .jpg as PHP, for example) and uses header(Location: ...) to redirect to the URL mentioned above. Also, this same attack can be used against one of your users to make them unknowingly submit such a URL to your site. Thus, even if you only show the image to the user who submitted it, that user may still be a victim. For more information on CSRF, check out http://www.tux.org/~peterw/csrf.txt. For more information on XSS, check out http://httpd.apache.org/info/css-security/ and http://www.cert.org/advisories/CA-2000-02.html. My advice would be to require human intervention in the way of a moderation system. Even with this, a URL that returns an image today may not tomorrow. A safer alternative might be to host the images yourself, so that you can check that they are in fact images. Good luck. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security question regarding including files..
Chris Shiflett wrote: --- Chad Day [EMAIL PROTECTED] wrote: I want to give my users the ability to submit a URL to a database, then when they pull up their page, their photo is included .. what I'm worried about is them pointing the link to some malicious code or something.. Your instincts serve you well. There are two types of attacks to worry about in this situation, depending on who can see this image. If only the user who submitted the URL can see it, then your users only risk CSRF attacks, which are not very common (yet) but are very dangerous. If everyone can see the image, then your application is also at risk of XSS. If you realize that an embedded image is requested separately by a Web client, you can see that this basically allows an attacker the opportunity of forcing another user to visit a URL of the attacker's choice. For example, consider an image that looks like this: img src=http://bookstore.xxx/buy.php?book=httphandbook; I agree that there are risks - but I do think this can be done safely if you make sure the user cannot insert javascript into the page, there isn't much cross site scripting that can be done. and make sure they can't insert quotes which would end the quoted string in the html page. is there really any site which will accept a book order based an a sigle GET ? I guess stripping the query string would be safest... but its a balance betwwen security and functionality ... -- Sean -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security question regarding including files..
On Wednesday 22 January 2003 01:40, Sean Burlington wrote: is there really any site which will accept a book order based an a sigle GET ? Amazon makes a big deal of their one-click shopping feature. It's so good they've even patented it. -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * /* We are drowning in information but starved for knowledge. -- John Naisbitt, Megatrends */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security question regarding including files..
Gibbs, Liam - SXIA wrote: I agree that there are risks - but I do think this can be done safely Couldn't you just check the submitted URL and find out if it's a gif or jpeg? I don't think even PHP-enabled servers will run a gif or jpeg. please send replies to the list ... and you cant tell what type of file will be returned by the url it is easy to set up a server to treat a file named foo.gif as a php file (or whatever) even if you tested the url by attemting to download the file it would be easy to write a script that would return an innocent gif to requests originating for the webservers ip address - and anything else to the rest of the world. I'm not sure what harm could be done by this though. if a broswer attempts to load an image reference by an img tag - but finds an unsuitable type of data - I would expect it simply to ignore it... but this would be worth testing. -- Sean -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security question regarding including files..
--- Sean Burlington [EMAIL PROTECTED] wrote: I'm not sure what harm could be done by this though. if a broswer attempts to load an image reference by an img tag - but finds an unsuitable type of data - I would expect it simply to ignore it... I sent a response about this earlier, but you should research CSRF and XSS. It does not matter that the browser shows a broken image if it has already sent the HTTP request. There is no special HTTP request for checking whether the Content-Type is really an image without the receiving Web server taking any action. A GET is a GET. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security question regarding including files..
--- Sean Burlington [EMAIL PROTECTED] wrote: is there really any site which will accept a book order based an a sigle GET? Well, yes, but that is not the point really. The example of the img tag is just one way you can forge an HTTP request from another user (the victim). Also consider that many people create sites with PHP with register_globals set to on. Even when these people go to great lengths to validate all incoming data and to identify the user, this does not defend against CSRF. The data being sent is valid data, and the user sending it is the authenticated user. That is the danger. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security question regarding including files..
Chris Shiflett wrote: --- Sean Burlington [EMAIL PROTECTED] wrote: I'm not sure what harm could be done by this though. if a broswer attempts to load an image reference by an img tag - but finds an unsuitable type of data - I would expect it simply to ignore it... I sent a response about this earlier, but you should research CSRF and XSS. It does not matter that the browser shows a broken image if it has already sent the HTTP request. There is no special HTTP request for checking whether the Content-Type is really an image without the receiving Web server taking any action. A GET is a GET. hmmm but what does this have to do with the site allowing users to include links to images this is a security problem for the site that allows you to place purchase orders with a single click. what difference does it make that img links are placed by users ? I could just as easily trick users into making GET requests by puting dodgy img links in a pgae that I control ... I only initiate a small proportion of the requests my browser makes - in fact I go to some trouble to stop some of the requests happening as I don't like to see so many ads - I filter outgoing requests via squid. There are problems in the way the internet is designed and in misconcepotions as to how it works - but if we all code for absolute security we end up disconnecting from the web entirely. -- Sean -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security
--- Phil Ewington [EMAIL PROTECTED] wrote: Can PHP be configured to allow certain web sites access to files and directories within their web root only? I would suggest looking into safe mode. It sounds like it may work for you: http://www.php.net/manual/en/features.safe-mode.php Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security in included PHP files
True. But let's just call me anal retentive. :-) Let's say I didn't have the option of doing what you suggested. Are my ideas sound? Also, those ideas apply to top-level PHP scripts in an application. Jacob Kevin Stone [EMAIL PROTECTED] wrote in message 007801c2bcd4$02d000f0$6601a8c0@kevin">news:007801c2bcd4$02d000f0$6601a8c0@kevin... Most web accounts have at least one or two directory levels behind the public directory. Simply place the files behind the public directory and call them into your main script from there. Absolutely no reason those files need to be publically accessible. -Kevin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security in included PHP files
--- Jacob Copsey [EMAIL PROTECTED] wrote: My style of PHP is to name all included files with a .php extension and of course this raises the problem of people accessing these script files directly. I always name included files *.inc myself, but that's a personal preference combined with a strong desire to adhere to strict naming conventions. It is very easy to make sure people cannot access your include files directly. There are two common ways to do this, and I will mention my preference first. 1. Do not store your include files under document root. This is a very simple and straightforward approach that negates all of the types of questions you were asking. 2. Deny access to any file with an extension of inc. Of course, you would have to conform to a naming standard a bit more for this to work. A quick Google search revealed this example for Apache: Files ~ \.inc$ Order Allow, Deny Deny from all /Files Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security in included PHP files
I agree these are good solutions and I have considered them. However, I am looking for an all-inclusive solution that is code only within PHP that allows the admin of the application to copy the files to their server and not need to do any server specific configuration. That is why I don't name the included files with .inc. It would require configuration of the server to prevent downloading of those files and I don't want to require that step of people who choose to run the app on their server. Thanks for the input! Jacob Chris Shiflett [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... --- Jacob Copsey [EMAIL PROTECTED] wrote: My style of PHP is to name all included files with a .php extension and of course this raises the problem of people accessing these script files directly. I always name included files *.inc myself, but that's a personal preference combined with a strong desire to adhere to strict naming conventions. It is very easy to make sure people cannot access your include files directly. There are two common ways to do this, and I will mention my preference first. 1. Do not store your include files under document root. This is a very simple and straightforward approach that negates all of the types of questions you were asking. 2. Deny access to any file with an extension of inc. Of course, you would have to conform to a naming standard a bit more for this to work. A quick Google search revealed this example for Apache: Files ~ \.inc$ Order Allow, Deny Deny from all /Files Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security in included PHP files
Have you thought about moving your include files outside of the web directory? i.e.If your site is in ../apache/htdocs/web/mywbsite_folder then move your include files to ../apache/my_include_folder/ or something similar. -john =P e p i e D e s i g n s www.pepiedesigns.com Providing Solutions That Increase Productivity Web Developement. Database. Hosting. Multimedia. On Wed, 15 Jan 2003, Jacob Copsey wrote: I am beginning work on a new web-based application using PHP and MySQL. I have been doing a lot of reading about PHP security and web application security in general to make sure I am up-to-date on what is known in this area. My style of PHP is to name all included files with a .php extension and of course this raises the problem of people accessing these script files directly. My main question is if all of the code inside an included PHP file is put inside one or more functions this should prevent anyone from running any of that code by directly calling that PHP file correct? There is no way for them to invoke a function just from a URL assuming I have no code at all outside the functions. And this leads to another question... if I encapsulate most of my variables inside one or more classes doesn't this help protect against attacks also? Is there a way for someone to set a class variable to a value just from a GET or POST request (or even file or cookie)? As long as I am carefully validating what information I put into the object variable this seems to be a way of adding another layer of protection. Any thoughts or comments regarding this and any other issues I should take into consideration regarding security are welcome. Jacob -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security in included PHP files
--- Jacob Copsey [EMAIL PROTECTED] wrote: I agree these are good solutions and I have considered them. However, I am looking for an all-inclusive solution that is code only within PHP that allows the admin of the application to copy the files to their server and not need to do any server specific configuration. This places a large restriction on your ability to provide the best solution. However, there are still a couple of things you might consider, though I'm not sure if you will be fond of them: 1. Force those who install your software to place include files outside of document root. I know a few applications that check this and will output an error with a brief description of the security hazard if the include files are found to be under document root. This way, you can be assured that by the time people get your application to work, the include files will no longer be under document root. A similar notion is to combine this with a Web-based installation program, where your application relocates the include files during installation. 2. If your users are using Apache, you can include a .htaccess file in the top-level directory of your application that denies access to *.inc files. Maybe something like that will work for you. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security in included PHP files
You already have your solution in your original question, then. If you don't want to use any of these other techniques, then name your files with a .php extension (I use .inc.php) and enclose everything in classes or function. If you're just aware that your included files can be run out of context, and program accordingly, your scripts will be just fine. An include file full of functions or classes will not run anything when called, it'll simply load it into memory. ---John W. Holmes... PHP Architect - A monthly magazine for PHP Professionals. Get your copy today. http://www.phparch.com/ -Original Message- From: Jacob Copsey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 3:53 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Security in included PHP files I agree these are good solutions and I have considered them. However, I am looking for an all-inclusive solution that is code only within PHP that allows the admin of the application to copy the files to their server and not need to do any server specific configuration. That is why I don't name the included files with .inc. It would require configuration of the server to prevent downloading of those files and I don't want to require that step of people who choose to run the app on their server. Thanks for the input! Jacob Chris Shiflett [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... --- Jacob Copsey [EMAIL PROTECTED] wrote: My style of PHP is to name all included files with a .php extension and of course this raises the problem of people accessing these script files directly. I always name included files *.inc myself, but that's a personal preference combined with a strong desire to adhere to strict naming conventions. It is very easy to make sure people cannot access your include files directly. There are two common ways to do this, and I will mention my preference first. 1. Do not store your include files under document root. This is a very simple and straightforward approach that negates all of the types of questions you were asking. 2. Deny access to any file with an extension of inc. Of course, you would have to conform to a naming standard a bit more for this to work. A quick Google search revealed this example for Apache: Files ~ \.inc$ Order Allow, Deny Deny from all /Files Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security in included PHP files
I am beginning work on a new web-based application using PHP and MySQL. I have been doing a lot of reading about PHP security and web application security in general to make sure I am up-to-date on what is known in this area. My style of PHP is to name all included files with a .php extension and of course this raises the problem of people accessing these script files directly. My main question is if all of the code inside an included PHP file is put inside one or more functions this should prevent anyone from running any of that code by directly calling that PHP file correct? There is no way for them to invoke a function just from a URL assuming I have no code at all outside the functions. No, the user can't run anything; it'll simply load the code into memory. And this leads to another question... if I encapsulate most of my variables inside one or more classes doesn't this help protect against attacks also? Is there a way for someone to set a class variable to a value just from a GET or POST request (or even file or cookie)? As long as I am carefully validating what information I put into the object variable this seems to be a way of adding another layer of protection. No, the user can't set a class variable directly, but if you are doing something like $this-var = $_GET['something'], then it's unsecure unless you are validating $_GET['something'] first. ---John W. Holmes... PHP Architect - A monthly magazine for PHP Professionals. Get your copy today. http://www.phparch.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security in included PHP files
Great! I was just looking for confirmation that my assumptions in my original post were correct. I have been using PHP for quite some time but have never read a specific article about possible attacks that allow modification of values in a class object or execution of functions in a PHP script. It is rarely safe to assume things when it comes to security so I figured I would ask. Thanks again for responding. --Jacob John W. Holmes [EMAIL PROTECTED] wrote in message 003801c2bd13$01fc85b0$7c02a8c0@coconut">news:003801c2bd13$01fc85b0$7c02a8c0@coconut... You already have your solution in your original question, then. If you don't want to use any of these other techniques, then name your files with a .php extension (I use .inc.php) and enclose everything in classes or function. If you're just aware that your included files can be run out of context, and program accordingly, your scripts will be just fine. An include file full of functions or classes will not run anything when called, it'll simply load it into memory. ---John W. Holmes... PHP Architect - A monthly magazine for PHP Professionals. Get your copy today. http://www.phparch.com/ -Original Message- From: Jacob Copsey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 3:53 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Security in included PHP files I agree these are good solutions and I have considered them. However, I am looking for an all-inclusive solution that is code only within PHP that allows the admin of the application to copy the files to their server and not need to do any server specific configuration. That is why I don't name the included files with .inc. It would require configuration of the server to prevent downloading of those files and I don't want to require that step of people who choose to run the app on their server. Thanks for the input! Jacob Chris Shiflett [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... --- Jacob Copsey [EMAIL PROTECTED] wrote: My style of PHP is to name all included files with a .php extension and of course this raises the problem of people accessing these script files directly. I always name included files *.inc myself, but that's a personal preference combined with a strong desire to adhere to strict naming conventions. It is very easy to make sure people cannot access your include files directly. There are two common ways to do this, and I will mention my preference first. 1. Do not store your include files under document root. This is a very simple and straightforward approach that negates all of the types of questions you were asking. 2. Deny access to any file with an extension of inc. Of course, you would have to conform to a naming standard a bit more for this to work. A quick Google search revealed this example for Apache: Files ~ \.inc$ Order Allow, Deny Deny from all /Files Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security in guest book and user forums
On Sunday 05 January 2003 01:16, Anders Thoresson wrote: I've seen both guest books and user forums hacked by users who enter javascript or other code, and that way redirects vistors to other sites or do other unwelcome things. What expressions should I look for and not allow in my forms? Disallow all HTML tags by using strip_tags(). -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * /* A dirty mind is a joy forever. -- Randy Kunkee */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security in guest book and user forums
on 05/01/03 4:16 AM, Anders Thoresson ([EMAIL PROTECTED]) wrote: I've seen both guest books and user forums hacked by users who enter javascript or other code, and that way redirects vistors to other sites or do other unwelcome things. What expressions should I look for and not allow in my forms? Personally, I'd disallow ALL HTML tags. Why? Best two reasons I have are: - someone might open a b tag, and never close it, making your whole page bold, or a link, or whatever - someone could do something evil with javascript or any other onmouseover/click type event, like b onmouseover=javascript:window.close(); (can't remember exact syntax) Just use striptags() (or is it strip_tags()?) on the entire contents of all your form's text elements, giving you clean text. If you wanted to bring back simple formatting (say, B,I,BR), you could implement 'BBtags', basically using [ and ] instead of and : Hello, [b]this bit is in bold[/b][br][i]and this in italics on a new line[/i]. Then you can specifically search and replace those tags using str_replace() or eregi_replace() or preg_replace(). Personally, I believe they don't have the right to get such amazing access to your site... everyone who you don't know shouldn't be trusted to provide decent content, or write decent HTML. Cheers, Justin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security of stand alone script
Hi gamin, Running Red Hat 7.2, PHP 4.0.6. Is there any way of knowing if a certain PHP script was run from the command line, shell script or through the webserver (Apache). May be i could check the user calling the script and find out but how would i do that ? There is a difference in the way argc and argv are managed - see manual. Also (do two phpinfo() runs to check - one under Apache and one from the command line) depending upon the web server (Apache in our cases) there are whole sections of the 'standard output' that do not have relevance from the command line (because there is no web server!), eg SERVER_SOFTWARE and SERVER_SIGNATURE. Should you figure out something better than this, please let me know too! Regards, =dn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security - Maybe a silly question
Hello, SED [EMAIL PROTECTED] wrote: When I use sessions in PHP or just plain login/password in $_POST, can 3rd parties or hackers monitor the transmission, between me and user, and somehow decode the transmission and use the variables to login other time or overtake the current session? Yes. (But, I'm not really sure what you meant by between me and user...) If so, how likely is for someone to manage it (get the username/password)? By sniffing. - E -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security - Maybe a silly question
Yes, Between user and server, everydata pass through DNS, routeur, etc... So if you don't want someone (hackers or FBI of CIA) to decode your data, use SSL server (https://) with certificate- - Original Message - From: SED [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 02, 2002 8:37 AM Subject: [PHP] Security - Maybe a silly question When I use sessions in PHP or just plain login/password in $_POST, can 3rd parties or hackers monitor the transmission, between me and user, and somehow decode the transmission and use the variables to login other time or overtake the current session? If so, how likely is for someone to manage it (get the username/password)? Regards, Sumarlidi E. Dadason SED - Graphic Design _ Tel: +354-896-0376, +354-461-5501 E-mail: [EMAIL PROTECTED] website: www.sed.is -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security - Maybe a silly question
Thank you for the reply, what do you mean by sniffing, do you mean everbody can monitor our browsing? -Original Message- From: @ Edwin [mailto:copperwalls;hotmail.com] Sent: 1. nóvember 2002 21:47 To: SED Cc: [EMAIL PROTECTED] Subject: Re: [PHP] Security - Maybe a silly question Hello, SED [EMAIL PROTECTED] wrote: When I use sessions in PHP or just plain login/password in $_POST, can 3rd parties or hackers monitor the transmission, between me and user, and somehow decode the transmission and use the variables to login other time or overtake the current session? Yes. (But, I'm not really sure what you meant by between me and user...) If so, how likely is for someone to manage it (get the username/password)? By sniffing. - E -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security - Maybe a silly question
I'm not very familiar to this stuff, but if I wanna use https:// do don't I need a key from Verisign (or similar) to make it work? If so, who control who is what on the internet? Regards, Sumarlidi E. Dadason SED - Graphic Design _ Tel: 896-0376, 461-5501 E-mail: [EMAIL PROTECTED] website: www.sed.is -Original Message- From: rija [mailto:rija;vatu.com] Sent: 1. nóvember 2002 22:33 To: php; SED Subject: Re: [PHP] Security - Maybe a silly question Yes, Between user and server, everydata pass through DNS, routeur, etc... So if you don't want someone (hackers or FBI of CIA) to decode your data, use SSL server (https://) with certificate- - Original Message - From: SED [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 02, 2002 8:37 AM Subject: [PHP] Security - Maybe a silly question When I use sessions in PHP or just plain login/password in $_POST, can 3rd parties or hackers monitor the transmission, between me and user, and somehow decode the transmission and use the variables to login other time or overtake the current session? If so, how likely is for someone to manage it (get the username/password)? Regards, Sumarlidi E. Dadason SED - Graphic Design _ Tel: +354-896-0376, +354-461-5501 E-mail: [EMAIL PROTECTED] website: www.sed.is -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security - Maybe a silly question
Hello SED, SED [EMAIL PROTECTED] wrote: Thank you for the reply, what do you mean by sniffing, do you mean everbody can monitor our browsing? I'm not really sure how I can answer your question but let me just put it this way. Everybody CAN monitor our browsing but: 1. That doesn't mean everybody WILL. 2. That doesn't mean they'll use sniffing. Regarding sniffing, I think it'd be better if your research it yourself. Google for it and use sniffing as your keyword--you'll be surprised with the results. I'm sure you can find more info there than if I try to explain it here. - E -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security - Maybe a silly question
SED [EMAIL PROTECTED] wrote: I'm not very familiar to this stuff, but if I wanna use https:// do don't I need a key from Verisign (or similar) to make it work? Yes and no. If you're going to use it on a production server, yes. If it's on a test server but you still want to be somehow protected, then, no--no you don't need a key from Verisign or others. If so, who control who is what on the internet? That's a tricky question. Perhaps, you need to be more specific. But, I'm afraid the question would be a bit OT... - E -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security - Maybe a silly question
SED wrote: When I use sessions in PHP or just plain login/password in $_POST, can 3rd parties or hackers monitor the transmission, between me and user, and somehow decode the transmission and use the variables to login other time or overtake the current session? If so, how likely is for someone to manage it (get the username/password)? I've read some of the responses to your question, and I think I can possibly help to clarify some things ... To answer your question directly, yes it is possible for people (hacker != computer criminal, by the way) to observe the transmission, but it is not very likely. Also, if someone successfully observes a user's HTTP request, they will have access to the user's data whether it is being sent via get, post, or cookies. There is no decoding necessary. However, though this is not too terribly difficult to accomplish, it is a lot harder than some people will lead you to believe. If you are worried about the security of your users, here are some things to consider in that regard: 1. For anyone to observe a specific transaction, they must have access to a machine that is between you (the Web server) and them (the Web client). For someone to reliably do this, they would need to have access to a machine along the path that is either very near the Web client (for targetting a specific user) or very near your Web site (for targetting a specific site, yours). Anything in between would likely have too much traffic. Needless to say, this scenario is unlikely. An example of such a thing would be perhaps if a curious systems administrator were observing outgoing traffic on a gateway that served a small office. If someone who worked in that office interacted with your Web site, it would be quite easy for the administrator to observe the transaction. 2. There are much easier ways to impersonate a user. PHP, by default, uses a single cookie to identify the Web client. Imagine if someone were to steal a cookie belonging to one of your users and then visit your site presenting the same cookie. You would mistake them for your user, right? Most attacks focus on the application itself, just like this example, because this is the usually the easiest thing to do. All versions of Internet Explorer from 4.0 to 6.0 have cookie vulnerabilities that allow any Web site to view any other Web site's cookies. So, if some of your users are IE users (very likely) and have not patched their browsers (also very likely), that cookie you use to identify them is in danger. In general, security is a balance. There is always going to be a risk. The harder you make it for the bad guys, the less risk you have, but also (usually) the less accomodating you are to your legitimate users - shorter timeouts, requiring frequent reauthentication, extra data validation, etc. The easier it is for the bad guys, the higher the risk, but the more accomodating you can be to your users - longer timeouts, automatic features, storing payment information for easier checkouts, etc. The appropriate balance here is really best decided by you, but this can be difficult when you first get started. Also, as others have said, SSL is the only way to reliably protect the communication from observation (it also verifies the identify of you and the user, which can be crucial), but if this is not an option, you can provide some decent security by observing the golden rule of Web development: NTDFTC - Never trust data from the client. This doesn't mean that you can't believe anything; it just means that your logic should be suspicious of everything you receive from the client (in PHP, this means $_REQUEST[] or all get, post, and cookie data) and validate it. Unfortunately, many people do not follow this rule (or even know about it), and this lead to many of the perceived security problems of register_globals. Anyway, let me know if you have any other questions or would like to see some specific examples. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security and register globals
Having recently switched from php 4.0.0 to 4.2.3 I quickly realized the change in variable handling. I still experience problems using the $_POST and $_GET globals so I currently have my register globals ON so I can have the ability to pass variables from page to page without using the $_POST and $_GET methods although I would really like to use them. My current project has me creating a login interface for users to access a form and file upload tools. I am using only 1 set of scripts for everyone. Each user is assigned a path to their file area and these records are kept in a MySQL database along with username, password and contact info. As Each page is loaded the ID variable is checked and table data is then loaded for them for use on that page. If the ID variable is null they are given an error and redirected to the login page. This is to keep them from bookmarking the index page for the tools. My question is this: If I were to turn off register_globals and use the $_POST and $_GET methods, what are the chances of a user getting someone else's variable information using only one set of scripts for all. There could be up to 700 people using the script at any given time. Cookies are not an options as many users may have them turned off and sessions have never worked for me or at least I have never figured them out to work the way I think they should. Using _POST or _GET doesn't make your scripts any more secure. It is still all dependant on how you write them. If you assume that the ID coming from _POST or _GET is the user that just logged in, then anyone can just change the ID and get other peoples information. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security and register globals
Correct! Problem is that I have been given explicit instructions to not use cookies to do this. The only way I can think of doing it without using cokkies is to pass at least one variable from page to page so the scripts know who the user is. Getting them to the user index page with links to the tools without knowing what the ID is was my main focus. I did this using hidden input type variables so it's not included on the URL when they get there. I could continue to do so if I were using all form based links but the value could still be seen in the source for the page. Ed On Mon, 30 Sep 2002, John W. Holmes wrote: Having recently switched from php 4.0.0 to 4.2.3 I quickly realized the change in variable handling. I still experience problems using the $_POST and $_GET globals so I currently have my register globals ON so I can have the ability to pass variables from page to page without using the $_POST and $_GET methods although I would really like to use them. My current project has me creating a login interface for users to access a form and file upload tools. I am using only 1 set of scripts for everyone. Each user is assigned a path to their file area and these records are kept in a MySQL database along with username, password and contact info. As Each page is loaded the ID variable is checked and table data is then loaded for them for use on that page. If the ID variable is null they are given an error and redirected to the login page. This is to keep them from bookmarking the index page for the tools. My question is this: If I were to turn off register_globals and use the $_POST and $_GET methods, what are the chances of a user getting someone else's variable information using only one set of scripts for all. There could be up to 700 people using the script at any given time. Cookies are not an options as many users may have them turned off and sessions have never worked for me or at least I have never figured them out to work the way I think they should. Using _POST or _GET doesn't make your scripts any more secure. It is still all dependant on how you write them. If you assume that the ID coming from _POST or _GET is the user that just logged in, then anyone can just change the ID and get other peoples information. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security and register globals
Correct! Problem is that I have been given explicit instructions to not use cookies to do this. The only way I can think of doing it without using cokkies is to pass at least one variable from page to page so the scripts know who the user is. Getting them to the user index page with links to the tools without knowing what the ID is was my main focus. I did this using hidden input type variables so it's not included on the URL when they get there. I could continue to do so if I were using all form based links but the value could still be seen in the source for the page. If that's the way you have to do it, then make the ID that identifies the user something very hard to guess. Take a look at uniqid() in the PHP manual. Assign the user a unique id after they supply the correct username and password, and then pass that value around in the URLs. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security and register globals
It would be possible to do this if I then created another table to load their profile data to and use the unique id as the identifier. It would make it alot harder for someone to guess an ID. I would then need a way to flush out their records from the second table when they are finished. Easily enough done using a logout script but who actually does this anymore. It would be possible to create a script to run through cron to delete records from that table that are more than say 30 minutes old. Good idea, thanks. Ed If that's the way you have to do it, then make the ID that identifies the user something very hard to guess. Take a look at uniqid() in the PHP manual. Assign the user a unique id after they supply the correct username and password, and then pass that value around in the URLs. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security and register globals
It would be possible to do this if I then created another table to load their profile data to and use the unique id as the identifier. It would make it alot harder for someone to guess an ID. I would then need a way to flush out their records from the second table when they are finished. Easily enough done using a logout script but who actually does this anymore. It would be possible to create a script to run through cron to delete records from that table that are more than say 30 minutes old. Yeah, that would be a good way to do it. Save a timestamp along with the unique identifier. Update the timestamp whenever the user does something. Then delete the unique identifier if the timestamp ever gets to be more than X minutes old (cron is best way for that). What you are basically doing, though, is recreating sessions with the trans_sid enabled. PHP will go through your code for you and automatically add the session ID to all URLs and forms. You can turn off cookies in php.ini, too, so you have to use the URL method. Only setback is that PHP must be compiled a certain way (--enable_trans_id or something) for it to work. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security and register globals
I think I would rather do it using a new table than have to handle sessions. It actually sounds harder to do it this way but I like hard. :) Thanks, Ed On Mon, 30 Sep 2002, John W. Holmes wrote: It would be possible to do this if I then created another table to load their profile data to and use the unique id as the identifier. It would make it alot harder for someone to guess an ID. I would then need a way to flush out their records from the second table when they are finished. Easily enough done using a logout script but who actually does this anymore. It would be possible to create a script to run through cron to delete records from that table that are more than say 30 minutes old. Yeah, that would be a good way to do it. Save a timestamp along with the unique identifier. Update the timestamp whenever the user does something. Then delete the unique identifier if the timestamp ever gets to be more than X minutes old (cron is best way for that). What you are basically doing, though, is recreating sessions with the trans_sid enabled. PHP will go through your code for you and automatically add the session ID to all URLs and forms. You can turn off cookies in php.ini, too, so you have to use the URL method. Only setback is that PHP must be compiled a certain way (--enable_trans_id or something) for it to work. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security login
At 04:12 PM 8/12/2002 +0100, Pag wrote:
Here is my humble, but relatively effective solution for a low security site.
Create a file called security.php and require it at the head of every
secure page. This is the one I use.
?
session_start();
if(!session_is_registered(userinfo))
{
echo h1You are not logged in. Please do so./h1BR;
echo a href=\login.php\Login Here/a;
exit;
}
else
{
echo You are currently logged in as: $userinfo[name] BR;
echo If you are not $userinfo[name] please a
href=\logout.php\Logout/a.BR Thank you.BRBR;
}
?
All you need your log in script to do is check the user name and password
against what is stored in the database and register a session.
You can store lots of useful information in the session as well. I find it
useful if you want to give different users different permission
levels. That way you can late check the session data to see if they have
permission to update the news, or publish an article.
Nick
Well, first off sory for a very basic question, but i really dont
know where else to look for the answer. Heres my dilemma:
I need to code a backend for this site i am building, the backend
will manage the news for the front page. The database stuff is pretty
straight forward (so far!), but i need to validate who does the managing,
i mean, some sort of login for only a few people. I am thinking of using
username/pass from a table and all that but the thing is, how do i do the
validating itself? Sure i know how to check for valid user/pass, but then
what happens for the rest of the pages inside the backend, how do i keep
the user validated and make sure only he can browse inside that secure
mini site?
Dont know if i am explaining things right, hmm, ok, any of you
guys are familiar with gryematter? It validates the user at the start and
then we can do whatever we want inside. I want to prevent users from
skipping the login and just typing the other page url and go on from there.
I use sessions, cookies? what? can you provide me with some urls
for my research, or at least what to look for?
Thanks a lot, really appreciate all the help.
Pag
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] security login
If it's simple security then you might want to use an .htaccess file instead
of coding something.
More complex solutions involve asking the user for credentials, validating
those credentials and then storing something in the $_SESSION that indicates
that this user has been validated.
It can be something as simple as $_SESSION['isOK'] = true; to creating a
Person object with various credentialling information and storing it.
$_SESSION['currentMember'] = new Person();
$_SESSION['currentMember']-setLogin('myUserName');
$_SESSION['currentMember']-setPassword('someSillyPassword');
$_SESSION['currentMember']-load();
if !$_SESSION['currentMember']-isA('SYSADMIN){
die(Begone form here you freakin' script-kiddie!);
} // if !$_SESSION['currentMember']-isA('SYSADMIN)
// normal code goes here.
In the above example it is assumed that you have created a Person object to
deal with everything.
HTH,
=C=
*
* Cal Evans
* The Virtual CIO
* http://www.calevans.com
*
-Original Message-
From: Pag [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 12, 2002 10:12 AM
To: [EMAIL PROTECTED]
Subject: [PHP] security login
Well, first off sory for a very basic question, but i really dont know
where else to look for the answer. Heres my dilemma:
I need to code a backend for this site i am building, the backend will
manage the news for the front page. The database stuff is pretty straight
forward (so far!), but i need to validate who does the managing, i mean,
some sort of login for only a few people. I am thinking of using
username/pass from a table and all that but the thing is, how do i do the
validating itself? Sure i know how to check for valid user/pass, but then
what happens for the rest of the pages inside the backend, how do i keep
the user validated and make sure only he can browse inside that secure
mini site?
Dont know if i am explaining things right, hmm, ok, any of you guys are
familiar with gryematter? It validates the user at the start and then we
can do whatever we want inside. I want to prevent users from skipping the
login and just typing the other page url and go on from there.
I use sessions, cookies? what? can you provide me with some urls for my
research, or at least what to look for?
Thanks a lot, really appreciate all the help.
Pag
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security concern with curl
On Fri, Aug 09, 2002 at 10:10:28PM +0200, Andy wrote: [curl] So I fear that someone would be able to tranfer files on / off my server. Has anybody some experiance on that, or can give a comment on that? Ehhh, PHP already has enough capabilities to transfer files to/from your server from/to the rest of the world without using curl. Or are you (healthy) paranoied about oasis? -- Daniel Tryba -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security concern with curl
So I fear that someone would be able to tranfer files on / off my server. Has anybody some experiance on that, or can give a comment on that? Ehhh, PHP already has enough capabilities to transfer files to/from your server from/to the rest of the world without using curl. Or are you (healthy) paranoied about oasis? well it is just that I have to install an aditional pice of software and it does something I am not familar with it. All I want to know if this could be security issue and a reason not to install oasis. How about oasis itself? This pease of SW will run on my server and could do anything what php is allowed to do (maybe delete some files or transfer them, open a gateway to some other user to take over my server, send spam over my server and so on) Are there any rummors about oasis, or is this a reputable software? Right now I just know what the site is telling me. Thanx for all your comments on that. Andy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions4.2.0
On Wed, 24 Jul 2002, Scott Fletcher wrote:
It work very nicely The whole process take 30 to 45 minutes for just
one server. I wonder how does someone did 12 computers in 10 minutes.
Cool!
cd /usr/src/local
tar -zxf php-4.2.2.tar.gz
cd php-4.2.2
../php-4.2.1/config.nice
make install
for i in server1 server2 server3 server4 server5 serverN
scp ../apache_1.3.26/src/httpd ${i}:/usr/local/apache/bin/
Most of the time was watching 'make install'.
miguel
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
Hmmm, interesting I didn't know about this and didn't see it in the docs. So now I know for my next upgrade. Anyway, my upgrade is in, and through the mails it should be clear to those who thought how terribly difficult and time consuming it is/was to do the upgrades that it was in fact not difficult at all, and seemingly even easier that the way I did it. Ian On Wednesday 24 July 2002 01:03, Andrew Chase wrote: If all you're doing is applying the patch (not adding/removing any extensions), you should be able to use ./config.nice which will use all of the configuration commands from your last compile (This is an extremely handy thing if your GD/Freetype setup was particularly ornery the first time around! ;) ) -Andy -Original Message- From: Ricky Dhatt [mailto:[EMAIL PROTECTED]] ./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --with-ldap make make install /usr/local/apache/bin/apachectl restart Hmm...is the configure step really necessary? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
Doing that right now! Just like a basic upgrade. Thanks, FletchSOD Matt Schroebel [EMAIL PROTECTED] wrote in message 4B08FD7DB3CBD4119F560002A508C453015B38DA@hsus3">news:4B08FD7DB3CBD4119F560002A508C453015B38DA@hsus3... From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 12:43 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 I don't know how to appy patches to the PHP software. I just finish upgrading the website to work with PHP 4.2.1 from PHP 4.0.6. And now this So, just patched it then configure openssl, mycrypt, curl, modssl then do the usual stuff for PHP then apache, right?? Rebuilding from source: 1. download the new php source, extract it to whereever you do. 2. cd to php-4.2.2 copy config.nice from your existing php compile dir (this has your previous complies config command). 3. Run it: ./config.nice 4. make 5. apachectl stop 6. make install 7a. i. If php is a DSO: ii. apachectl start (you're done) 7b. i. If php is compiled into apache: ii. cd to apache compile dir iii. make clean iv. ./config.status v. make vi. make install vii. apachectl start (you're done) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
It work very nicely The whole process take 30 to 45 minutes for just one server. I wonder how does someone did 12 computers in 10 minutes. Cool! Matt Schroebel [EMAIL PROTECTED] wrote in message 4B08FD7DB3CBD4119F560002A508C453015B38DA@hsus3">news:4B08FD7DB3CBD4119F560002A508C453015B38DA@hsus3... From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 12:43 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 I don't know how to appy patches to the PHP software. I just finish upgrading the website to work with PHP 4.2.1 from PHP 4.0.6. And now this So, just patched it then configure openssl, mycrypt, curl, modssl then do the usual stuff for PHP then apache, right?? Rebuilding from source: 1. download the new php source, extract it to whereever you do. 2. cd to php-4.2.2 copy config.nice from your existing php compile dir (this has your previous complies config command). 3. Run it: ./config.nice 4. make 5. apachectl stop 6. make install 7a. i. If php is a DSO: ii. apachectl start (you're done) 7b. i. If php is compiled into apache: ii. cd to apache compile dir iii. make clean iv. ./config.status v. make vi. make install vii. apachectl start (you're done) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
On Wednesday 24 July 2002 22:22, Scott Fletcher wrote: It work very nicely The whole process take 30 to 45 minutes for just one server. You've got a slow computer and/or you type too slow ;-) I wonder how does someone did 12 computers in 10 minutes. Cool! For me it was a case of 'typing' in 6 commands: 1) download php 2) untar it 3) cd 4) configure 5) make 6) make install Actually I just copy and pasted those commands which took me all of 5 seconds to do. So unless you count the download and compilation time, 12 systems in 10 minutes is in the ballpark. -- Jason Wong - Gremlins Associates - www.gremlins.com.hk Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * /* Yow! I just went below the poverty line! */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
At 10:22 AM 7/24/02 -0400, Scott Fletcher wrote: It work very nicely The whole process take 30 to 45 minutes for just one server. I wonder how does someone did 12 computers in 10 minutes. Cool! For me the key to upgrading many servers is to compile once then copy the resulting files to all my other servers. I also compile Apache + mod_ssl + PHP static into one file so usually all I have to do is copy the httpd file to the other machines. The machines need similar CPUs and identical library versions, but that isn't too hard to do. With Linux it is legal to copy in the new httpd file then apachectl restart to update the server. Rick -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
I don't know how to appy patches to the PHP software. I just finish upgrading the website to work with PHP 4.2.1 from PHP 4.0.6. And now this So, just patched it then configure openssl, mycrypt, curl, modssl then do the usual stuff for PHP then apache, right?? Adam Alkins [EMAIL PROTECTED] wrote in message 050a01c231c2$d483f770$aa9303c4@alkins">news:050a01c231c2$d483f770$aa9303c4@alkins... Any real programmer should know that almost nothing is bug free, even if you test it beyond your imagination. Something is always going to elude you and be found by someone experimenting down the road. For the widespread use of PHP, I'm rather impressed by the small amount of vunerabilities discovered in PHP so far. Some humans are just never ever satisfied... -- Adam Alkins http://www.rasadam.com -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
Amended to this recent posting. Already started a new posting from scratch. Scott Fletcher [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I don't know how to appy patches to the PHP software. I just finish upgrading the website to work with PHP 4.2.1 from PHP 4.0.6. And now this So, just patched it then configure openssl, mycrypt, curl, modssl then do the usual stuff for PHP then apache, right?? Adam Alkins [EMAIL PROTECTED] wrote in message 050a01c231c2$d483f770$aa9303c4@alkins">news:050a01c231c2$d483f770$aa9303c4@alkins... Any real programmer should know that almost nothing is bug free, even if you test it beyond your imagination. Something is always going to elude you and be found by someone experimenting down the road. For the widespread use of PHP, I'm rather impressed by the small amount of vunerabilities discovered in PHP so far. Some humans are just never ever satisfied... -- Adam Alkins http://www.rasadam.com -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 12:43 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 I don't know how to appy patches to the PHP software. I just finish upgrading the website to work with PHP 4.2.1 from PHP 4.0.6. And now this So, just patched it then configure openssl, mycrypt, curl, modssl then do the usual stuff for PHP then apache, right?? Rebuilding from source: 1. download the new php source, extract it to whereever you do. 2. cd to php-4.2.2 copy config.nice from your existing php compile dir (this has your previous complies config command). 3. Run it: ./config.nice 4. make 5. apachectl stop 6. make install 7a. i. If php is a DSO: ii. apachectl start (you're done) 7b. i. If php is compiled into apache: ii. cd to apache compile dir iii. make clean iv. ./config.status v. make vi. make install vii. apachectl start (you're done) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
Ian Ball [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... patch -p0 php-4.2.1-to-4.2.2.patch cd php-4.2.1 ./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --with-ldap make make install /usr/local/apache/bin/apachectl restart Hmm...is the configure step really necessary? --Ricky -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
If all you're doing is applying the patch (not adding/removing any extensions), you should be able to use ./config.nice which will use all of the configuration commands from your last compile (This is an extremely handy thing if your GD/Freetype setup was particularly ornery the first time around! ;) ) -Andy -Original Message- From: Ricky Dhatt [mailto:[EMAIL PROTECTED]] ./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --with-ldap make make install /usr/local/apache/bin/apachectl restart Hmm...is the configure step really necessary? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions4.2.0
The correct path for the windows binary version is http://www.php.net/do_download.php?download_file=php-4.2.2-Win32.zip /lasso ([EMAIL PROTECTED]) Rouvas Stathis wrote: Hi all, Just wanting to notify everyone that the link for the PHP.4.2.2 download is broken. -Stathis. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
Can you post this to php.announce as well? Marko Karppinen wrote: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1 Issued on: July 22, 2002 Software: PHP versions 4.2.0 and 4.2.1 Platforms: All The PHP Group has learned of a serious security vulnerability in PHP versions 4.2.0 and 4.2.1. An intruder may be able to execute arbitrary code with the privileges of the web server. This vulnerability may be exploited to compromise the web server and, under certain conditions, to gain privileged access. Description PHP contains code for intelligently parsing the headers of HTTP POST requests. The code is used to differentiate between variables and files sent by the user agent in a multipart/form-data request. This parser has insufficient input checking, leading to the vulnerability. The vulnerability is exploitable by anyone who can send HTTP POST requests to an affected web server. Both local and remote users, even from behind firewalls, may be able to gain privileged access. Impact Both local and remote users may exploit this vulnerability to compromise the web server and, under certain conditions, to gain privileged access. So far only the IA32 platform has been verified to be safe from the execution of arbitrary code. The vulnerability can still be used on IA32 to crash PHP and, in most cases, the web server. Solution The PHP Group has released a new PHP version, 4.2.2, which incorporates a fix for the vulnerability. All users of affected PHP versions are encouraged to upgrade to this latest version. The downloads web site at http://www.php.net/downloads.php has the new 4.2.2 source tarballs, Windows binaries and source patches from 4.2.0 and 4.2.1 available for download. Workaround If the PHP applications on an affected web server do not rely on HTTP POST input from user agents, it is often possible to deny POST requests on the web server. In the Apache web server, for example, this is possible with the following code included in the main configuration file or a top-level .htaccess file: Limit POST Order deny,allow Deny from all /Limit Note that an existing configuration and/or .htaccess file may have parameters contradicting the example given above. Credits The PHP Group would like to thank Stefan Esser of e-matters GmbH for discovering this vulnerability. Copyright (c) 2002 The PHP Group. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
Hi all, Just wanting to notify everyone that the link for the PHP.4.2.2 download is broken. -Stathis. -- Rouvas Stathis [EMAIL PROTECTED] http://www.di.uoa.gr/~rouvas -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
Yes. Please post something to php.announce! Nothing ever gets announced in there anymore. Steve Meyers [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Can you post this to php.announce as well? Marko Karppinen wrote: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1 Issued on: July 22, 2002 Software: PHP versions 4.2.0 and 4.2.1 Platforms: All The PHP Group has learned of a serious security vulnerability in PHP versions 4.2.0 and 4.2.1. An intruder may be able to execute arbitrary code with the privileges of the web server. This vulnerability may be exploited to compromise the web server and, under certain conditions, to gain privileged access. Description PHP contains code for intelligently parsing the headers of HTTP POST requests. The code is used to differentiate between variables and files sent by the user agent in a multipart/form-data request. This parser has insufficient input checking, leading to the vulnerability. The vulnerability is exploitable by anyone who can send HTTP POST requests to an affected web server. Both local and remote users, even from behind firewalls, may be able to gain privileged access. Impact Both local and remote users may exploit this vulnerability to compromise the web server and, under certain conditions, to gain privileged access. So far only the IA32 platform has been verified to be safe from the execution of arbitrary code. The vulnerability can still be used on IA32 to crash PHP and, in most cases, the web server. Solution The PHP Group has released a new PHP version, 4.2.2, which incorporates a fix for the vulnerability. All users of affected PHP versions are encouraged to upgrade to this latest version. The downloads web site at http://www.php.net/downloads.php has the new 4.2.2 source tarballs, Windows binaries and source patches from 4.2.0 and 4.2.1 available for download. Workaround If the PHP applications on an affected web server do not rely on HTTP POST input from user agents, it is often possible to deny POST requests on the web server. In the Apache web server, for example, this is possible with the following code included in the main configuration file or a top-level .htaccess file: Limit POST Order deny,allow Deny from all /Limit Note that an existing configuration and/or .htaccess file may have parameters contradicting the example given above. Credits The PHP Group would like to thank Stefan Esser of e-matters GmbH for discovering this vulnerability. Copyright (c) 2002 The PHP Group. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
[delete some flaming] Hehe, and I thought I had to go to USENET to see a flamewar. This is great, a flamewar delivered directly to my mailbox, it doesn't get better... Let me put my $0.02 in. Security holes happen, no matter what software you use. PHP and open source in general, unlike M$, does not have a new vius of the week, or security hole of the month. Their recent couple of announcements is bad luck, not bad design/development and I still happily stand by the PHP guys. I think PHP users should also be grateful that the PHP guys have said there is a need to upgrade to fix this hole, rahter than just put out a new release and hope most people see it and think great, a new version, I will upgrade. As for the the implied terrible difficulty of upgrading, on my Linux systems it was tragically complicated - I chose to patch my 4.2.1 source, then recompile, install and restart apache: patch -p0 php-4.2.1-to-4.2.2.patch cd php-4.2.1 ./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --with-ldap make make install /usr/local/apache/bin/apachectl restart Yes, with a script like this, it is terribly complicated. This whole process took less than 5 minutes. I had to do it on three machines, and there were no problems to be seen. If you are going to wine about having to upgrade software because of security holes, get off the net, it would be easier and take much less precious time. That's my $0.02 (or in my case 0.02 Euro). Now I will go back to trying to work out my ldap problems. Ian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
Any real programmer should know that almost nothing is bug free, even if you test it beyond your imagination. Something is always going to elude you and be found by someone experimenting down the road. For the widespread use of PHP, I'm rather impressed by the small amount of vunerabilities discovered in PHP so far. Some humans are just never ever satisfied... -- Adam Alkins http://www.rasadam.com -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: php security mailing list ...
Hi ... I want to be warned about php security issues, I couldn't find an exact match in the mailing list names ... which one do you recommend me? I believe that the Announce list would have any critical security warnings sent to it. It's also very low-volume. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: php security mailing list ...
Hello, On 07/22/2002 08:07 PM, Dario Bahena Tapia wrote: Hi ... I want to be warned about php security issues, I couldn't find an exact match in the mailing list names ... which one do you recommend me? http://www.phpadvisory.com/ is what you are looking for. -- Regards, Manuel Lemos -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security with XML
You could store passwords as MD5 hashes which of course is NOT really encryption, but it would obfuscate the users' passwords. They would still be vulnerable to social engineering (Hmm, I'll try his wife's name, then his dog's name, then his phone#, etc) and brute force (I'm going to run every word in the pspell dictionary through MD5 and see if anything matches) attacks, but it would be better than plain text, at least. So, instead of user nameFoo/name passwordbar/password /user you would have user nameFoo/name password37b51d194a7513e45b56f6524f2d51f2/password /user When 'Foo' tries to log in, you would just use MD5() on the password he entered in the web form and compare it to the value in the XML file. If it matches, he's in... otherwise, it's not the right password. I'm sure others will come up with more secure ideas, but anything is more secure than passwords in plain text. :) -Andy -Original Message- From: Chris Earle [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 9:42 AM To: [EMAIL PROTECTED] Subject: [PHP] Security with XML I've created a db like system with XML and PHP, and I want to require a username/password to change the contents of the file. How should I go about documenting the username/password? The contents of the site aren't really all to important (no financial info or anything like that, mostly just links actually), but I don't want someone's information stolen because someone found the users.xml file and opened it. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security with XML
Are you telling me that you cannot look at 37b51d194a7513e45b56f6524f2d51f2 and see that the is the same as bar? ... Just kidding. Thanks for the tip, that makes a lot of sense. Andrew Chase [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... You could store passwords as MD5 hashes which of course is NOT really encryption, but it would obfuscate the users' passwords. They would still be vulnerable to social engineering (Hmm, I'll try his wife's name, then his dog's name, then his phone#, etc) and brute force (I'm going to run every word in the pspell dictionary through MD5 and see if anything matches) attacks, but it would be better than plain text, at least. So, instead of user nameFoo/name passwordbar/password /user you would have user nameFoo/name password37b51d194a7513e45b56f6524f2d51f2/password /user When 'Foo' tries to log in, you would just use MD5() on the password he entered in the web form and compare it to the value in the XML file. If it matches, he's in... otherwise, it's not the right password. I'm sure others will come up with more secure ideas, but anything is more secure than passwords in plain text. :) -Andy -Original Message- From: Chris Earle [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 9:42 AM To: [EMAIL PROTECTED] Subject: [PHP] Security with XML I've created a db like system with XML and PHP, and I want to require a username/password to change the contents of the file. How should I go about documenting the username/password? The contents of the site aren't really all to important (no financial info or anything like that, mostly just links actually), but I don't want someone's information stolen because someone found the users.xml file and opened it. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security: PHP: how to harden PHP scripts?
on 03/07/02 11:36 PM, Jean-Christian Imbeault ([EMAIL PROTECTED]) wrote: In general how does one go about hardening a PHP script. i.e. making it as hacker-proof as possible. General things like: I think the general answer is you can't, but you can make it more secure. - verifying user inputted data verify user inputted data means nothing... you should take a specific example, like make sure a text box is less than 500 words, contains only B BR I U tags, and starts with a capital letter, and then let us help you solve it. Obviously verifying a date is different to a password, verifying that a certain select box was selected is different from making sure that their phone number contains only numbers, etc etc. The string functions will do most of this for you with very little effort. empty(), isset(), strlen(), is_int(), is_str(), strip_tags(), ereg() eregi() and many others will all help, but you need to approach them one at a time. You should also be concerned about character sets. If you wanna get anal about it, you should be using register_globals OFF in your php.ini file, and should be treating any $_GET var as unsafe, and same with all other such variables (cookies, sessions, post, etc) - not putting clear-text passwords in php scripts A thread started in here about two weeks back with the subject Keeping Secrets in PHP Files... you should read that end-to-end... HEAPS of infomation. - use safe-mode? I have no idea about safe mode. This list really does work best (ie best results for you) if you come to us with a specific problem, rather than something general. Justin French -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security: PHP: how to harden PHP scripts?
Jean-Christian Imbeault wrote: I'm writing my first commercial site and of course I am thinking about security. I'm worried about someone using a flaw in my PHP script logic to access information they shouldn't. I've read the PHP books I have and Googled around but can't quite find specific answers to my questions about PHP and security. In general how does one go about hardening a PHP script. i.e. making it as hacker-proof as possible I'm sure you'll get a lot of responses to this including various opinions, so this will be short and a bit vague. The most important thing you can do as a developer is: 1. Never, ever trust data from the client That is the main thing you should focus on. There are many different methods of cleaning or filtering data from the client, and all of these have these key characteristics: 1. They make sure the data contains acceptable characters (rather than attempting to make sure it does *not* contain unacceptable characters - very important distinction). 2. They employ a strict naming convention that clearly identifies which data has/has not been filtered. For example, assign $clean_blah=$blah when you have found $blah to be acceptable. In order for this to be useful, you should never accept any data from the client that has a name beginning with clean_, and you should only use the clean variables in queries or logical statements that affect access or any other critical function. Along these lines, you should never make any assumptions in your scripts. For example, if you have a variable that can only have three possible values, don't do [if, elseif, else], rather do [if, elseif, elseif]. Also, make sure you intialize all variables you are depending on. In adhering to the golden rule mentioned above (Never, ever trust data from the client), you need to make sure you don't accidentally accept data from the client and think it is something that you set. People might try to include rogue variables in the URL, post their own forms to various URLs in your application, etc. Basically, if you code very carefully and deliberately, you will create a very secure application. Many people focus only on securing the environment, but writing secure code is often much more important. Hope that helps give you some ideas. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security: PHP: how to harden PHP scripts?
Chris Shiflett wrote:
Jean-Christian Imbeault wrote:
In general how does one go about hardening a PHP script. i.e. making
it as hacker-proof as possible
There is no such thing as a 100% secure solution (this applies to
everything running on a computer, PHP included). But basically you can
make it pretty secure. Then again, quite a lot depends on what you are
going to write. Govt/Banks need much more defense than a small/midsized
commercial site (and are capable to pay for it). You can basically be
happy with some care in you development, just make sure your customers
do understand the amount of time this is going to take and are ready to
pay for it. Then let them decide themselves, but if you see they choose
a risky path in order to save budget money do write them a formal
letter, in which you acknowledge the problem. Many customers do not
think they need security until it's too late, then they get mad at you
because they did not want to buy the extra time for secure coding. So
make sure everyone knows what their responsibility are and make sure
this is stated on paper.
1. Never, ever trust data from the client
That's it. If you leave Register_globals off you will be sure you get
only what you need to get. Then, of course, you shall control data
content. As I am sure you know yourself most of the trouble will come
from uncorrect data input.
You might actually write client-side javascript controls to avoid
uncorrect input and then think that your data are clean. This is where
most of the problems come from (as Chris points out, it's not difficult
to post a form to your script after writing it at home, or just do a
plain command line call with altered parameters from a user browser, I
see that stuff on our customers logs quite often).
So, no matter what you checked on the client, check it again on the
server (even if you are not paranoid, some users may just have disabled
their javascript, right?)
Basically, if you code very carefully and deliberately, you will create
a very secure application. Many people focus only on securing the
environment, but writing secure code is often much more important.
Words of wisdom! and actually about 75% of the code you write is
dedicated to this very job, if you really want to get a stable application.
Alberto
Kiev
--
-_=}{=_-@-_=}{=_--_=}{=_-@-_=}{=_--_=}{=_-@-_=}{=_--_=}{=_-
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu?
lOrD i'M sHiNiNg...
YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security: PHP: how to harden PHP scripts?
Justin French wrote: This list really does work best (ie best results for you) if you come to us with a specific problem, rather than something general. I totally agree. Sorry to have asked such a wide question but in this case it is a bit of a chicken-or-the-egg situation. To make your scripts secure you need to make sure they no insecure programming practices. But how do you find out what insecure programming practices are? You only find out after someone exploits it. If I knew that someone can use a PHP session to somehow run malicious scripts on my server than I would do a search on Google for PHP session security advisory or something like that and find out how to secure my scripts against this. But I'd have to know in the first place that such a security problem exists with sessions. I guess what I am looking for is a kind of best practices for security list for PHP programming. Do's and Don't, or a list of common pitfalls and how to avoid them. Can anyone point me to such a list or tutorial? Jc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security problem?
On Tuesday, June 25, 2002, at 08:26 PM, Analysis Solutions wrote: I usually run PHP as CGI. My secure files are kept in a directory that's not under the */docroot. Thus, they can't be gotten to through the web server at all. Plus, the secure files are chmoded 600 (which means they can be read/written only by the owner). Thereby, the only user on the server who can read them is me. Tradeoff, huh? If I understand it correctly, you can't keep the files outside the docroot if you're using mod_php b/c the web server itself is what fetches the file (therefore it needs to be in the docroot). But mod_php is faster than CGI PHP and can handle more simultaneous requests. Right? Erik Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security problem?
On Tuesday, June 25, 2002, at 08:26 PM, Analysis Solutions wrote:
I usually run PHP as CGI. My secure files are kept in a directory
that's
not under the */docroot. Thus, they can't be gotten to through the
web
server at all. Plus, the secure files are chmoded 600 (which means
they
can be read/written only by the owner). Thereby, the only user on
the
server who can read them is me.
Tradeoff, huh? If I understand it correctly, you can't keep the files
outside the docroot if you're using mod_php b/c the web server itself
is
what fetches the file (therefore it needs to be in the docroot). But
mod_php is faster than CGI PHP and can handle more simultaneous
requests. Right?
Yes you can. Apache can read any file it has access to.
Include('/home/user/includes/myfile.php');
Works just as well as
Include('/home/user/www/includes/myfile.php');
Where /home/user/www is your web root.
---John Holmes...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security problem?
No. The only way they can get your source is by ftping or having shell access to your server. And even then, they'd have to have read perms on your web folder/files. If you were to have a lot of unknown people jacking around on your server, you have a lot of other stuff to worry about that who's gonna steal your mysql username/password. They can't just say: Download http://yoursite.com/file_with_good_info.php and get the php-source, all they'd get is the HTML source. -- Tyler Longren Captain Jack Communications [EMAIL PROTECTED] www.captainjack.com On Tue, 25 Jun 2002 20:46:04 +0100 Peter [EMAIL PROTECTED] wrote: When you have the standard $link = mysql_connect(localhost,username,secretpassword); Would it not be possible for someone to use PHP from another server to download your source and find out your MySQL details including password? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security problem?
On Tuesday, June 25, 2002, at 03:46 PM, Peter wrote: When you have the standard $link = mysql_connect(localhost,username,secretpassword); Would it not be possible for someone to use PHP from another server to download your source and find out your MySQL details including password? Yes. If they have access to the source, they can see these values. If they don't have some way of seeing those files, though, they won't be able to do it. For this reason it is a good idea to make sure that no one except you and the user that the webserver runs as can read your files. For instance, all my files are actually readable to all (their mode is 644), except for one. This one file is readable only to me and members the apache group, and it contains all of the database connection parameters. Of course, the only member of the apache group is the apache user that the web server runs as, so no one else will be reading this file. It's a luxury of having root access on my server, since this is pretty difficult to do without a root user (catch 22 -- how do you change the file to the apache group unless you are a member of the apache group, but if you are a member of the apache group then you can see all of the protected files in that group). Also I have a directive that prevents Apache from serving any file with .inc suffix, and this file does, so Apache (hopefully) won't serve this data to the world via port 80. Erik Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security problem?
On Tuesday, June 25, 2002, at 03:46 PM, Peter wrote: When you have the standard $link = mysql_connect(localhost,username,secretpassword); Would it not be possible for someone to use PHP from another server to download your source and find out your MySQL details including password? Yes. If they have access to the source, they can see these values. If they don't have some way of seeing those files, though, they won't be able to do it. For this reason it is a good idea to make sure that no one except you and the user that the webserver runs as can read your files. For instance, all my files are actually readable to all (their mode is 644), except for one. This one file is readable only to me and members the apache group, and it contains all of the database connection parameters. Of course, the only member of the apache group is the apache user that the web server runs as, so no one else will be reading this file. And make sure PHP is in safe mode. Otherwise, on a virtual server, with many users, I can write a php script that does this: $fp = fopen(/path/to/your/htdocs/html/config.inc,r); And read through your file. Since my script is running as apache, and apache has access to your file, it'll work. That's why you run in safe mode, as I understand it, at least. If you run a dedicated server, then you're fine, you just have to keep people from getting into your machine. Also I have a directive that prevents Apache from serving any file with .inc suffix, and this file does, so Apache (hopefully) won't serve this data to the world via port 80. Or just name it with a php extension. Then the user won't receive anything, either. I always name mine file.inc.php so something similar. Whatever you do, make sure the source isn't sent by apache to the browser. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security advice...
That's a big can of worms :) I think perhaps start with one problem, like sessions, then move onto another problem. Not really sure what you mean by cross site scripting... maybe you mean writing decent code once, and having it portable to many new projects with little fuss? Justin French on 14/06/02 1:01 AM, Jas ([EMAIL PROTECTED]) wrote: I am wondering if anyone out there knows of a good and quick way to test the security of a site for multiple vulnerabilities; cross site scripting, etc. Of course any examples of secure coding techniques might be a better question to ask, so if anyone knows of some good resources for this please let me know where I can do some good research on this subject. Thanks in advance, Jas -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
