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

Server Side Request Forgery in SEO file link endpoint #1177

Open
d--j opened this issue Jul 11, 2022 · 1 comment
Open

Server Side Request Forgery in SEO file link endpoint #1177

d--j opened this issue Jul 11, 2022 · 1 comment

Comments

@d--j
Copy link

d--j commented Jul 11, 2022

Describe the bug

The SEO file link endpoint takes the user provided URL and passes it to file_get_contents with only a very light validation (the URL must start with http: or https:).

With this endpoint (that can be configured to be accessible by anonymous) an attacker can

  • access any URL that the webserver has access to (including URLs that are only accessible to localhost), and
  • can use the server as a proxy.

To reproduce

Steps to reproduce the behaviour:

  1. (optional) Go to plugin settings -> Endpoints and enable "SEO File Link Endpoint Access" (if you skip this step, the next step must be done while you are logged in in the CP)
  2. Open <craft-cms-site-with-seomatic-installed>/seomatic/seo-file-link/aHR0cHM6Ly93d3cuZXhhbXBsZS5jb20v/bm9uZQ==/ZmlsZS50eHQ=/1/file.txt . E.g. when your craft runs on localhost:5500
  3. See the HTML code of https://www.example.com/

Expected behaviour

The user should not be able to construct links to the SEO file link endpoint on her own. You should use e.g. Craft::$app->getSecurity()->hashData and validateData to protect the URL (and other parameters) from tampering.

Asides

Checking the allowed extension after executing the HTTP request is not optimal (some GET requests have side effects). And the check is kind of useless anyways, since the file name can be altered by the user.

Versions

  • Plugin version: 4.0.6
  • Craft version: Craft Pro 4.1.3

PS: I tried to report this via the steps described in the security policy but did not get any response.

@d--j d--j added the bug label Jul 11, 2022
@khalwat
Copy link
Collaborator

khalwat commented Jul 11, 2022

The endpoint is off by default, for this reason: we wanted people to have to specifically enable it, understanding the implications.

I will look into the method of protecting the URL from tampering as you describe.

@khalwat khalwat added enhancement and removed bug labels Jul 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants