I have xssblocker module and entity embed installed in my local. When i do a entity embed. It does a ajax request to get Entity content(/entity-embed/preview/%textformat?value...). since this value is passed as a query string(get request) xssblocker check for tags in query string(<,>)and do a drupal_goto().
http://cgit.drupalcode.org/xssblocker/tree/xssblocker.module#n18
http://cgit.drupalcode.org/xssblocker/tree/xssblocker.module#n32
So our entity does not embed in our ckeditor.

Comments

smsivaprakaash created an issue. See original summary.

dsim’s picture

Yes, i'm facing this issue.

%3cdrupal-entity%3e tag is passed in the url query string which has both < and > characters which are xss vulnerable.

Have to pass this as POST parameter.

marcoscano’s picture

Category: Bug report » Feature request
Priority: Critical » Normal
Issue tags: +D8Media
dave reid’s picture

Component: CKEditor integration » Code
Category: Feature request » Bug report
Status: Active » Postponed (maintainer needs more info)
Issue tags: -D8Media

I think this is a D7 issue only. @silambarasan I see you filed [#https://www.drupal.org/node/2862614] where we should continue to discuss your issue, which is not related to a bug with another contrib module.

I'm also confused because I cannot find the xssblocker blocker module for Drupal 7 at all. I see it has a Drupal 6 version, but not Drupal 7.

dsim’s picture

Hi @dave-reid

Attached the screenshot in https://www.drupal.org/node/2862614

This is the module that does it. https://www.drupal.org/project/xssblocker

Usually many organization will configure to block the request which has these special characters in the GET request urls.

dsim’s picture

Here is a D8 issue which is similar to it. (without xssblocker module). My org security team blocking '<' and '>' characters which are coming in the url.

https://www.drupal.org/project/entity_embed/issues/2862614

wim leers’s picture

Category: Bug report » Support request
Status: Postponed (maintainer needs more info) » Fixed

That's just a flaw in the https://www.drupal.org/project/xssblocker module (and similar blocking done at lower levels). That approach simply has a significant probability of false negatives. It's by no means a best practice.

Status: Fixed » Closed (fixed)

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