drupal_add_js doesn't sanitize external resources access

Created on 31 March 2016, about 8 years ago
Updated 6 April 2016, about 8 years ago

WARNING, this is a long shot and involves a few parts in drupal.

A bit of history is here :

https://www.drupal.org/node/2385069 β†’ -> discussing why remote urls get to locale.inc system trough hook_js_alter
https://www.drupal.org/node/1802394 β†’ -> showing how a contrib module can use drupal_add_js badly ( and still in stable )

So for drupal_add_js :

If no type is specified and the URL is external, it would be wise to force the type to external, otherwise modules relying on the type to alter javascript will bypass drupal_http_request method, and potentially allow access to forbidden resource on the network by bypassing any configured proxy.

This is a safety against badly coded module that could open a potential breach to the internal network.

On the wysiwyg/locale combo the issue is not a security hazard because the included JS is a fixed one, but I can definitely see some modules asking for JS urls at the backoffice level, skip the external part and then, therefore lets to potential security risk.

( example, filling http://192.168.1.1/reboot.asp would reboot your home router, in corporate it could get way worse ).

The patch provided makes sure that no external URLs are added without beeing tagged a external.

It doesn't touch the type if the user forces it tough, so only modules forgetting to set will change behavior.

It will also improve performance on sites that tends to use badly coded modules as the server will never query itself trough http anymore if not needed.

πŸ› Bug report
Status

Needs review

Version

7.0 ⚰️

Component
RenderΒ  β†’

Last updated about 1 hour ago

Created by

πŸ‡§πŸ‡ͺBelgium gboddin

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.69.0 2024