Fixed Chrome 57 gives XSS error when editing a post

[Divvens]

And would also like to note it isn't just inline, if from an inline editor we press "more options" it gives us the same error.

 

[xenfans]

@Mike Will we be able to expect a release to address this for our 1.x communities?
Maybe an unofficial patch to give sites the option to detect urls and offer full editor instead for those posts?

 

[Mike]

You can workaround it by adding this to config.php:

header('X-XSS-Protection: 1');

Actually, this is potentially another reason why I think this is a Chrome bug. It thinks there is an XSS vector here based on view source, but it's not actually scrubbing anything from the input, so it doesn't break the page. I will have to take this to them to see if there are any further comments -- though it may just lead to them scrubbing this value, which would mean that XSS protection will have to be entirely disabled to workaround this issue.

 

[Chris D]

@Mike Will we be able to expect a release to address this for our 1.x communities?
Maybe an unofficial patch to give sites the option to detect urls and offer full editor instead for those posts?

Always assume that we will aim to resolve most bugs for the next release while practical or at least while it's open there will be an official resolution at some point.

 

[xenfans]

You can workaround it by adding this to config.php:

header('X-XSS-Protection: 1');

Actually, this is potentially another reason why I think this is a Chrome bug. It thinks there is an XSS vector here based on view source, but it's not actually scrubbing anything from the input, so it doesn't break the page. I will have to take this to them to see if there are any further comments -- though it may just lead to them scrubbing this value, which would mean that XSS protection will have to be entirely disabled to workaround this issue.

Thank you. (edit: Version 58.0.3029.68 beta (64-bit) fixes a few things, but more options still triggers, your 'add this to config' fixed it completely for my site).

 

[Sim]

But it's a moot point in XF2

So @Chris D you can confirm that this won't be a problem with XF2's editor?

 

[Chris D]

Inline editing is different in XF2 and we don't have a base tag, which I believe is what triggers this, so, no, this shouldn't be an issue in XF2.

 

[Allan]

Same problem for me.

Edit: Same problem with Chrome Version 58.0.3029.68 beta (64-bit)

 

[rwm1962]

I'm getting this with Chrome 57 when going into 'more options' on edit. Only when the post contains a link.

However it's only on our 1.4 site. It doesn't happen on our 1.5 site

 

[CTXMedia]

Just hit this today [link] and have added -- header('X-XSS-Protection: 1'); -- but would rather not leave that in permanently; if the Chrome devs do end up adding a fix for this would someone mind posting here with a heads-up so I can enable the protection again.

Thanks,
Shaun

ETA: Misunderstood the original issue - protection value changed from 0 to 1.

 

[Mike]

Note that the code I posted uses the value "1", which I believe is what Chrome was doing without a header up until recently -- at least based on their comments. That will use the XSS protection but try to strip the issue rather than blocking.

 

[Dan Hawkins]

You can workaround it by adding this to config.php:

header('X-XSS-Protection: 1');

Actually, this is potentially another reason why I think this is a Chrome bug. It thinks there is an XSS vector here based on view source, but it's not actually scrubbing anything from the input, so it doesn't break the page. I will have to take this to them to see if there are any further comments -- though it may just lead to them scrubbing this value, which would mean that XSS protection will have to be entirely disabled to workaround this issue.

Thanks for the work around - our members have just spotted this issue too!

 

[CTXMedia]

Note that the code I posted uses the value "1", which I believe is what Chrome was doing without a header up until recently -- at least based on their comments. That will use the XSS protection but try to strip the issue rather than blocking.

Thanks Mike. Perhaps I've misunderstood. I thought the default was '1' and that was what was causing the problem, hence my using zero. I'll change it to '1'. Cheers.

 

[Mike]

Chrome's new default is "1; mode=block" (which is why it suddenly broke).

 

[CTXMedia]

Chrome's new default is "1; mode=block" (which is why it suddenly broke).

Thanks Mike.

 

[RobinHood]

I'm getting this now too, the config.php setting seems to have suppressed it though.

 

[Kiem Dan Le]

Safari Browser also triggered the error now.

 

[Synseal]

I am getting this error also, is this mentioned above a safe workaround?

header('X-XSS-Protection: 1');

Or should I wait...

 

[Aceros]

Glad to have seen this thread. Getting this error as well for specific cases mentioned above (images as links back to site).

 

[aljaxus]

Also having this issue with opera.
Running latest XenForo vesrion.