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.
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.
@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.