Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secure errors directory #20212

Merged
merged 1 commit into from
Mar 26, 2019
Merged

Secure errors directory #20212

merged 1 commit into from
Mar 26, 2019

Conversation

schmengler
Copy link
Contributor

Description (*)

For Apache: deny access to XML and PHTML files within errors directory (pub/errors/.htaccess)
For Nginx: deny access to PHTML files in general and XML files within errors directory (nginx.conf.sample)

Fixed Issues (if relevant)

  1. errors/local.xml and error page templates are publicly accessible #20209: errors/local.xml and error page templates are publicly accessible

Manual testing scenarios (*)

See issue #20209

Contribution checklist (*)

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All automated tests passed successfully (all builds on Travis CI are green)

@magento-engcom-team
Copy link
Contributor

Hi @schmengler. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

  • @magento-engcom-team give me test instance - deploy test instance based on PR changes
  • @magento-engcom-team give me 2.3-develop instance - deploy vanilla Magento instance

For more details, please, review the Magento Contributor Assistant documentation

@schmengler
Copy link
Contributor Author

@magento-engcom-team give me test instance

@magento-engcom-team
Copy link
Contributor

Hi @schmengler. Thank you for your request. I'm working on Magento instance for you

@magento-engcom-team
Copy link
Contributor

Hi @schmengler, here is your new Magento instance.
Admin access: https://pr-20212.instances.magento-community.engineering/admin
Login: admin Password: 123123q

@orlangur orlangur self-assigned this Jan 11, 2019
@@ -198,6 +203,6 @@ gzip_types
gzip_vary on;

# Banned locations (only reached if the earlier PHP entry point regexes don't match)
location ~* (\.php$|\.htaccess$|\.git) {
location ~* (\.php$|\.phtml$|\.htaccess$|\.git) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@schmengler maybe forbid both xml and phtml in both occurrences here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was tempted to, but not sure if that could block legit requests

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wouldn't that block sitemaps?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@schmengler, ok, noticed

For Nginx: deny access to PHTML files in general and XML files within errors directory (nginx.conf.sample)

Do we need to give access for some xml in reality?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @wigman!) That's the case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

although they should not be, sitemaps can be named dynamically so this is not possible I guess?
so for now maybe only excluding .xml in the errors directory could do it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidverholen aren't they placed in some specific directory with name corresponding to some mask?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can choose a relative path and filename under the pub directory, so it's not possible to determine (at least by filename)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe a solution could be, to block the errors directory completely and only explicitly allow files that need to be public? Could be difficult for custom error themes as they lie in sub directories of errors and also can be named dynamically

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see a satisfying general solution here yet

@orlangur
Copy link
Contributor

@schmengler changes looks good to me, can you squash them into one commit maybe specifying all three points in commit message? Changes in general look atomic to me and does not require splittin into few commits.

For apache via .htaccess and in nginx sample configuration
@schmengler
Copy link
Contributor Author

@orlangur OK, squashed

@magento-engcom-team
Copy link
Contributor

Hi @orlangur, thank you for the review.
ENGCOM-4562 has been created to process this Pull Request

@soleksii
Copy link

✔️ QA Passed

Result:

after

@ghost
Copy link

ghost commented Mar 26, 2019

Hi @schmengler, thank you for your contribution!
Please, complete Contribution Survey, it will take less than a minute.
Your feedback will help us to improve contribution process.

@magento-engcom-team magento-engcom-team added this to the Release: 2.3.2 milestone Mar 26, 2019
@schmengler schmengler deleted the secure-errors-directory branch October 31, 2019 14:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants