There are all sorts of posts out there that advise you on how to add a .htaccess file to remove index.php from the URL. However, in order to get .htaccess files to work, the AllowOverride must be changed (usually to "All").
This tutorial explains that using .htaccess files for mod_rewrite is a misconception and can and should be done in the main config file.
I have been informed by my web security officer that - and I quote - "to change AllowOverride to All increases the risk to the web server as, if exploited, an intruder / hacker / opportunist could override the main servers configuration, which could allow them to get up to allsorts; this would be a serious security breach". I'm not sure how much weight this holds!
So my question is;
are there really serious dangers to changing the AllowOverride
and if so, why is .htaccess being recommended for removing index.php so widely on Stack Overflow?
Well there is little bit of security issue with .htaccess in the sense that if a hacker/intruder gets hold of your file system then they can modify rewrite rules and change the behavior of your website. However do remember that if a hacker gets hold of your DOCUMENT_ROOT folder then a lot more damage can be done by modifying/deleting any other code as well and you have much bigger problem in your hand.
However what .htaccess provides you is utmost flexibility by letting you control your website behavior, authentication needs without need to make those changes in Apache config and restart it every time. Especially in a shared hosting environments Apache config is not even accessible for website owners.
Related
couldn't find the right answer so here goes my question:
We've moved our webshop to a different platform (from Virtuemart to Opencart 2.0.3.2).
the old links around the internet leading to our products are like https://www.name.ext/category/productcode-detail
the new links come without the '-detail' at the end of it
I've found an extension that'll add the -detail to the product links, but I'd rather have a .htaccess redirect to remove '-detail' on those specific links.
This way, all links on the internet are still valid (but redirected) and Google e.g. can redo the indexing whilst not loosing all SEO earlier.
Can it be done?
Considering your comments to the question this probably is the correct approach. I fail to understand why you couldn't find an answer to this here on SO, it looks absolutely straight forward.
I assume that "category" is meant as a placeholder which can actually take different forms. Same with the "productcode". Since you did not provide any pattern or similar this suggestion is generic:
RewriteEngine on
RewriteRule ^/?(\w+)/(\w+)-detail$ /$1/$2 [R=301]
Note however that your question is vague. I assume that you need to tweak that suggestion, so that other references won't break. Most likely you need a blacklist to prevent some not product related stuff from getting rewritten. But again: since your question is vague there is nothing more specific we can suggest than the above.
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
This implementation will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I do write my htaccess-file by PHP and now I have read, that this is a scurity issue, because the htaccess-file's owner is www-data, when the file is created via PHP.
I also create a config.php which contains the mysql-creditentials.. this is also www-data then..
my question is, is this really a security-issue? how could this be exploited?
If .htaccess is writable by PHP, as it is purposefully in your case, that means if anyone is able to leverage any security problem in your PHP code they may be able to write to the .htaccess file, which might give them even more leverage to execute more arbitrary code.
For instance, some vulnerable file-uploading PHP code is tricked into writing an .htaccess file which configures Apache to execute .jpg files as PHP; and then another uploaded JPG file which actually contains PHP code is saved into the webroot folder where it can now be executed as PHP code. Et voilà, arbitrary PHP code execution.
Another nice scenario would be a rewrite rule turning your server into a reverse proxy forwarding requests to some other server and lending a hand in some DDoS attack against a 3rd party.
The point is that your web server wields a lot of power with its configuration, and .htaccess files allow you to change that configuration, and allowing PHP to change .htaccess files moves that power and the responsibility to use that power correctly into PHP. Which means you now need to be 100% certain that there are no exploitable bugs in your PHP code which could lead to somebody abusing that power.
It's always better to segregate powers and give individual pieces as little power as possible. There are probably much better approaches for whatever you're trying to do there that do not require dynamic reconfiguration of your web server by programmatically generating .htaccess files.
I am being informed by the team that manages the servers that enabling mod_rewrite will excessively compromise the server security.
Are they correct?
What can be done to make sure sever security is minimally compromised if at all after enabling the mod_rewrite.
I am not able to clean up joomla urls without mod_rewrite enabled.
Thanks in advance!
They're not correct as the issue depends exactly how "mod_rewrite" is tuned.
You can:
Enable "mod_rewrite" for your specific site/virtualhost and not other sites by using directives such as [RewriteEngine On] and then tune the rewrite code to handle what to do should someone ask for inappropriate url etc.
Remember the server itself is tuned by using other directives and the code within "mod_rewrite" block needs to handle itself as a block.
Here is docs and examples of "mod_rewrite" blocks
http://httpd.apache.org/docs/current/mod/mod_rewrite.html
mod_rewrite together with poorly crafted rewrite rules can potentially weaken your security but as with any server software, the key to keeping your server secure is to configure the software properly and keep it up to date.
mod_rewrite is widely used in conjunction with WordPress, Joomla and Drupal and it seems unlikely that this would be the case if it "excessively compromises" security.
Not using mod_rewrite could be a security issue too as the native Joomla URLs are visible and this gives hackers information about the extensions you have installed on your website.
Reference: https://stackoverflow.com/a/5009900/1983389
I'm trying to decide whether to use Magento or create my own platform and I was wondering about security. Does Magento's code include some sort of brute force protection? If not, is this not something important?
Protect your Magento Store to Brute force attacks. Follow following step.
Apache Server Users
To whitelist an IP address for the admin panel, add the following rule in root .htaccess file (inside <IfModule mod_rewrite.c>)
RewriteCond %{REMOTE_ADDR} !^xx.xx.xx.xx
RewriteRule ^(index.php/)?admin/ - [L,R=403]
To whitelist an IP address for the RSS feed, add the following rule in the root .htaccess file (inside <IfModule mod_rewrite.c>):
RewriteCond %{REMOTE_ADDR} !^xx.xx.xx.xx
RewriteRule ^(index.php/?)?rss/ - [L,R=403]
To whitelist an IP address for the downloader application, add the following rule in ./downloader/.htaccess file:
order deny,allow
deny from all
allow from xx.xx.xx.xx
So I know this is an old thread but I found it searching for answers on how to protect Magento against brute-force attacks. The things have changed since 2012, so I want to point the people looking for information about Magento security in (hopefully) the right direction.
Seems like Magento has finally decided to stop ignoring the problem of increasing number of brute-force attacks on Magento websites so they have published an official list of recommended steps on how to protect Magento from such attacks: https://magento.com/security/best-practices/protect-your-magento-installation-password-guessing
Hosting companies also started offering solutions to block these hack attempts, from blocking and blacklisting IPs to installing filtering software.
There are also several security extensions including a good number of Two-Factor Authentication ones. In my opinion the most complete security extension currently available is MageFence by ExtensionsMall. Here's a link on Magento Connect: magentocommerce[.]com/magento-connect/catalog/product/view/id/30596/. It has many useful features like scanning your website for malware and vulnerabilities, blocking IP addresses after too many failed login attempts and it comes together with Two-Factor Authentication module.You can also check out MageFence page on ExtensionsMall website to get the idea of all the security holes this module will help you patch up.
The only brute-force protection Magento has is in case of gift cards. When throwing exception there, Magento obscures real exception message (but puts it in logs) and shows 'Wrong gift card code' message instead.
When it comes to login forms, Magento has no brute force protection.
If this is an important factor for you when deciding whether use Magento or write your own platform, remember that you could write your own Magento module that introduces some brute force protection. This would be way less time-consuming than writing own platform with functionalities similar to Magento.
I did a quick search on the Magento Connect and found one extension that, among other things, provides brute force protection. Here it is: http://www.magentocommerce.com/magento-connect/market-ready-germany.html. You can download it using Freegento website and look into the code for clues on how to make something similar.
I know very little about Magento and did not build the site in question myself, but I discovered a client's website's local.xml file was publicly accessible- http://domain.com/app/etc/local.xml which contained the username and password.
I assume that this file shouldn't be publicly accessible, but doesn't Magento automatically block access (by sending a 403 header)?
What are the security implications for this?
The world would have your DB connection information, also the crypt key is right there so they can break all your customer's secure information.
Magento blocks access to etc from app via .htaccess in that directory.
Order deny,allow
Deny from all
How to move your local.xml to be outside your web root directory structure.
In addition to database and encryption key information it can contain info about cache servers.
In a standard Magento installation, that is correctly configured having local.xml file publicly accessible is not a security threat.
That said, if there would occur any deviation from the standard server configuration, and in one way or another it would become possible to read the file all other security measures you might have in place would become absolute.
As such, its highly recommended to have this file not publicly accessible, as a failsafe, if not anything else.