Chrome displays error message in iframe - Unsual code detected

[natuan62]

Update

Please use Firefox while we come up with a fix. Apologies for the inconvenience.

---

Challenge Add a Submit Button to a Form has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.88 Safari/537.36.

Description edited by @systimotic for clarification
There is a warning displayed in the phone frame. It says: "Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards)."

Code:

<link href="https://fonts.googleapis.com/css?family=Lobster" rel="stylesheet" type="text/css">
<style>
  .red-text {
    color: red;
  }

  h2 {
    font-family: Lobster, Monospace;
  }

  p {
    font-size: 16px;
    font-family: Monospace;
  }

  .thick-green-border {
    border-color: green;
    border-width: 10px;
    border-style: solid;
    border-radius: 50%;
  }

  .smaller-image {
    width: 100px;
  }
</style>

<h2 class="red-text">CatPhotoApp</h2>

<p>Click here for <a href="#">cat photos</a>.</p>

<a href="#"><img class="smaller-image thick-green-border" alt="A cute orange cat lying on its back. " src="https://bit.ly/fcc-relaxing-cat"></a>

<p>Things cats love:</p>
<ul>
  <li>cat nip</li>
  <li>laser pointers</li>
  <li>lasagna</li>
</ul>
<p>Top 3 things cats hate:</p>
<ol>
  <li>flea treatment</li>
  <li>thunder</li>
  <li>other cats</li>
</ol>
<form action="/submit">
  
</form>
<form action="/submit-cat-photo">
  <input type="text" placeholder="cat photo URL">
</form>

[erictleung]

@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!

[natuan62]

Oh, i forgeted about screenshot.

Nothing happen when I use firefox.

[szib]

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?

[natuan62]

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

[systimotic]

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.

[systimotic]

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?

[QuincyLarson]

@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?

[Bouncey]

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

[Bouncey]

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

This seems like a critical issue

[BerkeleyTrue]

@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.

[BerkeleyTrue]

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

[Bouncey]

I cannot replicate on beta, but I can on production

Chrome 57 is now the 'chrome stable' for Ubuntu

[Bouncey]

I cannot reproduce locally on backup/master

[GoceBogdanovski]

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

[driftshift]

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

[dimapct]

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.

[BerkeleyTrue]

@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.

[ghost]

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

[paddylandau]

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!)

[paddylandau]

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

[BerkeleyTrue]

@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?

[paddylandau]

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

[darkporpoise]

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.

[nvnellore]

I'm still experiencing this issue :(

[Rogerup]

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

[UnwrittenCanvas]

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?

[Lurches]

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 <#13727 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AV-9X3RBc4-MBzYNChdMp0_uZrywTADUks5rumUPgaJpZM4MS57P> .

[BerkeleyTrue]

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

[raisedadead]

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

[QuincyLarson]

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

[systimotic]

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.

[raisedadead]

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.

[Barryzachoppa]

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

[accidentalpurpose]

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

[raisedadead]

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