RFC Move protected folder outside of /public directory by default

[brettt89]

The default behavior of silverstripe-assets appears to have both Public and Protected assets stored within the /public directory (ASSET_DIR). This promotes bad architecture of web servers in that users are encouraged to expose the parent directory of protected assets (/public) to as the Root directory.

Currently the default behavior relies on the web servers ability to perform client-directed configuration through static files to protect access to these assets. This architecture is not great as if these configuration files (E.g. .htaccess) go missing / removed / changed in any way, these files could be exposed publicly.

It also restricts the usage of web servers which do not allow client-directed configurations such as Nginx.

Suggestions

• Move /public/.protected to its own root directory (E.g. /.protected)
• Remove .htaccess and IIS configuration files
• Create path to migrate files from existing folder structure to new
• Add dev/check for ensuring protected folder is not publicly accessible via URL?.

This helps encourage better security configurations for web servers by having the root directory for static requests set to /public, which is separated from the protected directory. This helps ensure requests to non-public directories can be directed to index.php without making assumptions about the sub-folder structure.

This would also allow the support of many other web server applications that do not support client-driven configurations such as Apache and IIS. (E.g. Nginx)

[michalkleiner]

As much as I'd generally support this idea, there will be hostings and webserver configurations where only one folder will be writable by the webserver itself, generally the document root itself (and the temp folder), which may prevent the use of two separate folders for storing public and private assets without one being a subfolder of the other.

[brettt89]

As much as I'd generally support this idea, there will be hostings and webserver configurations where only one folder will be writable by the webserver itself, generally the document root itself (and the temp folder), which may prevent the use of two separate folders for storing public and private assets without one being a subfolder of the other.

@michalkleiner Wouldn't that be better off as an opt-in experience rather than the default. Perhaps leaving the Apache/IIS Adapters as classes within this module is still suitable, but making the "combined public/private" asset store as an opt-in experience.

E.g. Ability to configure via ConfigManifest / YML.

[brynwhyman]

Here's the 2017 version of this conversation :) silverstripe/silverstripe-framework#7710

[michalkleiner]

Wouldn't that be better off as an opt-in experience rather than the default. Perhaps leaving the Apache/IIS Adapters as classes within this module is still suitable, but making the "combined public/private" asset store as an opt-in experience.

Yes @brettt89, you're right that the default can expect more from the hosting while providing better security, with the option to configure it for limited conditions such as a single writable folder. Basically, I forgot this would be configured per environment.

[maxime-rainville]

I think you can already do this bf defining a SS_PROTECTED_ASSETS_PATH environment variable.

I tried it locally a while back and it seemed to work well at first glance. Didn't try it on CWP or SCP however and I'm petty sure horrible things would occur if you did.

[brettt89]

@maxime-rainville Yes you can, but this RFC is for changing the default behavior to have PROTECTED assets stored in a different folder entirely.

This helps remove the dependency on Apache for running a Silverstripe Website OOTB.

[micschk]

“Security by default”
Moving the default location of the protected folder seems very sensible to me. Having it in the public webroot in the first place is more of a legacy than a feature. It's also better if the less secure setup of having it in the public webroot requires a conscious decision/configuration instead of the default.

Move /public/.protected to its own root directory (E.g. /.protected)

Any reason to keep the dot in there? I'd vote move it to a plain, slightly more descriptive name.
Eg private / non-public or so? (since the directory is not actually protected in any way, just not public).

Remove .htaccess and IIS configuration files

Maybe there's no harm in leaving them there anyway as a fallback protection mechanism, eg in case of misconfiguration of the webroot (like the other way around there's also still a fallback .htaccess outside /public to rewrite requests to /public)

[michalkleiner]

@micschk dot files (and possibly dot folders) are visibly hidden by some file managers, one more way to obscure things. Without the dot, the chance of a folder name collision with something in the codebase is slightly higher imho.

[brettt89]

hidden by some file managers

Only some file managers / systems actually hide dotfiles. While 'using dotfile annotation' is not part of this raised issue (and possibly should be its own Issue). But IMO, dotfiles should not be used as a method of security / hiding files and folders.

"Security through Obscurity is not Secure".

Dotfiles / Dotfolders is a UNIX convention that is not a standard. (Same as how Windows performs hidden files, uses its own convention).

[michalkleiner]

hidden by some file managers

Only some file managers / systems actually hide

That is saying the same thing.

I do agree that obscuring shouldn't be used as the main method to secure stuff, but I'd say it can be considered additional if the primary method is secure on its own.

[brettt89]

Apologies I didn't write that party very clear, was just trying to say that IMO we shouldn't default a setting in the application based on something that is not standardized across the industry (E.g. Hidden files/folders). But this is more just a personal opinion on what assumptions a framework should make. Using / Not using dotfiles doesn't have any functionality impact to this issue.