One of the users found today that you can put anything you want inside the [embed] tags. The content then gets html encoded, and then decoded again so it bypasses all other filters that may catch it

Here is her test case. She was trying to figure out if it was possible to set the size of an embedded object in the filter.

[embed]<iframe src="http://player.open.ac.uk/embed/c7a775d799" height="270" width="480" frameborder="0" allowfullscreen></iframe>[/embed]
CommentFileSizeAuthor
#8 oembed-filter_invalid_urls-2107397-8.patch3.15 KBstrangeways

Comments

stuart.crouch’s picture

stuart.crouch commented

Just to clarify - the html has to be escaped, then the embed tags seem to unescape it and let you put any HTML you want in

<p>[embed]&lt;iframe src=&quot;http://player.open.ac.uk/embed/c7a775d799&quot; height=&quot;270&quot; width=&quot;480&quot; frameborder=&quot;0&quot; allowfullscreen&gt;&lt;/iframe&gt;[/embed]</p>
<p>[embed]&lt;iframe src=&quot;http://player.open.ac.uk/embed/35a4355954&quot; height=&quot;480&quot; width=&quot;848&quot; frameborder=&quot;0&quot; allowfullscreen&gt;&lt;/iframe&gt;[/embed]</p>
thedavidmeister’s picture

thedavidmeister commented
Priority: Normal » Critical
Issue summary: View changes

Surely this is a critical security issue?

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented

Unpublishing because this is a security issue. We'll continue on security.drupal.org.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented

Because this only affected the Drupal 7 version and it has no stable release, this is moving back to the public issue queue. Sorry, for detour to security.drupal.org! I should have checked if there was a stable release. :-/

chasingmaxwell’s picture

chasingmaxwell commented

Could this be a text filter configuration issue? If the oEmbed filter comes before the "Limit allowed HTML tags" filter, the "Limit allwed HTML tags" filter will catch whatever was returned by the oEmbed filter.

stuart.crouch’s picture

stuart.crouch commented

If you make oembed filter happen first, the limit html tags filter actually strips out everything that the oembed put in (because objects etc are not allowed tags). We dont want the users entering them manually because they make a mess, so they cant be added as an allowed filter.

humansky’s picture

humansky commented

This is a pretty serious XSS vulnerability. Here's a simple example:

[embed]<script>alert(123)</script>[/embed]

EDIT: this vulnerabiliy only works when you are using the WYSIWYG Filter module

strangeways’s picture

strangeways commented
Version: 7.x-0.1-beta3 » 7.x-1.x-dev
StatusFileSize
new oembed-filter_invalid_urls-2107397-8.patch3.15 KB

Here is a patch that does the following:

  1. For invalid embed URLs, display the HTML encoded version rather than the decoded version.
  2. Add checks for valid URLs when validating and processing the embed URL.
  3. Apply decode_entities() in more consistent manner before calling oembed_get_provider().
  4. Fix the order of the arguments when calling oembed_resolve_link() from oembed_legacy.inc.
astonvictor’s picture

astonvictor commented
Status: Active » Closed (outdated)

D7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.