I've been doing web development for about 6 months now for fun and so I never really had a reason to be secure. Now I want to change that but I'm having a hard time understanding apache file permissions. I created the server and usually just ran var/www with 777 permissions because I needed to get by and didn't have information worth stealing. I researched user permissions and now I have run into a problem after configuring some things. I added the apache user "nobody" to a group I created called webserver, I also have an ftp user in this group. I set var/www permissions so that "me" and the group webserver have full permissions on for the folder and enclosed files and other users have no rights (can't read). When I attempt to view my sample website on 'localhost' I get a permission denied message from apache, but apache has full ownership of the file so why can't it process the file, send the appropriate response the the computer which requested it, and complete the transaction? Does Apache process http requests as a different user? I'm confused.
Usually on Ubuntu, apache run with the user www-data.
You can also pimp it by editing APACHE_RUN_USER and APACHE_RUN_GROUP in the envvars file.
Related
We have intranet website that is deployed on IIS 6 with windows authentication and ASP.Net Impersonation enabled. It works perfectly, but when we moved to IIS 8.5, logging (to a log file) seems to stopped working. When we ran Process Monitor, it shows access denied to the folder where logs are written. And it also shows that, it is impersonating logged in user to write the logs. Where we want the system to use app pool user to log. I tried everything available on internet, changing entries in applicationhost.config to adding location paths and adding web.config to that particular location, nothing seems to work.
Update:
Just executed Process Monitor on old server and below is the comparison. it is exactly same, except new server denies the access. In both the cases, impersonating user (logged in user) tries the access to folder. I think something to with OS. Old server us Windows Server Standard and new one is Windows Server 2012 R2 Standard.
Old Server
Operation:CreateFile
Result:SUCCESS
Path:XXXXX\log.txt
Desired Access:Generic Write, Read Attributes
Disposition:OpenIf
Options:Synchronous IO Non-Alert, Non-Directory File, Open No Recall
Attributes:n/a
ShareMode:Read, Delete
Impersonating:domain\username
OpenResult:Opened
New Server
Operation:CreateFile
Result:ACCESS DENIED
Path:XXXXX\log.txt
Desired Access:Generic Write, Read Attributes
Disposition:OpenIf
Options:Synchronous IO Non-Alert, Non-Directory File, Open No Recall
Attributes:n/a
ShareMode:Read, Delete
Impersonating:domain\username
I installed mediawiki on a webserver to some folder
drwxr-xr-x /server/web/mediawiki
This directory contains a file LocalSettings.php. Initially this file contained DataBase settings (user/password) as plain text.
Following the guide
https://www.mediawiki.org/wiki/Manual:Securing_database_passwords
1 I tried to read protect LocalSettings.php with chmod
-rwx------ LocalSettings.php
and got an error when tried to reload mediawiki page in web-browser
failed to open stream: Permission denied in .../includes/WebStart.php
So I had to give reading access to LocalSettings.php to proceed
-rwx---r-- LocalSettings.php
So, easy way didn't work for me for some reason.
Question 1: if you know why easy way didn't work, please, explain me.
2 Than I followed the other way described in the guide. I cut all the DataBase settings (user/password) from the LocalSettings.php to an external file (DBpsw.php) that I placed outside of the web accessible folder:
drwxr-xr-x /home/mediawikiDBpsw/
-rw-r--r-- /home/mediawikiDBpsw/DBpsw.php
and included /home/mediawikiDBpsw/DBpsw.php to the /server/web/mediawiki/LocalSettings.php
But as you can see, the folders /server/web/mediawiki, /home/mediawikiDBpsw/ and the files /home/mediawikiDBpsw/DBpsw.php , /server/web/mediawiki/LocalSettings.php are accessible to others (readable). Thus anyone "other" who has access to the server can ssh to the folder /server/web/mediawiki read the file LocalSettings.php, learn the path /home/mediawikiDBpsw/DBpsw.php from there and read the DataBase settings (user/password) from /home/mediawikiDBpsw/DBpsw.php.
Question 2: How can I protect DataBase settings (user/password) from the "other" users that have access to the server?
Thank you in advance!
The group of the file /home/mediawikiDBpsw/DBpsw.php with DataBase settings should be changed to the webserver's user group (use chgrp).
Than rights of the file should be changed to (use chmod)
w-rw-r----- /home/mediawikiDBpsw/DBpsw.php
Now, mediawiki will run, because webserver's user will have access to the DataBase settings. Still DataBase settings will be safe as others will not have reading access to /home/mediawikiDBpsw/DBpsw.php (unless they are in the same group as webserver's user, which shouldn't be the case).
i have read many tutorials about file permissions but all they say is for example "if you don't want others to write to your files, set it to xxx..."
but in a web host, who is who really?
there is just a web server (apache) and php and mysql and other programs. there is no "other users". the tutorials said that apache is considered "public". but i have a php scripts wich gets an uploaded file and puts it in "downloads" directory. i set that directory's permission to 744. it means group and public should only be able to "read" and owner has full access.
i expected my uploaded file not to be transfered to that directory because of no "write" permission for "public". but the file was there. and more confusing for me was when i tried to download the file, i got a "forbidden" error. i expected to be able to download the file because the public had the "read" permission.
The user this case is the web server itself. Apache is usually running as the user "apache" or "www-data" when it reads and writes files to the server filesystem. Static content should be readable by the server. Upload locations must be writable. Depending on the other users on the system you may consider the web server to be the "other" user and the webmaster account the actual file owner.
An .htaccess file is uploaded to a directory via ftp, the owner and group of the said file is then generally the ftp user and / or root.
If the said directory had file permissions set to 0777 would it at all be possible for a remote script to write over the said .htaccess file, or would every attempt always be blocked as the owner and group of the .htaccess file is the ftp user (and the root), and the hacker (depending on which port they were attempting to enter through) will not be logged into the server as the ftp user (and hopefully not the root user either).
The reason I ask is because I have the need for a directory to be permissions 0777 and am concerned that the .htaccess file (which prevents scripts from running in the said directory) could simply be overwritten meaning the said server would be vunerable to attack.
Thanks,
John
Personally, I wouldn't set 0777 permissions on a directly containing a .htaccess file. In that situation I would probably advise moving the files requiring 0777 permissions into a sub directory.
You're going to be vulnerable to an attack if a script has write access to that folder regardless. Here's an example from a true story on a friend's server:
Old version of TimThumb allowed files to be uploaded maliciously
The file uploaded was Syrian Shell, a script used to decrypt user permissions and begin creating new files
Access was given to the intruder and the server was effectively turned into a host for a phishing site.
I highly recommend you take a look at your structure. Move write access to a subdirectory. Hope this helps.
Here's what I need to do -- either:
include an external file in my .htaccess file that resides on Server B, or
parse the .htaccess file on Server A using PHP, or
even a more clever solution (which I can't dream up at this time given my limited experience with httpd.conf and apache directives)
Background
I have an .htaccess file on Server A. I set its permissions to -rw-rw-rw (0666) and build it dynamically based on events throughout the day on Server B in order to achieve certain objectives of my app on Server A. I have since discovered that my hosting provider sweeps their server (Server A) each night and removes world writable files files and changes their permissions to 0664. Kudo's to them for securing the server. [Please no comments on my method for wanting to make my .htaccess file world writeable -- I truly understand the implications]
The .htacess file on Server A simply exists to provide Shibboleth authentication. I state this because the only aspect of the apache directives that is dynamic is the Require user stack.
Is it possible to include the "user stack" that resides on Server B in my .htaccess file that resides on Server A?
Or can I parse the .htaccess file on Server A via the PHP engine?
Thanks for helping my solve this problem.
Here's what the .htaccess looks like:
AuthType shibboleth
AuthName "Secure Login"
ShibRequireSession on
Header append Cache-Control "private"
Require user bob jill steve
All I want to do is update the bob jill steve list portion of the file each and every time I add/change/delete users in my application in an effort to make my Shibboleth required users (on Server A) synch with my MySQL/PHP web app (living on Server B).
(Version 2 of this post missed the Require user point on first reading -- sorry).
My immediate and my second instinct here is that dynamic .htaccess files (especially designed to be written from a separate web service) are a disaster waiting to happen in security terms and your hosting provider is right to do this, so you should regard this as a constraint.
However there is nothing to stop a process on server A within the application UID (or GID if mode 664) rewriting the .htaccess file. Why not add a script to A which will service an "htaccess" update request. This can accept the updated Require user dataset as (JSON encapsulated, say) parameter, plus some form shared secret signature. This script can include any necessary validation and update the htaccess file locally. Server B can then build the list and initiate this transfer via web request.
Postcript following reply by Dr DOT
My first comment is that I am really surprised that your ISP runs your scripts as nobody. I assume by this that all accounts are handled the same and therefore there is not UID / GID access control separation of files created by separate accounts -- a big no-no in a shared environment. Typically in suEXEC /suPHP implementations any interactive scripts run in the UID of the scriptfile -- in your case, I assume your ftp account -- what you anonymise to myftpuser. All I can assume is that your ISP is running shared accounts using mod_php5 with apache running as nobody, which is very unusual, IMHO.
However I run a general information wiki for a doctor which is also set up this way, and what I do is to have all of the application writeable contents in (in my case) directories owned by www-data. There is surely nothing stopping you setting up such a directory with its own .htaccess file in it -- all owned by nobody and therefore updateable by a script.
If you want a simple example of this type of script see my article Running remote commands on a Webfusion shared service.
Here's how I solved the problem a few days ago.
Given my HSP sweeps the server every night and changes any world writable file to 664 I thought about a different approach.
I did this:
during the day I made the directory containing my non-writable .htaccess file to 0777
then I deleted my .htaccess file
then I re-ran my script -- my fopen() command uses mode "w" (so I thought...if the file doesn't exist right now, why not let my php script create it brand new.)
because I said somewhere above here that my php runs as "nobody" -- voila!!!! I now had a file owned by nobody in the directory
Later that night my HSP swept the server and changed my directory from world writable -- but no big deal ... I got my .htaccess file owned by "nobody' and I can update the Require user directive automatically.
Thanks for everyone's help on this.