Even when changed the files to with 777 the hacker still needs to get access to the server somehow to hack it?
Definitely true! This is something that is currently not prevented by Kirby.
So far I haven’t heard about a single hack of a Kirby site.
The main differences between WordPress and Kirby are the install base, the code size and complexity and the plugin ecosystem:
- Because WordPress is very well known, hacking into WordPress is currently very “profitable”. Of course, this is something that could affect Kirby at any time in the future.
- WordPress is complicated and contains quite old and unmaintainable pieces of code. It has a lot of functionality, some of which can be attacked (it’s just like with internet-connected cars ;)). Kirby is relatively small, the core even more so.
- There are a lot of WordPress plugins, which add even more complexity to the whole system. Some of them are installed on millions of websites, which makes them an attack vector on their own.
Yes, the problem here is that other people on the same server get full access to the whole site as well.
Conclusion: I think that using the Kirby core with a considered selection of plugins is very secure. The more interactive a site, the more complex the security though, so the Panel or custom interactive code could be an attack vector. If security is a major concern for a project, having a separate staging site with the Panel installation there makes sense.
2 Likes
This topic has a weird timing: http://forum.getkirby.com/t/kirby-2-1-1-security-update/1810 
No software can ever be 100% secure. That’s a sad fact. I take this issue very serious and don’t want to talk around it at all.
File-permissions are indeed a problem on shared hosting environments and we definitely need to create more awareness of what could go wrong with too liberal permissions. I was thinking about maybe addin an admin security check screen to the panel, which shows possible setup issues. But I need to investigate some more into how to make this reliable.
The note on possible brute-force attacks for the login is of course true as well. Suggesting strong passwords was just a first step with the latest release to work around that. I will set up a blocking mechanism for multiple login trials from the same IP. I’m also thinking about introducing the option for 2-factor authentication via Email.
In general I’m reviewing the code for the panel constantly, because the panel is probably the biggest source of possible issues — as any public admin interface. The ajax part is not a real problem here. All ajax views are of course protected from unauthenticated and I use csrf tokens for all form submissions and critical requests.
With the changes and decrufting I described here: http://forum.getkirby.com/t/behind-the-scenes/1778 I’m putting even more focus on possible vulnerabilities and ways to avoid them.
Something I can’t really controll is the code quality of plugins and of templates. Especially unfiltered and unsanitized input can do a lot of harm to any system. Kirby is no exception here. I can maybe only give more hints how to write secure frontend forms and stuff like that and how to use Kirby’s toolkit and other tools to filter input.
I’m very open to any suggestions, questions or feedback around this topic!! Make sure to send me anything you are worried about.
11 Likes
Also remember always to use HTTPS everywhere if it’s possible, especially for the pages with authentication or any sensitive data.
3 Likes
Maybe extending the Kirby docs with a chapter “How to keep your Kirby installation secure” would make sense. A few tips and tricks have been mentioned in this thread. I’m sure a few more will follow …
12 Likes
I think that something like a three-strike-pause bruteforce preventing mechanism would be essential for the panel login, but remember the user-experience that always follows this one, a “Forgot your password?”-feature might be necessary (other than just really handy) 
And as a important one, i think that the documentation about Authentication especially “The Login”-part should include Cross Site Request Forgery, maybe other forms in the docs (if any) would benefit from this.
2 Likes
I don’t know how bad it is because it seem the password is encrypted in some way, but you better not put you site/accounts/*.php files accessible publicly. I’m thinking in particularly at github.
Although it’s not a Kirby problem per se, it may be useful to make users make aware of this, in particular when version controllable content is a sale argument.
Indeed I’m agree with @flokosiol, a section about securing kirby should be added to the doc.
3 Likes
Some time ago there was a thread About Kirby folder structure
The sort of directories there look more easy to secure to me, but I may be wrong.
@thomas Kirby comes with a default .gitignore file that prevents pushing of the site/accounts folder to Github. But you are right, depending on how Kirby is installed, there should be a warning in the docs not push sensitive information.
Also, currently the site folder can be separated from the rest of the installation, I think it is planned to enable moving of individual folders as well.http://getkirby.com/docs/advanced/customized-folder-setup
1 Like
@anon77445132 Well it’s nothing to do with folder structure, if your accounts files are on github people can find your login and password hash.
It seems to be a pretty solid implementation and to be hard to get your password from that, but it’s never a good idea to have theses public.
@texnixe The .gitignore file is only present if you clone the starter kit from github. The zip file from the download page doesn’t have it.
I never use the download file but that’s what I thought, therefore I said “depending on how Kirby is installed”
Yes, you are right, but I think on the permission of the different folders.
Until now the webserver (I use the panel) has to write files at a lot of different located directories, where the webserver needs write access. On many other directories the webserver needs only read access.
If the structure would be changed, then it could be made easier to have the correct write permissions for every directory.
This could be another point to make a Kirby installation saver and this is, I think, the theme of this thread in the last posts.
If the docs get hints for security, this theme with the actual needed permission (like e.g. “webserver needs write access” or “webserver needs read access”) for each folder-structure should be added too, I think.
1 Like
That can not happen with me, since I do not use github.
But we have to cater for quite a few people who do and who might no be aware of the risk if they are new to using Git and Github.
Personally, I prefer Bitbucket to GitHub, because it gives me the possibility to use private repos (or as private a repo as can be if it is submitted to servers that are not under my control). For max. security it would be better to self-host GitLab.
1 Like
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.
https://github.com/getkirby/getkirby.com/edit/master/content/1-docs/10-security/docs.txt
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