I often got automatic updates from WordPress because they find security holes quite often. I have been hacked a few times using WordPress.
Is Kirby secure? How can we know?
Possible ways into Kirby by hackers
Brute force through the login page
Especially with a weak password hackers should be able to login with brute force. Because Kirby loads so fast it might be possible for a robot to make very many requests in a short time.
Would it be better to slow the login page?
Ajax through the panel or plugins, template, snippets
How secure are the panel? It uses much Ajax as far as I can tell. Is it breakable?
How hacking could be prevented by users
Set a strong password
Be careful of plugins
Validate variables sent with Ajax through template
More?
Anyone hacked?
Do you got hacked when using Kirby? What was the problem and how was i solved?
One pitfall I can think of has to do with file permissions. During server setup, sometimes I run into permission issues and need to reset all folders to 755 and all files to 644.
Someone in a similar situation could easily do a quick and dirty chmod 777, which would expose Kirby to more vulnerabilities.
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.
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.
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.
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 …
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.
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.
@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.
@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.
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.
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.
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.
