Security: Check your RewriteBase settings

Community Articles
#1

Kirby's default .htaccess file includes a set of rewrite rules for Apache, which should block access to text files within the content folder and all other files in the kirby and site folders. This is a security measure to avoid unwanted access to sensible files.

Unfortunately it turns out that in various shared hosting environments, those blocks lead to unwanted redirects and can reveal the full path to the accessed file on the server. This only happens if you browse directly to one of the blocked files, but is still an issue.

In order to fix this immediately you should change the following lines in your .htaccess file:

Old setup

# block text files in the content folder from being accessed directly
RewriteRule ^content/(.*)\.(txt|md|mdown)$ /error [R=301,L]

# block all files in the site folder from being accessed directly
RewriteRule ^site/(.*) /error [R=301,L]

# block all files in the kirby folder from being accessed directly
# RewriteRule ^kirby/(.*) /error [R=301,L]

More secure new setup

# block text files in the content folder from being accessed directly
RewriteRule ^content/(.*)\.(txt|md|mdown)$ index.php [L]

# block all files in the site folder from being accessed directly
RewriteRule ^site/(.*) index.php [L]

# block all files in the kirby folder from being accessed directly
RewriteRule ^kirby/(.*) index.php [L]

If you haven't modified your htaccess file at all, you can simply replace your existing file with this one:

https://raw.githubusercontent.com/getkirby/starterkit/master/.htaccess

If you don't use Apache, you are not required to make any changes. Just make sure you have similar blocking rules in place and they work as expected.

I've already updated all .htaccess files in all kits and downloads to avoid any future problems.

For additional security instructions, please refer to:
http://getkirby.com/docs/security

Please make sure to let me know if you have any questions: support@getkirby.com

This is a companion discussion topic for the original entry at http://getkirby.com/blog/check-your-rewrite-base
3 Likes
Shopkit commerce plugin
#3

Sorry, but I couldn’t stand the banner. I think that the global pins are much easier to read and still very visible.

#4
#5

And for Nginx? Do we have to change anything, currently we have something like:

location ~.php$ {
include /usr/local/etc/nginx/conf.d/php-fpm;
}

Adaptive Images - Resize images in folder, excluding those listed

http://adaptive-images.com/

Nginx re-write code from https://gist.github.com/netProphET/5338672

rewrite ^/(?!ai-cache|assets|bower_components|kirby|panel|site|styleguide|thumbs).*.(jpe?g|gif|png)$ /adaptive-images.php last;

Kirby

Cache Plugin

location /assets {
if (!-e $request_filename) {
rewrite ^/(.+).(\d+).(js|css)$ /$1.$3 break;
}
}

block content

location ~ ^/content/(.).(txt|md|mdown)$ {
rewrite ^/content/(.).(txt|md|mdown)$ /error redirect;
}

block all files in the site folder from being accessed directly

location ~ ^/site/(.)$ {
rewrite ^/site/(.)$ /error redirect;
}

block all files in the kirby folder

location ~ ^/kirby/(.)$ {
rewrite ^/kirby/(.)$ /error redirect;
}

site links

location / {
try_files $uri $uri/ /index.php?$uri&$args;
}

panel links

location /panel {
try_files $uri $uri/ /panel/index.php?$uri&$args;
}

Error pages

error_page 404 /error;
error_page 403 /error;

#6

You can test it by accessing any text file in your content directory, for example http://example.com/content/site.txt. If that redirects you to the full file system path, you have the same error. If it only redirects to http://example.com/error, everything is fine.

#7

Thanks Lukas, I just had a test and it is slightly complicated with multi-language

  1. domain.com/content/site.md
    goes to
    rivieraremovals.com/error
    So that looks fine?

  2. But
    domain.com/en/content/site.md
    Goes to the error page, but leaves the url showing
    domain.com/en/content/site.md

Any insight appreciated, my gut feel is it is fine?

#8

The first one is a real URL to an existing file, so it’s caught by the rule in your config. The second URL is going to the index.php because it’s not linking to a real file. It’s caught by Kirby’s router and handled just like any other error page. That’s why no redirect kicks in and the URL stays the same. It’s all good :slight_smile:

#9

Thanks for the explanation Bastian, all good! We shall continue with our jolly little nginx server, safe in the knowledge we don’t have to change anything.

#10

I noticed that with the above settings of the .htaccess file the content folder is not protected and that the structure of it with all its subfiles is visible. This is at least the case with my setup – maybe I miss something? Has anybody an idea how to prevent that without blocking images in subfolders?

#11

To prevent that, you could just put a blank index.html file into the content folder.

#12

you should always switch off index listing on your server. That’s something that should be a standard on every production server in my opinion. It’s not just risky for Kirby, but for everything else on your machine.

#13

Thank you @texnixe, that was a very useful and important hint! I did it with an index.php file. And I added a line in the .htaccess file. But wouldn’t it be good to have this setup in the starter kit, too?

Now I noticed a different thing: everything is safe when I have an address like this: mysite/content/site.txt. But this way shows the full path again: www.mysite/content/site.txt. What happens here?

#14

As Bastian wrote, directory indices should be disabled completely directly in the Apache configuration. Please ask your hosting provider to do so as other customers of that provider are affected by the same issue and it just doesn’t make sense to keep them enabled.

Regarding your www issue: What does your .htaccess look like? Are you sure that both domains point to the same webroot? Could be that you have two sites and only changed it for one.

#15

If you use both domains (www and non-www) for the same content, you should really redirect one to the other in your .htaccess anyway to avoid having duplicate content, that will also solve the other problem.

But as @bastianallgeier suggested, index listings should be forbidden by the server settings rather than .htaccess settings. Which provider are you with?

@lukasbestle was faster.

#16

Thanks to you three! Yup, I will contact my provider (a local business), also, as you said, it’s important not only for myself. I am sure that both domains point to the same webroot. But a redirect will do it. Good night to you!