Freecodecamp: Chrome displays error message in iframe - Unsual code detected

@leekirby6 thanks for the issue. Can you give more information on where you saw this notification? A screenshot might help as well if you're able to provide one. I don't get any notification from Chrome when I open the page. Thanks!

Oh, i forgeted about screenshot.

Nothing happen when I use firefox.

It might be related to Chrome Beta. See #12655. It works fine for me with stable Chrome. @leekirby6 Can you try it with stable Chrome?

Thanks for rely. I prefer beta vesion than stable :
I used firefox !

Is this error an indication that campers will see this in a future version of Chrome? If that's the case, we should probably make sure this is fixed before the release.

I can reproduce this with Chrome 57, both on the beta and the live site.

The version where this can be reproduced is 57.0.2987.88. From the Chrome releases blog, on March 9th:

The Chrome team is delighted to announce the promotion of Chrome 57 to the stable channel - 57.0.2987.98 for Windows, Mac and Linux. This will roll out over the coming days/weeks.

The error:

The XSS Auditor blocked access to 'https://www.freecodecamp.com/challenges/add-a-submit-button-to-a-form#?solution=solution-here' because the source code of a script was found within the request. The auditor was enabled as the server did not send an 'X-XSS-Protection' header.

This mentions that the error we're seeing is indeed caused by functionality enabled in Chrome 57.

The warning seems to be triggered by having a form in the iframe.
Here's a StackOverflow post with a suggestion on how to solve this.

I tested how Codepen handles this. It does work fine there. Some notable differences:

• X-Frame-Options is ALLOWALL on Codepen, SAMEORIGIN on fCC. I think this is unlikely to be the cause, but it may be related.
• X-XSS-Protection is 1; mode=block on fCC, but not present on Codepen. I think this is why it does work on Codepen but not on fCC.

/cc @freeCodeCamp/moderators This looks like it has the potential to become a very serious issue for us, but I'm not certain. Can anybody help investigate?

@systimotic thanks for bringing this to everyone's attention. Yes - this is a serious issue. If Google rolls out this update, it will completely break our challenges. So we need to fix this ASAP.

Have you been able to make any progress on this?

@BerkeleyTrue is this something you could fix and deploy to production real quick, or do you have someone in mind for delegating this?

On Mon, Mar 13, 2017 at 6:44 PM, Quincy Larson notifications@github.com
wrote:

@systimotic https://github.com/systimotic thanks for bringing this to
everyone's attention. Yes - this is a serious issue. If Google rolls out
this update, it will completely break our challenges. So we need to fix
this ASAP.

Have you been able to make any progress on this?

@BerkeleyTrue https://github.com/BerkeleyTrue is this something you
could fix and deploy to production real quick, or do you have someone in
mind for delegating this?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/13727#issuecomment-286147082,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX9USGhYYpx9VbE14GEjc5ELIWUePYCaks5rlWRggaJpZM4MS57P
.

I have an idea, I'll raise a PR against backup/master if my theory works out.

If it works I can then implament it for staging also

But please, if someone else has an idea, go ahead and work away at it

This seems like a critical issue

@QuincyLarson @systimotic @Bouncey Looking into it, (according to @timo's link) Chrome is changes the default behavior X-XSS-Protection: 1 to X-XSS-Protection: 1; mode=block. What this does is complete block a page from running when the source code for the page is within the request itself (i.e. code-url).

Before, the chromes default bahavior was to filter outs the parts of the script that would be considered harmful. We’ve gotten around this by encoding the specific parts that chrome would complain about (form actions and such) and then decoding them before injecting into the iframe.

Now the default behavior is going to block the page completely. This is what is causing the issue (I believe).

I downloaded Chrome canary and ~have not been able to replicate the issue (it is on version 59)~ I was able to replicate it by adding a script tag to the code-uri.

A fix may be as simple as changing our X-XSS-PROTECTION to 1;

I cannot replicate on beta, but I can on production

Chrome 57 is now the 'chrome stable' for Ubuntu

I cannot reproduce locally on backup/master

try to post back, via server control, some html and JavaScript code to server and you will see the issue.

happened to me on Chrome Version 57.0.2987.110 (64-bit) Win10 64bit

Hello, all,

please help me understand this better.

I am Business Analyst in Software company. We experience the issue that after 57.0.2987.98 Chrome update we get the error “This page isn’t working Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards). ERR_BLOCKED_BY_XSS_AUDITOR" - basically what you are discussing here.

My questions would be:

1. is it a bug or a feature?
2. if it is a bug - where could I get the information when it will be fixed?

We have number of customers who suffer from this error and we need to understand whether we should wait for the Chrome fix or to implement the fix on our side.

@dimapct This the repository for FreeCodeCamp.com not for Chrome. Please direct your questions related to your business software and chrome to the chrome team, not us.

@QuincyLarson
Chrome settings > advanced settings > Protect from dangerous sites > off
worked for me for a while

I have just come across this bug report. I wonder if my experience might shed some light on this.

When I write a post on Ubuntu Forums — which is a perfectly bona fide site — Chrome frequently, but not always, gives me this error when I press "Preview Post".

I have attempted to find a pattern, but it seems entirely arbitrary; I can type some wording, which Chrome accepts, and other wording, which it doesn't, and I see no significant difference between them. For example, sometimes Chrome blocks a post with quotes, and other times not.

I use Chrome 57 Stable (from the official Chrome repositories) on Linux Ubuntu.

(I shall adopt the suggestion by @QuincyLarson for the time being, although it's a bit nerving to turn it off!)

Unfortunately, the proposed solution from @QuincyLarson did not work for me.

However, there is further information, which I hope is of some help:

https://bugs.chromium.org/p/chromium/issues/detail?id=702542
https://bugs.chromium.org/p/chromium/issues/detail?id=706038
https://productforums.google.com/forum/#!msg/chrome/4MUJd75N4Jw/8uDOUMgrEQAJ

@paddylandau Thanks.

It seems the issue is solved by explicitly adding x-xss-protection headers to our csp. Anyone have some time to test this out?

The problem with adding this header is that it means reducing security, for the sake of Chrome. That seems weird to me.

Actually, if you set the header to 1, then you're just keeping the security the same and preventing Chrome v57 from increasing security. The only real difference is that v57 is noisily blocking some code that v56- and other browsers have been silently blocking up to now.

I'm still experiencing this issue :(

I'm still experiencing this issue on "Create a Form Element".

The interesting thing regarding this issue is when you complete the lesson on a different browser and return to Chrome and "view the solution" of that lesson, the code reads with no error and you can continue on with the next lesson. Any thoughts?

On Apr 10, 2017 10:21 AM, "Rogerio Penchel" notifications@github.com
wrote:

I'm still experiencing this issue :(

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/13727#issuecomment-293018041,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AV-9X3RBc4-MBzYNChdMp0_uZrywTADUks5rumUPgaJpZM4MS57P
.

i ran this in firefox and had no issues

@nvnellore This applies only to Chromium and, by extension, Chrome. No other browser gives this problem.

I've seen this ERR_BLOCKED_BY_XSS_AUDITOR when I add content with an

Sorry - should clarify ... trying to just update content on our shop cart.
Once this is included

we then get the ERR_BLOCKED_BY_XSS_AUDITOR error.

Experienced this right now.
@udbhavs 's solution worked just fine.

Chrome 57
Windows 10 - 64 bit

Chrome Version 57.0.2987.133 (64-bit)
Windows 8.1 Pro 64 bit

@ssisaias — The workaround (not a solution) from @udbhavs might work, but that is because it deliberately breaks security! It is not a reasonable workaround, and certainly not appropriate for a work-based computer or indeed any computer that holds confidential information.

The issue seems to be resolved by upgrading to version 58 (Version 58.0.3029.81 beta(64bit, on my machine). I was getting the same error and had to go into into the 3 dots -> about. Under the version was a button I had to press to complete the update from v57 to v58. Upon relaunch of Chrome issue was resolved.

@willdanneriv You are lucky, perhaps, because version 58 hasn't solved it for me. I still get the bug after today's update.

@paddylandau Perhaps. Are you on Beta or Stable?

@willdanneriv Stable. The one that was released to my machine today.
Version 58.0.3029.81 (64-bit)
Same as yours.

@paddylandau Did you follow the process I did under about and relaunch?
Just covering bases, sorry it's not working for you.

@willdanneriv — I use Linux, not Windows, so updates are automatically installed directly from the official Google repository. I started Chrome only after the updates were complete; the version number that I posted was a cut-and-paste from Chrome's "About Google Chrome".

As an experiment, I've hopped onto a Windows 10 machine and tried there, and I get the same problem (Chrome fully updated, of course).

Maybe the forum where you've tried this coincidentally today added the solution as described by @BerkeleyTrue above?

I am also experiencing this issue on my Mac running OS Sierra with Chrome 58.0.3029.81. I'm a bit confused on where to post, but hopefully this will work!

Am also facing the same issue in mac os.

I had the same issue now on Chrome, then went on Firefox to continue, since Chrome was stopping me from progressing. I advice if you have another browser, you do the same. However I still think we need to be assured that our private information is safe here

Is anyone still experiencing this in Chrome or Firefox? I just updated to Chrome 58 and can't reproduce the issue there, nor in the latest firefox.

When you are facing issue sign into other browser and try the same. I faced the issue in chrome and then tried in Safari i just done.

Is anyone still experiencing this in Chrome or Firefox?

Yes, I can reproduce with Chrome 58 on the Main website but same challenge works OK in beta website.

Maybe that's a lead to progress other than what Berkeley has already identified.

I noticed an issue though. I left chrome and continued on Firefox when I
saw the error message, so I did a few more exercises on Firefox, however on
the map that particular exercise was not ticked as done. It just appeared
as if it was skipped.
So I went back to Chrome now to do it and the bug has been fixed. However I
couldn't continue from where I stopped on Firefox, I refreshed the tab, and
I also closed the tab and re-opened it, but I was shown the next exercise
not the exercise I am currently working on Firefox.
I then signed-out of my account on Chrome and signed in again and was able
to select the exercise I want to do. I think the process can be done
better, so that if I refresh my tab it takes me to the exercise I stopped
at. Thanks for your help guys.

On Tue, Apr 25, 2017 at 7:34 AM, mrugesh mohapatra <[email protected]

wrote:

Is anyone still experiencing this in Chrome or Firefox?

Yes, I can reproduce with Chrome 58 on the Main website but same challenge
works OK in beta website.

Maybe that's a lead to progress other than what Berkeley has already
identified.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/13727#issuecomment-296928274,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZgA8UshOMmM5_yVN3POvedvIIVyoCL9ks5rzZPkgaJpZM4MS57P
.

--

Tobiloba Ogunlobiyi
+234 816 699 8393
www.linkedin.com/in/tobilobaogunlobiyi

@QuincyLarson — Yes, I still have this problem on Chrome 58.

@tobi10 — A simple refresh simply reloads the page, but doesn't refresh everything; it still uses the cache. To force a complete refresh and ignore the cache, press Ctrl+Shift+R. It should save you the hassle of signing out and in again.

@paddylandau - I have the same issue again, I got stuck at the first jQuery exercise and went to firefox to do the exercise and also did 4 more exercises. I then came back to Chrome to continue. I refreshed using ctrl + shift + R like you suggested and I logged out and logged in back but it shows that I'm stuck on that first exercise. Attached is a screenshot of the page

@tobi10 — I guess that you'll have to continue on Firefox. A nuisance, I know, so let's hope that Google fixes this bug soon.

Thank you @paddylandau

Please refer this comment.

I strongly believe the above comment correctly analyzes what's going on here.

This is most probably fixed in the staging because we have stopped automatic code execution on the page.

@willdanneriv - Thanks, your advice worked for me.

I'm having the same issue on that challenge, but I'm about to try it in Canary; which is the developer version of Google Chrome. If it works, I'll post another message here, and maybe we'll all just have to switch over.

I tried it all in Canary, and was able to easily finish without any errors or issues. I am Windows 7, and I do have the current version of Google Chrome, so it's not just a Windows 10 or old version of Chrome issue.

You guys can get Canary here, if you want to try it instead. https://www.google.com/chrome/browser/canary.html

I also have this on Vivaldi 1.8.770.56 (Stable channel) (64-bit) on Arch Linux - it is based on Chromium as well. Same place as @tobi10

I had this issue on Chrome but as per @paddylandau 's suggestion above, I did a hard refresh and then it worked. (CMD + SHIFT + R on Mac)

Issue again

Hi, this is a know issue. And we are trying to figure out ways to get this fixed.

Please DO NOT comment on this thread confirming the issue (as it is no longer required).

Please use the ( 👍 ) on the opening post in this thread instead.
We would like to keep this thread only for potential solutions.

Getting the issue in Chrome Version 58.0.3029.96 (64-bit).
Not getting the issue in Firefox Version 53.0.2 (32-bit).

Try not to use JavaScript.

I had same issues turned out that replacing JavaScript: void(0) with # resolved my problem.

Thank you.

On Mon, May 8, 2017 at 7:09 PM, priyasjoshi notifications@github.com
wrote:

Try not to use JavaScript.

I had same issues turned out that replacing JavaScript: void(0) with #
resolved my problem.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/13727#issuecomment-300032774,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AT1eCNOnLJ8N0nN5JHiBNCx-e4cFc42Cks5r37zDgaJpZM4MS57P
.

Current Workaround is to use Firefox instead of Chrome.

Please bear with us while we try and fix this.

from core team conversation today:

So I believe we may have to replicate the logic from beta. Mainly, striping the solution from the uri on read, disable auto run, and add code locking

Some code used in production to strip and lock code uri (solution in uri)

https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/client/sagas/code-storage-saga.js#L98

The utils used to do this:
get the code from the uri:

https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/client/utils/code-uri.js#L52

remove code uri:

https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/client/utils/code-uri.js#L66

Here in the epic that handles building the files before they go to the iframe is where we check whether the code will run automatically

https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/client/sagas/build-challenge-epic.js#L24

Here we lock the execution button in the classic view and display an unlock button

https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/common/app/routes/challenges/views/classic/Tool-Panel.jsx#L64

note: I have a major refactor in the works that will break all these links. I'll updated them in a separate comment when that PR is merged in

Thanks @BerkeleyTrue, going to take a crack at it tonight.

@raisedadead awesome - thanks for your help. Please keep us posted, and let us know if you need any backup.

Last Tuesday, @raisedadead and I looked into this issue. I'm sharing our findings here, supplemented by things I found afterwards on my own. I hope this will give some background into why we believe this is the way to fix this issue.

This issue is _not_ reproducible on the freeCodeCamp beta, in any browser, with any code.

Using the code shared in the initial report, this issue _is_ reproducible in Chrome 57 and Chrome 58 (current), but _not_ in Chrome 59 (Chrome Beta) or Chrome 60 (Chrome Canary).

On this line, we enable the helmet xxsFilter plugin. It sets the X-XXS-Protection header to 1; mode=block. It has been there for two years.
Let's look at the error again:

The XSS Auditor blocked access to 'https://www.freecodecamp.com/challenges/add-a-submit-button-to-a-form#?solution=solution-here' because the source code of a script was found within the request. The auditor was enabled as the server did not send an 'X-XSS-Protection' header.

This confuses me. We have always sent this header, it's definitely there in the response, but it still says it's not there. My best guess as to why this is happening: the header is sent for the /add-a-submit-button-to-a-form page. The problem occurs on the /add-a-submit-button-to-a-form#?solution=solution-here, which it considers different, somehow. I believe this may be a bug in Chrome.

In Chrome 57, no header present was changed to default to 1; mode=block, and 1 would also be handled as 1; mode=block [source]. This is why we started noticing this issue from that version. I've not yet discovered the source for this problem no longer being present from Chrome 59. I'm not sure whether they've only fixed our specific issue, or whether they rolled back their change from version 57.

Here's a short summary of what the XSS auditor does (or at least, how I understand it): it looks at the URL and the page source code. If it finds a script (or something else that seems malicious) in the URL that it also finds in the HTML, it will block the page. [source 1] [source 2] [source 3]

The proper and easiest solution should be to set the X-XXS-Protection header to 0. We tried this, however, as this header is not picked up (I don't understand why), this doesn't work. The alternative solution that has been suggested now would be to remove the code from the URL, so that the URL doesn't influence the page anymore, and the XSS auditor won't' freak out. I think it will be tricky to make this work within the production version, but I do believe it should solve the problem. I believe this is what @raisedadead is working on.

Thanks for the insight, and the excellent sum up what we debugged the other day. Yes, it's a bit tricky on the production site, I'll update asap.

Adding this "--disable-xss-auditor" to the target field of the chrome shortcut got it working for me.

It didn't work on Chrome or Firefox (54.0b12) for me. Had to resort to using IE.

This has been fixed both in beta and in the main website.
Happy coding!