Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kirby Panel requests composer.json which triggers WAF #6878

Open
gitlabisbetterthangithub opened this issue Dec 23, 2024 · 4 comments · May be fixed by #6932
Open

Kirby Panel requests composer.json which triggers WAF #6878

gitlabisbetterthangithub opened this issue Dec 23, 2024 · 4 comments · May be fixed by #6932

Comments

@gitlabisbetterthangithub
Copy link

gitlabisbetterthangithub commented Dec 23, 2024

Description

Loading the Systems view in the Panel will trigger Kirby to check if certain sensitive files are exposed, such as /kirby/composer.json, however these checks are done on the client side which can lead to the firewall on the server blocking the IP address of the Panel user because the Panel tried to request known sensitive files.

In my situation, the Web Application Firewall used is bitninja.io which will block IP addresses that try to access any of these files: https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0/master/rules/restricted-files.data

This list includes composer.json, the file that Kirby tries to access to see if the Kirby folder is exposed.

Rather than requesting composer.json from the kirby folder, it would be better if Kirby tested a different file. This would mitigate the problem caused by requesting sensitive files that a WAF might block while still allowing Kirby to check if the kirby file is exposed.

I'm well aware that this bug could be resolved by disabling the WAF rule, but I believe that given that this problem could be an issue for others and that Kirby can develop a workaround, it would be better to change the code to accommodate this situation.

Expected behavior
While this bug largely depends on the environment that Kirby is deployed in, Kirby shouldn't be requesting known file paths that web application firewalls may treat as malicious, especially when making the request in the front-end (browser)

To reproduce

You won't be able to reproduce this bug unless you have a WAF that blocks /kirby/composer.json

Your setup

Kirby Version
4.5.0

Console output

Running system health checks for the Panel system view; failed requests in the following console output are expected behavior.
XHR GET
https://www.REDACTED/content/site.txt
[HTTP/2 404 176ms]

XHR GET
https://www.REDACTED/site/blueprints/site.yml
[HTTP/2 404 175ms]

System health checks ended. 1 issues with accessible files/folders found (see the security list in the system view).

@tobimori
Copy link
Contributor

tobimori commented Jan 14, 2025

IIRC, the whole point of this is a security check and testing whether that file is exposed. It's meant to fail, no? So the only way to fix it would be to disable all of those security checks.

@distantnative
Copy link
Member

I am also not sure if I understand your issue @gitlabisbetterthangithub

Rather than requesting composer.json from the kirby folder, it would be better if Kirby tested a different file. This would mitigate the problem caused by requesting sensitive files that a WAF might block while still allowing Kirby to check if the kirby file is exposed.

This whole check is about testing whether the composer.json is accessible - it would be bad if it is, so the request is intend to fail. Testing another file would negate this security check as it is specifically about the composer.json.

@gitlabisbetterthangithub
Copy link
Author

gitlabisbetterthangithub commented Jan 22, 2025

The whole Kirby folder is supposed to be inaccessible, correct? Couldn't we change the file from /kirby/composer.json to a different file in the Kirby folder, e.g /kirby/differentfile.json? Obviously this file would need to be created. The request should still fail as the file shouldn't be accessible as it's in the Kirby folder.

If differentfile.json is accessible then composer.json would surely be accessible.

This change still checks to see if the Kirby folder is exposed but won't trigger the WAF to block the user for checking a restricted file name.

--

My problem is that the WAF will block the IP address of the Panel user who has clicked on the System tab because this security check is done in the background automatically.

Perhaps an option in the config.php file for changing what security checks are performed or an option to stop automatically checking (& instead have a button). As a workaround, I've disabled the System view for normal users but I still would like to access this page without automatically being blocked by the WAF due to the Panel checking composer.json

Let me know if you still don't fully understand. I might be able to do a screen recording

@lukasbestle
Copy link
Member

lukasbestle commented Jan 22, 2025

I had the pleasure to work around a WAF before (in a different case, but still), so I agree in the first step we should switch to a different file path to check. Maybe even something simple like kirby/README.md? Then we wouldn't need to create a new file just for this check.

One check we won't be able to adapt though: .git/config. The blocklist of your WAF contains the entire .git directory, so it would still trigger a block. But Kirby only checks this path if a Git repo actually exists, which is why you maybe didn't run into this.

So I think it could be a two-step fix:

  1. Replace the path for the kirby folder with kirby/README.md
  2. Offer a config option to disable or customize the checks.

@distantnative distantnative linked a pull request Jan 23, 2025 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

4 participants