Can denying access to a mod_rewrite folder be unsafe?

Asked

Viewed 423 times

6

I’m thinking of creating a very limited php microframework just for own use, however I came across a situation, most frameworks uses a folder called public and on the generally production servers we point this folder with DocumentRoot through the httpd.conf.

The structures are usually like this:

/home/user/projeto
├── data/
├── vendor/
├── application/
└── public/
    ├── .htaccess
    └── index.php

The vhost is similar to this:

<VirtualHost *:80>
    ServerName myapp.localhost.com
    DocumentRoot "/home/user/projeto/public"
    <Directory "/home/user/projeto/public">
        AllowOverride all
    </Directory>
</VirtualHost>

But as in my case it’s a microframework simple for personal use I thought of using so the folder structure:

/home/user/projeto
├── index.php
├── .htaccess
└── exemplo/
    ├── application/
    ├── vendor/
    └── data/

In this second example the /home/user/projeto/.htaccess this way:

IndexIgnore *

<IfModule mod_rewrite.c>
    RewriteEngine On

    RewriteRule "^exemplo/" "index.php" [L]

    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

Note that I used RewriteRule "^exemplo/" "index.php" [L] to prevent accessing the contents of the folder exemplo/ where you can find the project files, libraries and classes and the folder data/ which is used to save non-public data. Also if accessed like this: http://site/exemplo/ he will execute the /home/user/projeto/index.php.

The reason you want to use the second way is to be able to easily port the application to other servers without having to configure the DocumentRoot and restart Apache, making settings easier.

The question is:

  • Use RewriteRule "^exemplo/" "index.php" [L] to prevent access to the folder exemplo/ where I keep the folders data/, vendor/ and application/ may be unsafe or may cause some other kind of problem?
apache htaccess security-guard

  • I stopped answering because I got a little confused, and although there are no security problems visually, I feel like something is slipping away, because the way it is, the user is practically in the directory exemplo you understand ? He basically already has access to this directory simply because it is in the public directory, the only thing that separates him from the rest is the redirect that is triggered if it is accessed.

  • It wouldn’t be the same as putting multiple files index.php with header(location) in the directory exemplo and those that follow ?

  • Look, disable all the .htaccess and creates a file index,php in the briefcase exemplo with header("location:../"); exit();, and forehead.

  • @Edilson I know how to use header("location:../"); exit(); or header("", true, 403); exit(); works to override access to the example. But please understand that the RewriteRule already overrides access. The question is whether to use the RewriteRule "^exemplo/" "index.php" [L] has some security problem, you understand?

  • 1

    It wouldn’t be the same, but it’s pretty much the same, that’s what I wanted to prove. Although it may seem convenient, I think it would be good if you kept the first form, although it seems more laborious. Still I’m vague the idea.

  • @Edilson would not be the same, because Location redirects in the browser, rewriterule is an internal redirect, that is, a rewritten url. Yes is the point I want to make, why keep the first form that is more laborious? Maybe this answers the question :)

  • 2

    @Guilhermenascimento does not apply to your case, because it is to run in several different places, but only of curiosity: I have a system where the Documentroot is PHP and not the folder. So all the way is managed by PHP, and neither . htaccess uses. Only that there is nothing else static on the site. header("X-Sendfile: $filename"); helps not to overload PHP.

Show 2 more comments

1 answer

2

Normally the verification technique of a constant is used.

So as you showed it is very interesting because it leaves the code clean and free from the gambiarra of constant technique.

The portability of this will depend on how to translate this mod_rewrite for other servers such as Nginx and IIS. But it’s not hard.

As for side effects or security issues, there is no way the user has access as long as the rule is working.

Something that can lead to problems is the fact of using <IfModule mod_rewrite.c>.

The utility of this is to prevent internal error when the server does not have the mod_rewrite.

On the other hand, if the server does not have the mod_rewrite, the rule will not be read and no error will be triggered. This is a little dangerous as it will occur silently leaving the folder unprotected.

One tip is, remove the conditional that checks whether the mod_rewrite is loaded.

However, it is easier to find a server without mod_rewrite than to find a server that offers only a public access folder.

Both cases can exist on the same server. At this point, there is not much output other than using the constant technique.

  • Really maybe this is the only and main problem, we have to take into account the problem of rewriting here - RewriteRule "^exemplo/" "index.php" [L]

  • 3

    Portability and structure without having to configure internally all the time, that was the question. And why it’s simple, too many paragraphs make the text shorter and easier to read.

  • In the worst case we can try to block the access in . htaccess, at least if the rewrite does not work, the person does not get to access the folder. That is if the allowoverride allows, of course...

  • @Bacco then but the Deny works before modules because it is Apache Core, if you create a . htaccess inside the example folder I will not be able to create a route like this http://site/exemplo/test because it will generate HTTP_403, I know it is unlikely to create a route with the same name as the folder, but the idea is to leave it free too.

Browser other questions tagged apache htaccess security-guard

You are not signed in. Login or sign up in order to post.