I am unsure how IIS would react to the settings.php file being outside of the virtual directory or how to configure it. Right now, unless you set the folder to allow for this, you cannot browse files below the root unless specifically allowed. ________________________________ From: development-bounces@drupal.org on behalf of Darrel O'Pry Sent: Tue 1/10/2006 8:41 AM To: development@drupal.org Subject: Re: [development] let's cleanup /misc On Tue, 2006-01-10 at 14:49 +0100, Bèr Kessels wrote:
Op dinsdag 10 januari 2006 14:20, schreef Adrian Rossouw:
The OSX way is far far simpler, and much much cleaner.
But much unsafer (not speaking of OSX vs Unix safety). We discussed before, that PHP files should really live in a non-web-acessible place. -- I kind of have to disagree with this... php files containing sensitive data should not be in a web accessible directory(settings.php)... If you're worried about people uploading randscript.php or rewriting your .php files I think you have other things you need to address like permissions.
The biggest downside of that, indeed, is that the web-accessible files can no longer live in the module directories.
Bèr
Well yeah, thats the point. We don't want anyone to browse to settings.php. Only two things need to be able to access that file... drupal, and the administrator. On Tue, 2006-01-10 at 18:57 -0800, Steven Peck wrote:
I am unsure how IIS would react to the settings.php file being outside of the virtual directory or how to configure it. Right now, unless you set the folder to allow for this, you cannot browse files below the root unless specifically allowed.
______________________________________________________________________ From: development-bounces@drupal.org on behalf of Darrel O'Pry Sent: Tue 1/10/2006 8:41 AM To: development@drupal.org Subject: Re: [development] let's cleanup /misc
On Tue, 2006-01-10 at 14:49 +0100, Bèr Kessels wrote:
Op dinsdag 10 januari 2006 14:20, schreef Adrian Rossouw:
The OSX way is far far simpler, and much much cleaner.
But much unsafer (not speaking of OSX vs Unix safety). We discussed before, that PHP files should really live in a non-web-acessible place. -- I kind of have to disagree with this... php files containing sensitive data should not be in a web accessible directory(settings.php)... If you're worried about people uploading randscript.php or rewriting your .php files I think you have other things you need to address like permissions.
The biggest downside of that, indeed, is that the web-accessible files can no longer live in the module directories.
Bèr
Well yeah, thats the point. We don't want anyone to browse to settings.php. Only two things need to be able to access that file... drupal, and the administrator.
Why not? I really think this is getting crazy, securitywise. * An admin would have to screw up .php configuration badly. * An admin would have to screw it up badly for a *length* of time. * The liklihood of an admin screwing up .php for a *length* of time is about as equal to them screwing up the DocRoot of a virtualhost (thus, exposing a protected settings.php). This stuff just doesn't happen in principle, and the downsides of making it secure for a "just in case" is, IMO, not worth the effort. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Morbus Iff wrote:
Well yeah, thats the point. We don't want anyone to browse to settings.php. Only two things need to be able to access that file... drupal, and the administrator.
Why not? I really think this is getting crazy, securitywise.
* An admin would have to screw up .php configuration badly.
* An admin would have to screw it up badly for a *length* of time.
* The liklihood of an admin screwing up .php for a *length* of time is about as equal to them screwing up the DocRoot of a virtualhost (thus, exposing a protected settings.php).
This stuff just doesn't happen in principle, and the downsides of making it secure for a "just in case" is, IMO, not worth the effort.
Just for the record: I agree with Morbus. If somebody misconfigures Apache it is his fault, not ours. Once again: We can't prevent people from shooting themselves into the foot. Cheers, Gerhard
Just for the record: I agree with Morbus. If somebody misconfigures Apache it is his fault, not ours.
Once again: We can't prevent people from shooting themselves into the foot.
But we can put a safety on a gun... if they still manage to shoot themself in the foot, well, we did our best... Cheers, ted
Theodore Serbinski wrote:
Just for the record: I agree with Morbus. If somebody misconfigures Apache it is his fault, not ours.
Once again: We can't prevent people from shooting themselves into the foot.
But we can put a safety on a gun... if they still manage to shoot themself in the foot, well, we did our best...
The problem is that we do so at a possible cost: More support requests. I am not eager to deal with these. Cheers, Gerhard
Guys Let us proceed with the parts we agree on and leave major reorganizations for security to later discussions. We agree to make upgradability, clean directory structure and separate of core from contrib. Let us go forward with these, and file feature requests for the rest rather than delay everything because we have no consensus.
At 6:19 PM +0100 11/1/06, Gerhard Killesreiter wrote:
Just for the record: I agree with Morbus. If somebody misconfigures Apache it is his fault, not ours.
I agree too. I want my entire Drupal installation in a single directory, inside my DocumentRoot. ...R.
Op woensdag 11 januari 2006 18:19, schreef Gerhard Killesreiter:
Just for the record: I agree with Morbus. If somebody misconfigures Apache it is his fault, not ours.
Sure, I doubt anyone will disgree. But we can do a *lot* to help avoid misconfigurations. oh, and we are not entirely apache-only, are we? -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
But we can do a *lot* to help avoid misconfigurations.
This particular misconfiguration is so rare that we're pushing an awful lot of effort onto the user - regardless of automation (as *knowing* where files are is half the battle) - for something they'll probably never encounter in their life, unlike say, XSS.
oh, and we are not entirely apache-only, are we?
I deliberately didn't mention Apache in my own post because it's a NULL issue: the *frequency* with which it takes to *screw up a server SO BAD* such that a DocRoot is misplaced or PHP is broken, is common equally enough on Apache, LigHTTPD, Zeus, Covalent, IIS, or any other server. It happens *so infrequently* that the software used, or the method in which it is screwed up, doesn't make a damn bit of difference. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On Wed, 2006-01-11 at 11:14 -0500, Morbus Iff wrote:
Well yeah, thats the point. We don't want anyone to browse to settings.php. Only two things need to be able to access that file... drupal, and the administrator.
Why not? I really think this is getting crazy, securitywise.
* An admin would have to screw up .php configuration badly.
* An admin would have to screw it up badly for a *length* of time.
* The liklihood of an admin screwing up .php for a *length* of time is about as equal to them screwing up the DocRoot of a virtualhost (thus, exposing a protected settings.php).
This stuff just doesn't happen in principle, and the downsides of making it secure for a "just in case" is, IMO, not worth the effort.
And just in case is all it is... I don't think it should all be moved around. I was just trying to make a point that if people insist on moving things out of the public drupal tree, that they limit themselves to settings.php. settings.php is the only file in drupal that has the potential to be a security problem if its contents are exposed... The downside of that rarely occurring misconfiguration for say an e-commerce site, is a large liability. Then again its easy enough for the determined to relocate their settings.php. So maybe in light of popular opinion we just need to add the site/all and be done with it. :)
Darrel O'Pry wrote:
And just in case is all it is... I don't think it should all be moved around. I was just trying to make a point that if people insist on moving things out of the public drupal tree, that they limit themselves to settings.php. settings.php is the only file in drupal that has the potential to be a security problem if its contents are exposed...
The downside of that rarely occurring misconfiguration for say an e-commerce site, is a large liability.
Then again its easy enough for the determined to relocate their settings.php. So maybe in light of popular opinion we just need to add the site/all and be done with it. :)
Darrel, any module or theme source file could be a security problem if exposed. You can directly inspect the source code, identify versions, or in case of custom code, examine weaknesses. Any identified publicly available module can possibly contain weaknesses. Goba
On Wed, 2006-01-11 at 22:13 +0100, Gabor Hojtsy wrote:
Darrel O'Pry wrote:
to settings.php. settings.php is the only file in drupal that has the potential to be a security problem if its contents are exposed...
Darrel, any module or theme source file could be a security problem if exposed. You can directly inspect the source code, identify versions, or in case of custom code, examine weaknesses. Any identified publicly available module can possibly contain weaknesses.
Goba
I can infer the version of drupal you are running by the feature set, then examine the code in CVS all day, or night as is my leisure. In the case of custom code, well that's on the developer who wrote it. Although I think XSS is a far more likely way to get my db goodies than accidentally exposing my settings.php. :) Versions can be inferred from features. Authentication information is a security breach which compromises everything.
participants (9)
-
Bèr Kessels -
Darrel O'Pry -
Gabor Hojtsy -
Gerhard Killesreiter -
Khalid B -
Morbus Iff -
Richard Archer -
Steven Peck -
Theodore Serbinski