News:

Bored?  Looking to kill some time?  Want to chat with other SMF users?  Join us in IRC chat or Discord

Main Menu

What IS data:, ?

Started by azarober, November 01, 2013, 08:58:05 AM

Previous topic - Next topic

kat


margarett

A similar issue, but with a MOD on 2.0.x

There's something wrong with Chrome, hey? :o
Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

QuoteOver 90% of all computer problems can be traced back to the interface between the keyboard and the chair

SoftwareSamurai

#22
FYI: I just went through the same problem but with another mod. I traced it down to Chrome not handling the redirectexit() call correctly when the refresh is not enabled. When I changed the call to force a refresh, the Chrome browser was fine.

Additional info:
I've traced it down to redirectexit() sending a Location Header. There seems to be a problem with Chrome processing this type of header under some conditions. Exactly what conditions are causing this behavior is what I'm looking into right now.

Solution!
Turns out that Chrome has a security feature that disables the page when the exact same java script is seen on a post and then on a get.
This behavior is controlled via the header "X-XSS-Protection". It's normally enabled. By inserting the line

   header('X-XSS-Protection: 0');
into the function template_header() (in Subs.php), I can disable this behavior. This, for me and the mod I've been investigating, solves the blank-page with "data:," problem. Now I'm not suggesting that everyone disable the X-XSS-Protection mode, but this does raise some serious questions regarding that "feature" in Chrome.

Arantor

And yet, I've been running forums since before 2.0.6 came out with that line in it and no problems observed... (I'm the guy who introduced the X-XSS-Protection line into 2.0.6 / 1.1.19, it's not there beforehand)

This is why I asked you for the data URL that you were receiving. Because if Chrome is messing this up, IE should mess it up too.
Perhaps it would have been better if I'd simply never bothered. Y'all clearly would be less unhappy that way.

SoftwareSamurai

#24
I'm not sure what you mean by "data URL". (Forgive my ignorance.)

I've double-checked the URL on the "Location:" header and it's totally correct.

I discovered this as the source of the problem when I brought up Chrome's element inspector, opened the console window, and then tried to submit the form containing javascript code. The console window popped up the error:
Quote
The XSS Auditor blocked access to '...' because the source code of a script was found within the request. The server sent an 'X-XSS-Protection' header requesting this behavior.
That's when I started to look at the X-XSS-Protection header as the cause.

I've tried this with IE 10 v10.0.10 and Firefox v25.0. Neither stopped loading the page as Chrome did.

If there's more information I could give you on this, please feel free to ask. (Just remember, I don't have a lot of experience with this web-stuff, but I am a software engineer - I'll learn quickly!)

p.s. Just a thought: Perhaps it would be better if "mode=block" was removed?

Arantor

QuoteI'm not sure what you mean by "data URL". (Forgive my ignorance.)

Well, I assumed, perhaps naively, that you were responding to this topic which is all about that.

The OP is having a redirect to a URL that begins with data: rather than http:, which is a perfectly legal URL that contains data. It is possible, for example, to encode entire images into data URLs.

What you're reporting is a different problem with likely different consequences.

In your case, the mod's author should themselves manage the change of X-XSS-Protection level since most users have no reason or ability to add JavaScript anywhere.
Perhaps it would have been better if I'd simply never bothered. Y'all clearly would be less unhappy that way.

SoftwareSamurai

I responded to this topic since this is exactly the same behavior that I was seeing with the global headers and footers mod. After entering a little javascript into the text area for a global header and clicking "save settings", I would get a blank page with a url of "data:," - exactly the same as the OP described. (I'm beginning to believe that getting a url of "data:," is the result of Chrome blocking the page from loading.)

After doing a little testing, I think that enabling the X-XSS-Protection but not setting it to block is a good compromise. The page will still load, but the script(s) will simply be ignored just for that load.

Arantor

QuoteI would get a blank page with a url of "data:,"

Just that? Or a string of longer stuff? (This is a data URL) It's just that what you were describing a post or two ago didn't sound like the same thing as the OP.

QuoteAfter doing a little testing, I think that enabling the X-XSS-Protection but not setting it to block is a good compromise. The page will still load, but the script(s) will simply be ignored just for that load.

It's a good compromise for *you* perhaps, but it's not something we can entertain in the base software so much - I say again that the mod author should deprotect their mod rather than expecting us to do the same thing everywhere.
Perhaps it would have been better if I'd simply never bothered. Y'all clearly would be less unhappy that way.

SoftwareSamurai

Quote from: Arantor on November 03, 2013, 12:35:48 PM
QuoteI would get a blank page with a url of "data:,"

Just that? Or a string of longer stuff? (This is a data URL)

Just that. Nothing else. A blank white page and "data:," in the url. Exactly as the OP had described:

Quote from: azarober on November 01, 2013, 08:58:05 AM
...when I reply a post and click on 'save' on the address bar appears this 'data:,' and the page in white...

azarober

Hi all !
First of all thanks for your efforts to find a solution. Although I opened this topic, I can not contribute due to my lack of knowledge.. but I am here to add another element: I left the problematic Chrome and downloaded the new Opera 15 NEXT...
same behaviour with a little difference=
when I reply a post and click on 'save'... OPERA shows me for a second or two the saved page and afterwards on the address bar appears this 'data:,' and the page in white... As always I must close the tab, reopens SMF and the post IS SAVED !
For some reason YOU ONLY understand... it seems Firefox is the only browser which does not makes problems to SMF !

Thanks again to everybody !
Roberto

re1lazz

I also have these problems :(

Zavoolon

I have same problem. But only with "Global Headers and Footers" MOD. Any solutions are appreciated.

Arantor

Perhaps it would have been better if I'd simply never bothered. Y'all clearly would be less unhappy that way.

Advertisement: