You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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]
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
The text was updated successfully, but these errors were encountered: