Jump to content

Security risk to use custom file extensions?


bernhard
 Share

Recommended Posts

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

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 ?

  • Like 4
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

12 hours ago, bernhard said:

Actually I'm quite surprised that those files are not blocked by defaul?

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.

  • Like 3
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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 ?

  • Like 2
Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...