Is Kirby secure?

I agree wholeheartedly and think that is extremely important for the reputation of Kirby.

After your suggestions I started to add a docs section with all kinds of security tipps around Kirby: http://getkirby.com/docs/security

Please let me know what you think about it so far. It’s very much work in progress and if you have anything that should be added or extended, please let me know.

3 Likes

Security check

I think it’s a great suggestion. To make it smooth, don’t rush it. You could add one security check list item whenever they are tested and ready.

You can always add an line at the bottom that even if all checkmarks are green, it does not guarantee the safety. (In my mind it’s a list with green checkboxes to the left ;))

Security check - As a plugin in the future

In the future there might be security plugins to check this and show a list view in the panel, but I don’t think the panel is fully mature for that yet. We can’t create own main views or add stuff to the sidebar.

For security geeks with time left over

Missing some docs about security? Edit the docs into the browser. Help Bastian out.

This is a very good idea. A similar plugin for Drupal checks on write status for system files and simple configuration settings (like turned off debug messages and a fixed domain setting). Nothing magical but very efficient on deploys. I guess these helpers exist on most CMSes and shops.

Due to the nature of Kirby it could be necessary to check Kirby core as well as the panel configuration separately because they allow for different security holes (eg. hazardous file uploads).

@bastianallgeier:
Although I know the answer to the following question, but for a beginner of Kirby it is not easy to identify, which version number Kirby has currently (and which version is secure).

I assume that she/he does not want to use Git or cannot use Git for this. I ask this only to illustrate the need for security of these users.

If she/he looks at http://getkirby.com/:

If she/he looks at http://getkirby.com/downloads:

If she/he looks at http://getkirby.com/try:

If she/he looks at http://getkirby.com/docs/installation/download:

Here she/he never sees the actual version number (yet: 2.1.1) nor the date and time of that version without downloading that ZIP-file first.
And for security this is not good I think and suggest that you change this (and elsewhere)!


Hint:
We can look e.g. at http://getkirby.com/blog or http://getkirby.com/changelog to get this information, but I think, the other places are more useful for a beginner. I may be wrong with this last assessment!

3 Likes

I think, this/these “.gitignore” file(s) should be added to all ZIP-download files on getkirby.com and https://github.com/getkirby.
This/These file(s) is/are very small, but may be useful for some users and is/are harmless to those users, who don’t need it.

1 Like

Yeah…

Besides [you can argue] (The difference between two-factor and two-step authentication.) that email is no two-factor authentication, but two-step authentication at least one thing is sure: 2FA via email is really insecure.
It’s better than nothing of course, but it shouldn’t be the only option.

@rugk:
I think this page debates the security of a webserver build using Kirby but not the security
of getkirby.com.
That is the theme of HTTPS on getkirby.com.
Do you agree?

Actually, Bastian is right. No software is 100% secure. There must me some small holes that can be used to peek-in a little bit, and in that little hole you can get ALL or NOTHINGAND I JUST HAPPED TO DISCOVER A SMALL HOLE THAT PROVES IT, THOUGH ONLY PRESENT ON SOME SERVERS; maybe this is because of server misconfiguration, but anyways let me share this with you…

First let me introduce you these 3 htaccess rules in the starterkit.

RewriteRule ^content/(.*)\.(txt|md|mdown)$ error [R=301,L]

RewriteRule ^site/(.*) error [R=301,L]

RewriteRule ^kirby/(.*) error [R=301,L]

The goal of these rules is to redirect you to the not found page if you tried to open or view the txt/md/mdown files and site/kirby directories…

EXAMPLE:
you requested to access url http://www.example.com/content/site.txt in your browser, but those htaccess rules are blocking them so it should instead redirect you to url http://www.example.com/error.

##FEELING SAFE?
On the other hand, many webservers nowadays are misconfigured or shall we say does not support those 3 htaccess rules completely… in most cases, incompatibility reveal the full root directory location (IF MY TERMS WERE RIGHT)… So it should show something like /home/usr****/public_html/error** in the url…

##Just Directory? No Big Deal!
It’s not just about directories. Most webservers (especially shared webserver/hosting) uses your username(can be an ftp username) as part of the location…

EXAMPLE:
/home/ USERNAME_HERE /public_html/

PROOF:
You requested to access url http://www.example.com/content/site.txt in your browser, but those incompatible htaccess rules are blocking them so it instead redirects you to url http://www.example.com/home/usr****/public_html/error**.

So hackers don’t have to worry about the ftp username, the only thing they have to worry about is the ftp password… Anyway TRIAL AND ERROR is not a big problem especially if the owner’s ftp password is weak…

I managed to hack a website in the SHOWCASE page with full ftp access + his ftp and cpanel username and password are the same THEN I GOT COMPLETE ACCESS TO THE WHOLE WEBSITE AS IF I WAS THE OWNER… Good thing I am a good guy, I didn’t touched anything…

Thanks for reporting that issue! The reason for this could be that some servers need the RewriteBase setting to work properly. Maybe this should be written more directly in the docs or even activated by default in the .htaccess (disadvantage and the reason it is commented out now: Kirby sites don’t work in a subdirectory if it is set to a wrong value).

I’m will open this as an issue on GitHub.

That’s definitely not good. But please make sure to follow these very important steps now:

  • Don’t tell anyone the name/domain of the site so that no one but the real owner can “fix” the problem. Really: Don’t, this is very important.
  • Securely contact the website owner to tell them to change the password and how to fix the issue.
  • Please don’t publicly post security issues in the future, that itself can make a software/system vulnerable in the first place.

This process is called “responsible disclosure” and is very important to be a good guy. :wink:

Thats funny:

  1. site.ltd/site/config/config.php is returning to the site.ltd/error
  2. site.ltd/content/site.txt is returning to the site.ltd/var/www/****/public_html/error

I just saw the latest replies now after returning from my holidays and I will instantly provide a fix for it. This is definitely not good. I wasn’t aware that the RewriteBase setting has this side effect on shared hosting. Disabling it in such a situation wasn’t a good choice and I will revert to keep it activated by default even if this means that subfolder installations will be more tedious. Thanks for the heads-up. But as Lukas said. Please report this directly to me next time. This can help to avoid problems for many installations out there.

Ok, we should discuss this only in one thread. So I suggest we keep on using this one for this specific issue: Very important security issue - most kirby website could be vulnerable to this attack

You can now find the current version number on the main download links on the website.

I will also switch the Forum to HTTPS asap. I already contacted the Discourse folks. I will also move getkirby.com to HTTPS in the next days. It makes no sense to keep it like it is and talk about security.

Concerning the htaccess issue, I just re-released all 2.1.1 kits and changed the htaccess file in the downloadable package. I also posted an article with instructions how to change the htaccess settings in order to fix this issue: http://getkirby.com/blog/check-your-rewrite-base

@anon77445132

Yes, but I was just pointing out this:

Probably I asked about CSRF protection in the wrong place but then I found an answer by myself.

The toolkit provides a csrf() helper but unfortunately it is still undocumented. I think that using CSRF protection is one of the basic tools, along with input validation and sanitization, that helps to create secure themes and plugins.

You are right. I’m sorry that the csrf() method is yet undocumented. There’s still a lot of work to do to finally document each and every detail of the toolkit. As it marks mainly the foundation of Kirby on a very low level I spent more time on documenting the more obvious parts so far, which is not meant as an excuse :smile:

The csrf() method is fortunately very easy to use.

Without a parameter it will generate a token for you and also store it in the session. You can then use it for example in a hidden input field to submit it with a form:

<input type="hidden" name="csrf" value="<?php echo csrf() ?>">

In your submit handler you’d then just check for the incoming code like this:

$csrf = get('csrf');

if(!empty($csrf) and csrf($csrf)) {
  // your form has been submitted correctly together with a correct token
}

I hope this helps as a first explanation how to use it.

Thank you for your quick reply and the explanation on how to use it :+1: . I agree about the documentation process, it wouldn’t be a reproach :grinning: .