Created on 28 August 2023, over 1 year ago
Updated 10 January 2024, about 1 year ago

I see the original images ar downloaded under public://externals/. I wonder what are the safety measures taken to make sure this is not a vulnerability. In general showing remote assets is considered a risk. Some can access the original images directly, they are just downloaded as they are. Is the mime type check enough?

πŸ’¬ Support request
Status

Fixed

Version

3.0

Component

Code

Created by

πŸ‡·πŸ‡΄Romania claudiu.cristea Arad πŸ‡·πŸ‡΄

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @claudiu.cristea
  • πŸ‡·πŸ‡΄Romania claudiu.cristea Arad πŸ‡·πŸ‡΄

    At least we might do a getimagesize() which know to detect non-images?

  • Status changed to Fixed over 1 year ago
  • πŸ‡§πŸ‡ͺBelgium swentel

    Well, in about 99% of our use cases, the external images are saved in a field which is populated by an API call. Users never enter this value themselves. And in addition with the whitelist, I think we're fine to be honest. Larowlan has maintained this module for a couple of years as well, so I kind of imagine that he and his team have definitely thought about security things in this module.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    Just to clarify. I wrote this module in D6 era for a European Government tourism site.
    I no longer use it but still help out with reviews/maintenance.

    In terms of safety, if you don't trust the domains in the allow-list there is a risk of defacement.

    E.g. someone could craft a URL that fetched a file from an untrusted domain and it would appear as though that image is from your site.

    I think the itok param that was added in D7 would make it harder to do this than it was in D6 where you could effectively use the site as a proxy if the allow-list was wide-open.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024