Re: [PHP] Keeping "Secrets" in PHP Files
>try this for now.
>
>http://pobs.mywalhalla.net/
>
>depending on how fancy your code is it may not work. Or you'll only have
>to change a few little things.
>
>basically what it does is :
>
>for($bob=1; $bob<10; $bob++){
>echo $bob;
>$sam=$bob;
>}
>
>Converts above to something like
>
>for($edghr354dfga=1; $edghr354dfga<10; $edghr354dfga++){ echo
>$edghr354dfga;$hsfgfsyrtae34dfgdfas=$edghr354dfga; }
>
>basically.
Sure hope they are not charging money for *THAT*...
And I don't see how it helps the "secrets" issue at all...
--
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
Re: [PHP] Keeping "Secrets" in PHP Files
>The hosting provider could probably implement a solution... Alter the FTP >configuration to automatically set the group permission to that of the web >server when you transfer files. You wouldn't need to be in the group. >You're the owner and can modify your own files. World Read access would be >unnecessary. > >Thoughts? So I write a PHP application to read your file, or just symlink a .phps file to it. Game over. The "Group" is no more magical than the "User" as an access route. If PHP can read it to use, PHP can read it for me to steal. -- 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
Re: [PHP] Keeping "Secrets" in PHP Files
>I've been thinking some more about the issue of keeping PHP >source files secure in a shared hosting environment. I've now >convinced myself that there is simply no way to protect these >files, even if safe_mode is turned on, as long as other users can >have telnet (or ssh) access to the box. > >Here's my thinking ... > >First off, I am assuming that > - we are discussing a Unix-variant > environment (I don't know enough about > Windows to comment) > - the web server does NOT run as root To be thorough, you should also rule out: 1. PHP *could* be run as a CGI via suExec as your own user, and thus only if your own shell account was compromised would the file be readable. (If your own shell account is compromised you probably have bigger problems than just the PHP-readable files...) My host actually provides me with both "nobody" Module and "realuser" CGI PHP installation, for example. (http://hostbaby.com -- I highly recommend them -- Apparently they had a hard drive crash last week, but I didn't even notice anything until a cron job ran this week that needed to read/write a file whose permissions didn't quite get restored.) So, if I *really* wanted a particular "secret" secure, I could run it as CGI and keep all my files 400 (or 600 for data) So far, I've used the CGI more for the second stage of file upload (copy into web-tree *ONLY* after security vetting has occurred) but I *COULD* run all the database pages through CGI... And with the minimal traffic I get, I probably should... Oh well. [ASIDE] Too bad I can't run the CGI one first, get a db connection, and then "switch" to the Module one for the rest... Oh, never mind, once you've fired up the CGI, it ain't slower to run. [/ASIDE] 2. I *think* Apache 2.0 *can* be made to run PHP as a Module in different directories as different users... At least, last I heard, that was on the boards for "To Do" in Apache 2.0... So, in theory, as I understand it, there *could* be an ISP who was running Apache 2.0 Beta that was running each users' PHP Module as that user, and your "secrets" files would not be world-readable. 3. I'm reasonable certain fhttpd has the same feature as described in 2. That said, some more caveats about file browsing: I *THINK* you can bury your PHP file inside directories that are not readily browsable by other shell accounts. So long as the "foo.inc" file *is* readable, the intervening directories don't have to be. I *THINK*. I got bit by this once on one web-site, but I was mixing and matching a Module and CGI usage (see 1.) and maybe was just confusing myself about which user was actually 'acting' at a particular time. >So unless I'm missing something, safe_mode provides no protection >in a Unix environment where > - the web server does not run as root > - other users have telnet access to the box > >I hope wrong. Can anyone find the hole in my reasoning? Safe mode stops some of the most obvious routes of reading the files in question -- It doesn't stop a determined reader from digging them out and reading them. As noted earlier -- If a real hacker *really* wants to break in, they will. Usually, your task (and the ISP's) is to raise the bar high enough that the frequency of successful attack is low enough, that you/they don't spend your/their entire life restoring from un-hacked backups. There are some high-end special cases where your task is far more complicated than that, of course... To that end, less-obvious file names and safe mode "weed out" some percentage of the "wannabe hackers" If truly secure "secrets" are needed, a shared environment is the wrong answer... The same shoe doesn't fit everybody. I generally prefer systems where I don't feel hamstrung every time I need to do something interesting with my web-sites, and I'm willing to risk the (mostly public) data in my databases being compromised by fellow clients of my ISP for that. I'm also mostly on servers with starving musicians who have a hard enough time getting their web-sites to work and getting gigs, much less time to waste pawing through my files :-) In one extreme case, the bulk of the data is editable by anybody on the planet through a web-interface, so "securing" the username/password would be almost pointless. I still do it, through habit and to avoid mass destruction by the unwashed masses, but... Security is not an on/off switch. It's a gradient in N dimensions, where you have to balance usability, development time, risk, upper management stupidity, and a host of minor variables to decide where your software/hardware/solution "fits" into the spectrum. You can't learn that in one day, or even in a week's seminar. It's a place where experience counts. I'm not saying a one-week security seminar wouldn't be invaluable -- only that the seminar has to be followed by a lot of real-world experience to be really useful. I've picked up (mostly against my will) enough knowledge about security to know how truly ignorant I am
Re: [PHP] Keeping "Secrets" in PHP Files
try this for now.
http://pobs.mywalhalla.net/
depending on how fancy your code is it may not work. Or you'll only have
to change a few little things.
basically what it does is :
for($bob=1; $bob<10; $bob++){
echo $bob;
$sam=$bob;
}
Converts above to something like
for($edghr354dfga=1; $edghr354dfga<10; $edghr354dfga++){ echo
$edghr354dfga;$hsfgfsyrtae34dfgdfas=$edghr354dfga; }
basically.
Lazor, Ed wrote:
>Dang. $2880 is kind of expensive! I wish they'd base licensing more on how
>many copies your encoded program you sell.
>
>-Original Message-
>http://www.zend.com/store/products/zend-encoder.php
>
>
>This message is intended for the sole use of the individual and entity to
>whom it is addressed, and may contain information that is privileged,
>confidential and exempt from disclosure under applicable law. If you are
>not the intended addressee, nor authorized to receive for the intended
>addressee, you are hereby notified that you may not use, copy, disclose or
>distribute to anyone the message or any information contained in the
>message. If you have received this message in error, please immediately
>advise the sender by reply email and delete the message. Thank you very
>much.
>
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Keeping "Secrets" in PHP Files
Sorry, Wrong topic. http://www.php-encoder.com/ Looks like beta is starting soon for this, so we should see it in a little bit. They have an option for per script charge. You upload the file and it gives you a compiled one. My guess it is the same thing as Zend encoder, just not as expensive. Dan Dang. $2880 is kind of expensive! I wish they'd base licensing more on how many copies your encoded program you sell. -Original Message- http://www.zend.com/store/products/zend-encoder.php This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Keeping "Secrets" in PHP Files
Dang. $2880 is kind of expensive! I wish they'd base licensing more on how many copies your encoded program you sell. -Original Message- http://www.zend.com/store/products/zend-encoder.php This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Keeping "Secrets" in PHP Files
Easy, http://www.zend.com/store/products/zend-encoder.php Dan -Original Message- From: Erik Price [mailto:[EMAIL PROTECTED]] Sent: Monday, July 01, 2002 7:29 AM To: Lazor, Ed Cc: [EMAIL PROTECTED] Subject: Re: [PHP] Keeping "Secrets" in PHP Files On Friday, June 28, 2002, at 06:14 PM, Lazor, Ed wrote: > The hosting provider could probably implement a solution... Alter the > FTP > configuration to automatically set the group permission to that of the > web > server when you transfer files. You wouldn't need to be in the group. > You're the owner and can modify your own files. World Read access > would be > unnecessary. Someone pointed out last week that a maleficant can write a script that reads other files' data [and does something evil with that], since it will be executed as the web server user and the web server user can read all those files. 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Keeping "Secrets" in PHP Files
On Friday, June 28, 2002, at 06:14 PM, Lazor, Ed wrote: > The hosting provider could probably implement a solution... Alter the > FTP > configuration to automatically set the group permission to that of the > web > server when you transfer files. You wouldn't need to be in the group. > You're the owner and can modify your own files. World Read access > would be > unnecessary. Someone pointed out last week that a maleficant can write a script that reads other files' data [and does something evil with that], since it will be executed as the web server user and the web server user can read all those files. 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] Keeping "Secrets" in PHP Files
On Sunday 30 June 2002 09:52, Justin French wrote: > on 29/06/02 3:20 AM, Tamas Arpad ([EMAIL PROTECTED]) wrote: > >> I was thinking if you use 90 character long filenames, assuming you > >> only use the letters of the alphabet and the digits then you would > >> have 62^90 different filenames, which is roughly 2E161 (2 followed by > >> 161 zeros), which is quite a bit. Hopefully the numbers involved > >> would make it infeasible for an attacker to loop through all the > >> permutations. > > > > But what if the attacker just knows one file's name, for example > > index.php or something that's in the url in the browser. Then he/she > > can stole that file, read it, and gets other filenames because of > > includes/requires. With some work he/she can get all the files without > > any bruteforce filename guessing. > [...] > If you adopt some of the practices (I think) included earlier in this > thread by me, you could restrict browser access to your inc files by the > use of smart file naming, dedicated directories and .htaccess files, > then this should cover the basics of people grabbing your included files > (with passwords etc) via http (browser). > > It doesn't cover people within the server (others on a shared server, > etc) though. Yes, but I think we were talking about the latter, when users have shell access on a shared server. Preventing from getting the php source through the web server is relatively easy, there are really a dozen of ways. Arpi -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Keeping "Secrets" in PHP Files
on 29/06/02 3:20 AM, Tamas Arpad ([EMAIL PROTECTED]) wrote: >> I was thinking if you use 90 character long filenames, assuming you only >> use the letters of the alphabet and the digits then you would have 62^90 >> different filenames, which is roughly 2E161 (2 followed by 161 zeros), >> which is quite a bit. Hopefully the numbers involved would make it >> infeasible for an attacker to loop through all the permutations. > > But what if the attacker just knows one file's name, for example index.php > or something that's in the url in the browser. Then he/she can stole that > file, read it, and gets other filenames because of includes/requires. > With some work he/she can get all the files without any bruteforce > filename guessing. Well if a php file is parsed to the server, then they can't determine what the orginal included fiels were at all, unless you're dumb enuff to do this: :) If you adopt some of the practices (I think) included earlier in this thread by me, you could restrict browser access to your inc files by the use of smart file naming, dedicated directories and .htaccess files, then this should cover the basics of people grabbing your included files (with passwords etc) via http (browser). It doesn't cover people within the server (others on a shared server, etc) though. Justin French -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Keeping "Secrets" in PHP Files
-Original Message- > From: Peter J. Schoenster [mailto:[EMAIL PROTECTED]] > Sent: Saturday, June 29, 2002 1:27 AM > To: [EMAIL PROTECTED] > Subject: RE: [PHP] Keeping "Secrets" in PHP Files > Yeah, you are assuming an environment that does > not necessarily have to be. Why must one Apache > server serve all users? Simply because that's > the easiest way to do right out of the box? > You have 2 scenarios as I see it: > 1. Your own box -- no troubles other than the > obvious > 2. Virtual Server - One Apache for all users ... > seems insecure > 3. Virtual Server - One Apache for EACH user ... > seems quite secure and experience confirms. Not to be picky but you said there werwe 2 scenarios :-) In any case, your #3 above works as long as each server runs in its own unique group, which is shares with the customer. > Peter -- JR -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Keeping "Secrets" in PHP Files
On 28 Jun 2002 at 17:54, Jonathan Rosenberg wrote: > -Original Message- > > From: 1LT John W. Holmes [mailto:[EMAIL PROTECTED]] > > Subject: Re: [PHP] Keeping "Secrets" in PHP Files > > > With shell access, you can't see each others > > files. This is where the permissions come into > > play, because you are logged into the box as a > > specific user, you can only access your files. > > If I change the permissions > > on my files, you can't see them. > > I've been thinking some more about the issue of keeping PHP > source files secure in a shared hosting environment. I've now > convinced myself that there is simply no way to protect these > files, even if safe_mode is turned on, as long as other users can have > telnet (or ssh) access to the box. snip > I hope wrong. Can anyone find the hole in my reasoning? Yeah, you are assuming an environment that does not necessarily have to be. Why must one Apache server serve all users? Simply because that's the easiest way to do right out of the box? You have 2 scenarios as I see it: 1. Your own box -- no troubles other than the obvious 2. Virtual Server - One Apache for all users ... seems insecure 3. Virtual Server - One Apache for EACH user ... seems quite secure and experience confirms. > http://www.freevsd.org/ > freeVSD is an advanced web-hosting platform for ISPs, educational > institutions and other large organisations. It allows multiple Virtual > Servers to be created on a single hosting server, each with a truly > separate and secure web-hosting environment. This reduces an ISP's > hardware outlay and also lowers the cost of support due to delegated > administration. > > Distributed under the GPL, freeVSD comes complete with a documented > administration protocol and an open-source web-based administration > system. That pretty much describes the server I've used at the company once known as iserver which was bought by Verio and Verio used much of their website but renamed it to viaverio.com (was iserver.com). It looks like they've done the same thing with Oracle. The above people have done it with Linux. I've only used iserver for 7 years now at 3 different companies but that freeVSD really looks good. If someone is using Joe's 4.95 a month hosting solution ...well, what the heck do they expect. Peter -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Keeping "Secrets" in PHP Files
> Thanks for the reply. But changing the ground read permission of > the PHP files wouldn't help, either, would it? Because the other > users who have web sites can just create a PHP file that reads my > PHP files from one of their pages (which would be running in > group "websecret"). > > Seems like this just opens up the same hole. Yes? Yep. If your PHP script can read the file, then any PHP script can read it. They all run as the same user. Again, this is assuming safe_mode is off. I think there are some things you can run along with PHP (maybe only in CGI mode) that'll stop this kind of thing from happening, though. I just don't know what they are...Sudo or something like that ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Keeping "Secrets" in PHP Files
This is a problem that affects many webhosts... the issue is more of trusting other users who have shell access to the server in question... I have been trying to help a hosting company address this issue, but short of dissallowing shell/ssh access their is no way to stop another user logging into the shell and browser other peoples files... If I am wrong then I would like to be enlightened! Which is is hy the company above only give out ssh accounts to users with valid reasons for needing ssh access. > -Original Message- > From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED]] > Sent: 28 June 2002 2:52 PM > To: Erik Price > Cc: php-list > Subject: RE: [PHP] Keeping "Secrets" in PHP Files > > > Thanks for the reply. But changing the ground read permission of > the PHP files wouldn't help, either, would it? Because the other > users who have web sites can just create a PHP file that reads my > PHP files from one of their pages (which would be running in > group "websecret"). > > Seems like this just opens up the same hole. Yes? > > > -Original Message- > > From: Erik Price [mailto:[EMAIL PROTECTED]] > > Sent: Friday, June 28, 2002 9:43 AM > > To: Jonathan Rosenberg > > Cc: php-list > > Subject: Re: [PHP] Keeping "Secrets" in PHP Files > > > > > > > > On Friday, June 28, 2002, at 09:30 AM, Jonathan > > Rosenberg wrote: > > > > > Let's say I am in a shared server environment & the > > provider does > > > NOT have safe_mode turned on. In that case, it > > seems to me that > > > it is "insecure" to keep "secrets" (e.g., DB > > passwords) in a PHP > > > file that is executed by the server. > > > > > > I say this because any other users of that shared > > host can read > > > the PHP file & obtain the secret. There does not > > seem to be any > > > way around this (once again, I am assuming safe_mode is NOT > > > turned on). > > > > Think about it in terms of the permissions on the > > file. The people who > > can read this file are explicitly defined in your permissions. > > > > The catch-22 is that the web server is usually not run > > as root, so it > > doens't automatically get to see your files -- you > > need to give it > > permission to read them just as you would any other > > user. In a shared > > system, if you give "others" permission to read the > > file, the web server > > user can now read the file, but so can everyone else. > > > > However, if there were some way for you to change the > > group association > > of the file to, say, the "websecret" group, and then > > you could close off > > the read permissons of "others" on that file. As long > > as the web server > > is a member of "websecret", and you grant read > > permissions to the group > > for that file, then the web server can read it. > > > > The trick is that in order to change the file's group > > association to > > "websecret", you probably need to be either root or a > > member of > > "websecret", unless the system admins have provided > > some kind of script > > that does this on your behalf. Which means that > > anyone else who has > > this ability can read the file too (since they are a member of > > "websecret"). > > > > It's tough. Shared hosting security is a difficult issue. > > > > > > > > > > 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 > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Keeping "Secrets" in PHP Files
From: "Jonathan Rosenberg" <[EMAIL PROTECTED]> > Let's say I am in a shared server environment & the provider does > NOT have safe_mode turned on. In that case, it seems to me that > it is "insecure" to keep "secrets" (e.g., DB passwords) in a PHP > file that is executed by the server. > > I say this because any other users of that shared host can read > the PHP file & obtain the secret. There does not seem to be any > way around this (once again, I am assuming safe_mode is NOT > turned on). > > Am I correct? Yep. If Apache and PHP can access a file, either directly through the web, or through an include()/require(), etc, then anyone on your machine can access that file. All PHP scripts run as the same user, the Apache user, so the system can't tell the difference between your script including a file, and someone else's script including a file. I thought we covered this about a week ago? ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Keeping "Secrets" in PHP Files
Thanks for the reply. But changing the ground read permission of the PHP files wouldn't help, either, would it? Because the other users who have web sites can just create a PHP file that reads my PHP files from one of their pages (which would be running in group "websecret"). Seems like this just opens up the same hole. Yes? > -Original Message- > From: Erik Price [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 28, 2002 9:43 AM > To: Jonathan Rosenberg > Cc: php-list > Subject: Re: [PHP] Keeping "Secrets" in PHP Files > > > > On Friday, June 28, 2002, at 09:30 AM, Jonathan > Rosenberg wrote: > > > Let's say I am in a shared server environment & the > provider does > > NOT have safe_mode turned on. In that case, it > seems to me that > > it is "insecure" to keep "secrets" (e.g., DB > passwords) in a PHP > > file that is executed by the server. > > > > I say this because any other users of that shared > host can read > > the PHP file & obtain the secret. There does not > seem to be any > > way around this (once again, I am assuming safe_mode is NOT > > turned on). > > Think about it in terms of the permissions on the > file. The people who > can read this file are explicitly defined in your permissions. > > The catch-22 is that the web server is usually not run > as root, so it > doens't automatically get to see your files -- you > need to give it > permission to read them just as you would any other > user. In a shared > system, if you give "others" permission to read the > file, the web server > user can now read the file, but so can everyone else. > > However, if there were some way for you to change the > group association > of the file to, say, the "websecret" group, and then > you could close off > the read permissons of "others" on that file. As long > as the web server > is a member of "websecret", and you grant read > permissions to the group > for that file, then the web server can read it. > > The trick is that in order to change the file's group > association to > "websecret", you probably need to be either root or a > member of > "websecret", unless the system admins have provided > some kind of script > that does this on your behalf. Which means that > anyone else who has > this ability can read the file too (since they are a member of > "websecret"). > > It's tough. Shared hosting security is a difficult issue. > > > > > 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] Keeping "Secrets" in PHP Files
On Friday, June 28, 2002, at 09:30 AM, Jonathan Rosenberg wrote: > Let's say I am in a shared server environment & the provider does > NOT have safe_mode turned on. In that case, it seems to me that > it is "insecure" to keep "secrets" (e.g., DB passwords) in a PHP > file that is executed by the server. > > I say this because any other users of that shared host can read > the PHP file & obtain the secret. There does not seem to be any > way around this (once again, I am assuming safe_mode is NOT > turned on). Think about it in terms of the permissions on the file. The people who can read this file are explicitly defined in your permissions. The catch-22 is that the web server is usually not run as root, so it doens't automatically get to see your files -- you need to give it permission to read them just as you would any other user. In a shared system, if you give "others" permission to read the file, the web server user can now read the file, but so can everyone else. However, if there were some way for you to change the group association of the file to, say, the "websecret" group, and then you could close off the read permissons of "others" on that file. As long as the web server is a member of "websecret", and you grant read permissions to the group for that file, then the web server can read it. The trick is that in order to change the file's group association to "websecret", you probably need to be either root or a member of "websecret", unless the system admins have provided some kind of script that does this on your behalf. Which means that anyone else who has this ability can read the file too (since they are a member of "websecret"). It's tough. Shared hosting security is a difficult issue. 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
