First of all, sorry if the question is unclear due to my poor knowledge.
I'm interested to know how apache calls the appropriate engine/invoker to serve a request. Suppose, user requests a http://somesite.com/someurl.php - now how apache determines that it needs to launch the PHP interpreter? Does apache determines so based on the file extention/MIME type or anything else?
What I know is: I can configure apache to invoke certain interpreters based on file's extension, by something like:
AddHandler cgi-script .cgi .py
# Tells apache to treat .cgi & .py files to treat as cgi scripts
Why I'm concerned about it? Recently, I came to know from my question ( PHP file upload: mime or extension based verification? ) that if some user uploads a file with wrong MIME type (i.e image/jpeg) but with an extention .php the file can get executed (assuming it has got execution permission) and malicious php code included with the EXIF meta-data can do harmful things.
It depends entirely on how the server is configured. By default, Apache always uses the default handler which simply serves the content of the file. However, you can change that using the SetHandler directive. This directive can be placed literally anywhere in the configuration, including <Files> or <Directory> or <Location> blocks, making it possible to set the handler based on the filesystem path, URL prefix, or pretty much any other variable Apache can access.
It is particularly common to set the handler based on the filename extension, though, so Apache provides the AddHandler directive as a shortcut for doing so.
For more details, have a look at the handler documentation.
P.S. For what it's worth, filesystems normally don't store MIME type data, so Apache normally has to guess at the MIME type of a file by examining the extension.
Related
I am trying to decide whether to use .htaccess files in each sub-directory to deny all requests for specific files (while also denying directory indexes), or whether it is more security conscious to move all files except for essential files (index.php, .htaccess, robots.txt) outside the root directory and call them from the index file.
Are there any critical differences in security between these two methods for securing files in my web application?
Here is a view of what the .htaccess looks like in the root directory.
# pass the default character set
AddDefaultCharset utf-8
# disable the server signature
ServerSignature Off
<FilesMatch "\.(htaccess|htpasswd|ini|phps|fla|psd|log|sh|lock|DS_Store|json|)$">
order allow,deny
allow from all
</FilesMatch>
# disable directory browsing
Options All -Indexes
# prevent display of select file types
IndexIgnore *.wmv *.mp4 *.avi *.etc
However, this would not stop someone from accessing a file if they knew the directory structure such as https://www.example.com/security/please_dont_look.cfg
Although that file does not print anything, I don't want anyone to know it exists, and don't want a site-specific solution like using modredirect to redirect calls to specific files.
I could use a .htaccess file in each directory such as this:
order deny,allow
deny from all
From this question and reply (Prevent access to files in a certain folder)
Is one solution more bullet-proof than the other?
As always in such complex systems, security here is about having several lines of defense, keeping things simple and attempting to prevent as many attack vectors as possible.
Theoretically both solutions should provide you with the exact same level of security - the files would not be accessible in either case.
I'd recommend moving files that should not be accessed directly into a directory outside of the web root directory. It is quite easy to screw up htaccess files and thats just not possible when you move the files outside of your webroot. This will also prevent timing attacks against the directory structure of your server: reading htaccess files comes with a time penalty and that might be measureable, especially if your htaccess files get big and you have plenty of them for each sub directory. Actually I'd recommend skipping htaccess entirely, just disable indexes directly in your vhost configuation, such that Apache does not have to look for htaccess files at all, speeding up your website.
Additionally, in case you run php via fcgi, you should disallow file access on a file system level for apache and just allow access from php. With this setup it should be outright impossible to access your files by attacking the webserver (excluding php) unless you have some privilege escalation vulnerability (in which case you are screwed anyways).
The only way to access your confidential files in this setup would be to convince PHP to read the file or to mess with the file system, i.e. by creating a hard link from your web root into your "confidential files outside web root"-directory. Preventing against that boils down to ensuring your PHP configuration is as restrictive as possible, file creation inside the webroot is disallowed and, most importantly, ensuring that the PHP application itself is not vulnerable.
Im not that familiar with Apache.
When using <Location>, I am able to redirect users to a sign-on page, forcing them to authenticate and have proper privileges before accessing the URL.
When using <Directory>, it is supposed to allow me to control access to specified folders and directories, right?
Question:
How does <Directory> behave similarly and differently from <Location>?
With <Location /web>: www.mysite.com/web and www.mysite.com/web/foo will be controlled.
With <Directory /webforms>: how will www.mysite.com/web look like if some of the scripts are from that folder?
With <Directory /pictures>: how will www.mysite.com/web look like if some of the picture are from that folder?
What about a situation where you have both types of directives active and affecting a single page? What kinds of things should I expect or watch out for?
The Apache HTTP server documentation has a section called What to use When which, I think, directly, answer your question :
Choosing between filesystem containers and webspace containers is actually quite easy. When applying directives to objects that reside in the filesystem always use <Directory> or <Files>. When applying directives to objects that do not reside in the filesystem (such as a webpage generated from a database), use <Location>.
The important part is the following :
It is important to never use <Location> when trying to restrict access to objects in the filesystem. This is because many different webspace locations (URLs) could map to the same filesystem location, allowing your restrictions to be circumvented.
Read on for more information...
I've made a cookbook in Chef to install a web application, Apache and PHP.
This web application has a PHP document that clients access in this URL:
http://localhost/www-app/ClientFE
With this I have a problem. By default PHP will only interpret documents that have a PHP extension, and as my URL doesn't have it, it gets interpreted as text. I can't change the file's extension because the client (which is also software) should not be modified.
What I want to accomplish is to make PHP interpret that document, and for what I've investigated it can be accomplished in three ways at least: configure appropriately PHP, create an alias, create a rewrite rule.
First: I could configure PHP to interpret the desired document:
<FilesMatch "/www-app/ClientFE">
SetHandler application/x-httpd-php
</FilesMatch>
Second: I could do it through mod_write (I would have to rename the fill in the web app, which is also acceptable for me):
RewriteCond ^/www-app/ClientFE /www-app/ClientFE.php
Third: I could do it with mod_alias in a similar fashion than mod_rewrite.
The 3 are good for me, but my problem is: how to do them with Chef ? I haven't been able to find useful docs about it, and I have already tried to put this in my recipe (I found them around the Internet but they haven't worked):
apache_rewrite do
source "/www-app/ClientFE"
target "/www-app/ClientFE.php"
end
and this
apache_module "alias" do
source "/www-app/ClientFE"
target "/www-app/ClientFE.php"
end
Some people in my company suggested 2 valid solutions:
Put the configuration in a .htaccess inside my web application. This works for me and allows to use the alternatives I mentioned above.
Do nothing! It happens that the Multiviews option in the Apache2 cookbook is enabled by default, and it allows Apache to resolve URL http://localhost/A as http://localhost/A.php .... I mean, if Apache is asked about file A, and it doesn't find it, then it will search for A.php instead.
From the two, I chose the later, and yes, it works. It wasn't working before because in my many attempts I created both A and A.php and in that case the Multiviews has no effect.
Some people say that to enable compression you modify htaccess file:
apache compression Deflate .js and .css files not compressed?
http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/)
Others say you need to update httpd.conf file
http://kb.mediatemple.net/questions/1567/Compressing+web+pages+with+mod_deflate#dv
What is the right way? If either is correct then wouldn't htaccess be a better choice since it doesn't require web server restart?
The Apache HTTP Server can be configured in a number of ways: The main configuration file is (usually) called "httpd.conf", but this file can include other configuration files with the "Include" directive. Furthermore, the HTTP Server allows for configuration files to be placed in the context path of your website. These decentral configuration files are (usually) called ".htaccess".
Configuration directives, like the directives to enable compression, can be valid in different contexts. The valid configuration contexts of the "AddOutputFilter", the "SetOutputFilter", and the (deprecated) "AddOutputFilterByType" all specify "server config, virtual host, directory, .htaccess" as their valid configuration contexts. Therefore, all of these directives can be used in the "httpd.conf" as well as in the ".htaccess" configuration files.
So both ways of configuring output compression are valid, and it's just a matter of taste whether you want all your server configuration in one central file (which gets only read during server (re)start) or whether want to spread the configuration in multiple files and directories (but get the benefit of changes being applied instantly).
If your Web Host is through C Panel
Enable G ZIP Compression on Apache C Panel
Go to CPanel and check for software tab.
Previously Optimize website used to work but now a new option is available i.e "MultiPHP INI Editor".
Select the domain name you want to compress.
Scroll down to bottom until you find zip output compression and enable it.
Now check again for the G ZIP Compression.
You can follow the video tutorial also.
https://www.youtube.com/watch?v=o0UDmcpGlZI
I've taken over development of a fairly heavy-duty LAMP application. The original dev used an .htaccess file with RewriteMap and a PHP script to handle certain conditions of the app.
Specifically, when certain subdomain patterns are requested by the client, the RewriteMap catches them and sends them to the appropriate application module.
I'm quite comfortable with typical mod_rewrite redirects, and I think I've got the basic RewriteMap concept figured out; but I'm struggling to find decent documentation on how RewriteLock works. According to the Apache docs:
This directive sets the filename for a synchronization lockfile which mod_rewrite needs to communicate with RewriteMap programs. Set this lockfile to a local path (not on a NFS-mounted device) when you want to use a rewriting map-program. It is not required for other types of rewriting maps.
But this is still a little vague for me. Whats the exact purpose and function of RewriteLock and how does it work?
RewriteLock is used with the prg: keyword. RewriteMap can be used with several keywords, to use text files (txt:), hashfiles (dbm:), randomized text (rnd:) or external mapping scripts ( this one is the prg: keyword ). In this mode the external script is launched when apache start. Then for every incoming request, when mod-rewrite is calling the prg: mapping, apache sends input to that script and reads the output stream to get the value.
RewriteLock must be used in that case to prevent parallel requests (so parallel inputs to that external process) to mix answers on this process standard output. It's a locking mechanism (a file, the given path, which is a classical token, only one user) to enforce serialization of the calls to this external mapping script. IMHO it should be transparently applied by mod-rewrite when using prg: as I never found a prg case where this locking thing is not mandatory.
Edit:
Well in fact you could use an external prg: without the rewriteLock if randomization of the output is not a problem, i.e. for a given entry you can get a response which was given for another entry, like in a script doing some advanced rnd:, your own round-robin service. But if the output must reflect the entry, then you need that semaphore, which of course can slow down the rewritemap process.
So if you're only using the hashmap or textmap you do not need to set the RewriteLock.
Edit:
You may find useful details on this thread, like the fact the lock file exists only for a few milliseconds, when apache calls the prg and waits for an answer.
Edit:
On the question one strange fact is:
The original dev used an .htaccess file with RewriteMap
This is strange because RewriteMap cannot work on .htaccess files, .htaccess are configuration entries read dynamically and RewriteMap as stated here in the Context line can only be set in the main configuration or in a VirtualHost configuration. It cannot be in a Location, a Directory or a .htaccess. So chances are this will never work in a .htaccess.
Now #puk asked for an example of RewriteMap usage. Well, searching for "RewriteMap" in Stack overflow will show you several real examples:
here in a question
here a list of example in my answer
another here
Apache hangs if you define more than one RewriteLock directives or if you use it in a VHOST config.
The RewriteLock should be specified at server config level and ONLY ONCE. This lock file will be used by all prg type maps. So if you want to use multiple prg maps, I suggest using an internal locking mechanism, for example in PHP there is the flock function, and simply ignore the warning apache writes in the error log.
See here for more info:
http://books.google.com/books?id=HUpTYMf8-aEC&lpg=PP1&pg=PA298#v=onepage&q&f=false