Issue 79014 in chromium: Refused to execute a JavaScript script. Source code of script found within request.

448 views
Skip to first unread message

chro...@googlecode.com

unread,
Apr 11, 2011, 6:56:11 AM4/11/11
to chromi...@chromium.org
Status: Unconfirmed
Owner: ----
Labels: Type-Bug Pri-2 Area-Undefined

New issue 79014 by cocomon...@hotmail.com: Refused to execute a JavaScript
script. Source code of script found within request.
http://code.google.com/p/chromium/issues/detail?id=79014

Chrome Version : 12.0.725.0 (Official Build 80304) dev
URLs (if applicable) :
http://www.w3schools.com/js/tryit.asp?filename=tryjs_text
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x: OK
IE 7/8/9: OK

What steps will reproduce the problem?
1. Go to any of the JS Tryit Editor samples on W3Schools.com.
2. Optionally edit the code.
3. Press "Edit and Click Me >>" button.

What is the expected result?
In the right frame, the output of the code in the left frame should be
shown.

What happens instead?
The right frame becomes blank.

Please provide any additional information below. Attach a screenshot if
possible.
If code within requests were allowed to execute, this page would function
correctly.

chro...@googlecode.com

unread,
Feb 20, 2012, 3:33:42 PM2/20/12
to chromi...@chromium.org

Comment #3 on issue 79014 by fbin...@gmail.com: Refused to execute a
JavaScript script. Source code of script found within request.
http://code.google.com/p/chromium/issues/detail?id=79014

As of 17.0.963.56 this has grown beyond just breaking on javascript source
references being the problem.

We have an <img src="" /> within a richtext editor. User presses "preview"
to see what the post would look like once parsed. A $_POST is sent and
away we go to see what the post would look like parsed. We also populate
editor again with the same content.

Now the existence of the <img src="" /> from the previous page is throwing
the infernal XSS error and disabling javascript on the page. This <img
src="" > is an element, not a string in a text node. It is displaying an
image in the text editor.

chro...@googlecode.com

unread,
Feb 20, 2012, 4:50:09 PM2/20/12
to chromi...@chromium.org

Comment #4 on issue 79014 by fbin...@gmail.com: Refused to execute a
JavaScript script. Source code of script found within request.
http://code.google.com/p/chromium/issues/detail?id=79014

It is worse than I thought.

Say you have an editor and in your page source you have a script reference,
say

<script type="text/javascript"
src="https://www.vbulletin.com/forum/clientscript/vbulletin-core.js?v=4110c"></script>

Now say, within the editor you type:

src="https://www.vbulletin.com"

Or even better, your editor has an image in it like

<img src="https://www.vbulletin.com/me.png" />

Now you preview, and bang, javascript is dead because Chrome insists on ANY
usage of src="yourdomain" appearing in the request means that an XSS has
been triggered.

Previously I would have to have this in my request to trigger the problem:

src="https://www.vbulletin.com/forum/clientscript/vbulletin-core.js?v=4110c">

Now you've pared it down to just this

src="https://www.vbulletin.com">

chro...@googlecode.com

unread,
Feb 20, 2012, 4:54:11 PM2/20/12
to chromi...@chromium.org

Comment #5 on issue 79014 by fbin...@gmail.com: Refused to execute a
JavaScript script. Source code of script found within request.
http://code.google.com/p/chromium/issues/detail?id=79014

It is worse than I thought.

Say you have an editor and in your page source you have a script reference,
say

<script type="text/javascript"
src="https://www.vbulletin.com/forum/clientscript/vbulletin-core.js?v=4110c"></script>

Now say, within the editor you type:

src="https://www.vbulletin.com"

Or even better, your editor has an image in it like

Now you preview, and bang, javascript is dead because Chrome insists on ANY
usage of src="yourdomain" appearing in the request means that an XSS has
been triggered.

Previously I would had to have this in my request to trigger the problem:

chro...@googlecode.com

unread,
Feb 7, 2013, 9:42:53 AM2/7/13
to chromi...@chromium.org

Comment #6 on issue 79014 by seantar...@gmail.com: Refused to execute a
JavaScript script. Source code of script found within request.
http://code.google.com/p/chromium/issues/detail?id=79014

Also seen when adding an iframe to a page when using Drupal to edit a page.

To reproduce: as a website editor, try to add iframe embed code for a
google calendar. When the page is saved for the first time, Drupal
displays the updated page, or optionally a preview of the page.

It turns out that in current version of Chrome - 24.0.1312.57 for OS X, the
content of the iframe will silently be dropped, and an error message will
only appear in the Chrome error log.

"Refused to execute a JavaScript script. Source code of script found within
request."

I expect to see either the contents of the frame, or at least some form of
error message to let me know about this change of behavior.

This occurs when adding a more complex page including scripts such as a
Google Calendar, or a embedding simple web page with no javascript.

On editing and saving the page after adding some html using a web based
editer
<iframe src="http://calendar.google.com......."></iframe>

Also occurs when embedding a simple page with no included javascript

<iframe src="http://www.example.com"></iframe>

It seems that example.com has a website now provided by IANA.

Sean Farrell
Edinburgh





chro...@googlecode.com

unread,
Apr 5, 2013, 1:17:25 PM4/5/13
to chromi...@chromium.org
Updates:
Cc: mk...@chromium.org

Comment #8 on issue 79014 by bat...@chromium.org: Refused to execute a
JavaScript script. Source code of script found within request.
http://code.google.com/p/chromium/issues/detail?id=79014

(No comment was entered for this change.)

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

chro...@googlecode.com

unread,
Jun 12, 2013, 7:21:24 AM6/12/13
to chromi...@chromium.org

Comment #10 on issue 79014 by Austin.France: Refused to execute a
JavaScript script. Source code of script found within request.
http://code.google.com/p/chromium/issues/detail?id=79014

I am getting this for something I would not expect. On my page I have two
buttons (List Templates and Add New)

<button onclick="location.href = 'template_list.asp'">List
Templates</button>
<button onclick="location.href = 'template_edit.asp'">Add New</button>

Both these buttons are triggering

The XSS Auditor refused to execute a script in '...' because its source
code was found within the request. The auditor was enabled as the server
sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.

What is wrong with that javascript?

Needless to say the buttons are rendered useless. In initial load (GET) of
the page the XSS Auditor is completely fine with those buttons, its only
when a form submitted (POST) and it goes back to the server, updates the
database, then redisplays the same form, that XSS Auditor gets upset.

There are no iframes, no cross domain scripting or anything going on.

Chrome: 27.0.1453.110

chro...@googlecode.com

unread,
May 19, 2015, 1:21:32 AM5/19/15
to chromi...@chromium.org

Comment #11 on issue 79014 by ibma...@gmail.com: Refused to execute a
JavaScript script. Source code of script found within request.
https://code.google.com/p/chromium/issues/detail?id=79014

I am also having the same problem as reported by Austin from France. My
point is that why chromium would trigger the XSS behaviour when the request
domain is the same of the original domain? AFAIK, XSS was introduced to
protect vulnerabilities from Cross-Site Domain attack. But, there is no
cross-site issue when we are clicking a button whose action script changes
the page, but not the domain nor the site. And, the fix-up that you guys
proposed (i.e. to set a specific http header), we are not willing to apply
as doing such will make our pages MORE VULNERABLE to XSS attach by the
eavesdroppers. Chromium authority MUST fix this issue ASAP.
Reply all
Reply to author
Forward
0 new messages