Hardened Configuration for Shopware

[shyim]

I had the idea of a Hardened Configuration what covers things like

• Remove access to all folders except folders: themes, media, web
• Add ip based whitelist to /backend and optional /api, otherwise rewrite to error controller
• Remove all return 404 and rewrite to error controller, to have the same look and feel on blocked resources

What do you think about that? :)

[bcremer]

Sounds interesting.
This should be archived without hurting usability too much.

Maybe you can split the locations checks into separate include files that can be referenced inside shopware.conf.

Please not that I am not able to test this configuration by myself but I will trust PRs from Shopware Folks like @shyim.

If I don't find any obvious errors or usability errors in a Pull Request regarding this topic I am willing to merge.

[emilv]

You are proposing the sane way of configuring a web application server. The idea is great. My concern is that it will not be semantically the same as the supported Apache configuration. This kills the assumptions plugin developers and others might make about the environment. Therefore I think this change should be driven from upstream.

[wbob]

hi! good ideas, but I see downsides with an error controller.

1. Laravel has this public/ folder approach I envy (I'm not privy to all details and downsides). Maybe shopware ppl can discuss if this is feasible, but generally yes, a directory-whitelist approach seems worth pursuing & testing
2. if you place an outcommented section with allow/deny for those url paths it is quicker to enable yes, but it would be an easy Nginx edit to restrict by IP. Whoever ends up at these paths ain't there accidentally, so I think a return 404/403 is the most performant approach, see reasoning in use http 404 instead of deny for restricted locations #40
3. same with .env/.md/.txt files (version enumerating shopware installs?) is not in search of pretty errorpages (potentially loading cross-selling widgets for "alternative articles", hitting database and search). Nginx can return a 404 pretty fast when PHP is still compiling tpl and asking the db to serve the errorpage. There's always the option to link to a static error_page within nginx. If shopware introduces a maintenance.html alike static 404 page for those purposes I think this would be a better approach.