bernhard Posted September 5, 2019 Share Posted September 5, 2019 Hi, @jens.martsch brought up the concern that .ready and .hooks files that I'm using for RockMarkup2 could be a security risk. See https://github.com/processwire/processwire-requests/issues/329 What do our security experts think? Is it worth the effort of refactoring my module to using .ready.php and .hooks.php extensions? Link to comment Share on other sites More sharing options...
teppo Posted September 5, 2019 Share Posted September 5, 2019 2 hours ago, bernhard said: Is it worth the effort of refactoring my module to using .ready.php and .hooks.php extensions? I wrote a longer reply to the issue mentioned above, but long story short: yes. Currently the contents of these files can be (and by default will be) world-readable, which – depending on the use case, i.e. the code stored in the files – can be considered anything from "probably unexpected but mostly harmless" to "a major issue". As a quick fix you can include a .htaccess file in your module directory preventing access to files with .ready or .hooks extensions, but in the longer term I would definitely recommend refactoring the module to use standard .php extensions instead ? 4 Link to comment Share on other sites More sharing options...
adrian Posted September 5, 2019 Share Posted September 5, 2019 I agree with @teppo - I recently discovered a colleague who was using phpc extensions on a site and he'd left debug mode on. I changed a URL query string value to something invalid which threw an error in a phpc file and I could simply load that file in the browser and view its contents - turns out it contained a payment gateway API secret key. All this because of a non-standard extension that PW's default htaccess file doesn't prevent access to. 2 Link to comment Share on other sites More sharing options...
netcarver Posted September 5, 2019 Share Posted September 5, 2019 What about, in principle, having an install-time option of making all non-standard files inaccessable unless whitelisted in the .htaccess file? If chosen, the installer could use a version of .htaccess file with rules that whitelist .css, .js, .htm(l) and perhaps .json extensions by default, along with the usual image file extensions. I'm suggesting this as I have, in the past, come across client sites with .pem certificate files in the site root directory and nothing in the .htaccess file to prevent their download. I think this would allow ProCache to work, as it compiles things down to these kinds files. Am I missing something with the idea? 1 Link to comment Share on other sites More sharing options...
bernhard Posted September 5, 2019 Author Share Posted September 5, 2019 Thx everybody for pointing that out. Actually I'm quite surprised that those files are not blocked by default ? I'll have to do some refactoring (again) ^^ 2 Link to comment Share on other sites More sharing options...
LostKobrakai Posted September 6, 2019 Share Posted September 6, 2019 12 hours ago, bernhard said: Actually I'm quite surprised that those files are not blocked by default ? ProcessWire protects what it knows it needs to protect. Blocking everything can be just as annoying especially on e.g. shared hosting where there might be some wordpress site in some subfolder. Or some new favicon file for some new mobile OS to be added to the root. There‘s even a xml file for MS in the mix already. So I feel like e.g. having a list of known sensitive files like .pem/.crt/... blocked would be a nice addition. .phpc is afaik also a often used extension for php. But I‘d not support blocking things beyond that. 3 Link to comment Share on other sites More sharing options...
Ivan Gretsky Posted September 6, 2019 Share Posted September 6, 2019 A lot of (even shared) hosting providers nowadays use nginx for static. And you may have no control over which extensions they include. So renaming to .php could be more secure than doing .htaccess restrictions in some cases. 3 Link to comment Share on other sites More sharing options...
teppo Posted September 7, 2019 Share Posted September 7, 2019 On 9/5/2019 at 7:39 PM, netcarver said: What about, in principle, having an install-time option of making all non-standard files inaccessable unless whitelisted in the .htaccess file? If chosen, the installer could use a version of .htaccess file with rules that whitelist .css, .js, .htm(l) and perhaps .json extensions by default, along with the usual image file extensions. A quick note on this one: while at first it sounded a bit over the top, I'm kind of warming up to the idea. Sure, there are problems and may not work in all situations, but it might make sense as an optional setting in the .htaccess file. There are already a number of optional sections in there, ones you can enable manually if they make sense in your context. This could be one of those: instead of blacklisting specific files, you could choose to disallow everything except for those you know your site to require. Just saying. 2 Link to comment Share on other sites More sharing options...
teppo Posted September 7, 2019 Share Posted September 7, 2019 On 9/6/2019 at 9:10 AM, LostKobrakai said: So I feel like e.g. having a list of known sensitive files like .pem/.crt/... blocked would be a nice addition. These sound like a good addition to rule 5B. Blocking access to known sensitive files is exactly the point of that rule ? 2 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now