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.
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'm going to store pdf's on my website so they are available online. Should the directory be outside the root director or is it safe enough to keep it inside the root directory? What is standard practice for storing this type of file. There will not be any sensitive date on the files. I'm worried about the potential of the files being hacked or modified.
If the PDFs are available for general download and you simply link to them, there should be no problem putting them directly into your webroot.
You say you are worried about files being hacked or modified on the server. Bear in mind that if an intruder gains access to your webroot, all bets are off. It doesn't matter at that point if you have PDFs or not in the webroot - because the attacker can just edit your php or asp pages and cause havoc. This would be easier than editing your PDFs and trying to "execute" them.
There are lots of techniques for securing your webroot. Unless you know what you are doing, do not allow file uploads. Disable this at all costs. Next, use the correct permissions on folders. I'm afraid apache/linux is much better for this than windoze. But for instance set permissions so files in the webroot can be read and executed but not written. There are more things you can do, like Apache chroot, but this gets complicated.
Last, bear in mind that by far the most common vulnerability in web applications is SQL injection, so if you are using dynamic pages make sure your are protected against this. Actually gaining access to webroot files tends to be a consequence of a hack rather than the initial hack, unless of course you have set it up all wrong!
This is something I am trying to grasp my head around.
Okay, so Apache simply servers files on a web server to clients. I fully understand that. But then if you install PHP, suddenly PHP code will be interpreted before those files are served by Apache. Then you install MySQL, and all of a sudden PHP can work directly with MySQL.
What is really done in the installation process that allows these three things to work so closely together? If Apache and PHP are separate programs, then how do they both work together on serving files?
Nothing happens suddenly.
TO have PHP work with Apache on Windows, you need to add the following lines in httpd.conf:
LoadModule php5_module "c:\php\php5apache2_2.dll"
PHPIniDir 'c:\php'
AddHandler application/x-httpd-php .php
(This is just referring to my settings) and then restart Apache to start serving PHP requests.
PHP comes with Mysql extension to handle MySQL requests. These days we have PDO/Mysqli extension to (a) avoid SQL injection (b) handle requests more efficiently. However as i mentioned above nothing happens automatically, you have to uncomment following lines in php.ini to make any of these extensions work for you:
extension=php_mysqli.dll
extension=php_pdo_mysql.dll
(Again referring to my php.ini on windows).
Hope that helps.
Thanks
PHP is a server side programming language that handles HTTP requests. It is fully featured and offers alot of helpful functions. Try some tutorials and you'll quickly be ready to use it.
HTTP requests are:
GET - which allows you to read data from your where you are storing data. This is done commonly with a database(MySQL) query
POST - For posting user data, commonly from HTML forms. PHP allows you to access this global variable $_POST['example'] and store it in the data.
PHP basically allows you to Create, Read, Update, Destroy (CRUD) with Databases.
What is really done in the installation process that allows these three things to work so closely together? If Apache and PHP are separate programs, then how do they both work together on serving files?
They work together because you allow them to. In your php script you must connect to a sql database before you are able to use that database. look up "mysqli_connect()" in php documentation. HTML pages call PHP scripts usually through a user input form. So that on submit you add to a database. But they must be on the same server and domain! the same locality of all programming still applies.
Im just done with a cakephp website, but im still in a doubt on what are the things that I must take care of, before making this website live.
Since it is a big application that require users to Register and Login and to manage their accounts. Any sort of help is appreciated.
Thanx.
There is a section in the CakePHP book answering directly that:
http://book.cakephp.org/2.0/en/deployment.html
Harden instillation, set production mode if you are using different SQL services, disable php error reporting, enable caching, disable and remove all client side debugging like DebugKit, make sure any comments in your html will not give hackers an advantage like printing variables.
Php frameworks can be resource hogs. I think the last but most important is to test server with some generated traffic. There are services that can do this for you. You may need to separate resources or set up an additional server for SQL if you expect a lot of traffic.
There may be a couple other things you might want to do.. Just browse your core.php and bootstrap.php. Make sure everything is working is correctly for production environment.
Here are some common but important things to be taken care of before making cake website live.
Check for read/write permissions on desired folders.
Check for images,js files and css files you need on your website .
Check for writable temp folder and clear cache.
Set debug level to 0.
Make sure database connectivity works fine.
As a follow up to an earlier question that attracted a whole zero answers, I'm wondering about the possibilities of allowing a web server (apache) to write to its own document root (Linux), in order to dynamically create meta-redirect files.
Of course, this sounds incredibly dangerous, and I'm wary of going the whole hog and granting the web-server user full write-access to its own docroot. Is there a more appropriate way of achieving this?
Use mod-rewrite, mapping to a program that you write to do the rewrites based on database records or some other mechanism.
Instructions here:
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
Look for: "External Rewriting Program" on the page
Edit (from Vinko in the comments, 2.2 docs)
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritemap
What's usually done is to allow writes only to subdirectories, hopefully located in a noexec mounted partition.
That said, it seems to me that you should just create a set of RewriteMap directives to do your dynamic redirection, there's no need to write files in the document root to accomplish that.
I answered similarly in the other question, just for completeness.
This is incredibly dangerous if you are trying to achieve what your previous question was getting at.
If you are going to go this route, you'll want a ton of testing to prevent people from forcing webserver instructions into htaccess files.