Jump to content
bernhard

Security risk to use custom file extensions?

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?

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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) ^^

  • Like 2

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...