拒绝执行 JavaScript 脚本。在请求中找到脚本的源代码
在 WebKit 中，我的 JavaScript 出现以下错误：
拒绝执行 JavaScript 脚本。在请求中找到的脚本的源代码。
该代码适用于 JavaScript 微调器，请参阅 ASCII Art。
该代码过去工作正常，并且在 Camino 和 Firefox 中仍然可以正常工作。仅当通过 POST 保存页面然后通过 GET 检索页面时，才会引发该错误。 Chrome/Mac 和 Safari/Mac 中都会发生这种情况。
有人知道这意味着什么以及如何解决这个问题吗？
In WebKit I get the following error on my JavaScript:
Refused to execute a JavaScript script. The source code of script found within request.
The code is for a JavaScript spinner, see ASCII Art.
The code used to work OK and is still working correctly in Camino and Firefox. The error only seems to be thrown when the page is saved via a POST and then retrieved via a GET. It happens in both Chrome/Mac and Safari/Mac.
Anyone know what this means, and how to fix this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
可以通过发送非标准 HTTP 标头
X-XSS 来禁用此“功能” -受影响页面上的保护。This "feature" can be disabled by sending the non-standard HTTP header
X-XSS-Protectionon the affected page.这是一项防止XSS（跨站脚本）攻击的安全措施。
当某些 JavaScript 代码通过 HTTP POST 请求发送到服务器，并且相同的代码通过 HTTP 响应返回时，就会发生这种情况。如果 Chrome 检测到这种情况，脚本将被拒绝运行，并且您会收到错误消息
拒绝执行 JavaScript 脚本。在请求中找到的脚本源代码。另请参阅这篇关于深度安全：新安全性的博文特点。
It's a security measure to prevent XSS (cross-site scripting) attacks.
This happens when some JavaScript code is sent to the server via an HTTP POST request, and the same code comes back via the HTTP response. If Chrome detects this situation, the script is refused to run, and you get the error message
Refused to execute a JavaScript script. Source code of script found within request.Also see this blogpost about Security in Depth: New Security Features.
简短回答：首次提交 JavaScript 后刷新页面，或者点击将显示您正在编辑的页面的 URL。
长答案：因为您填写到表单中的文本包含 javascript，而浏览器不一定知道您是 javascript 的来源，所以浏览器假设您不是 javascript 会更安全这个JS的来源，而不是运行它。
示例：假设我给了您一个电子邮件或 Facebook 的链接，其中包含一些 javascript。想象一下 javascript 会向您所有的朋友发送我的酷链接。因此，调用该链接的过程变得简单，找到一个发送 javascript 的位置，以便将其包含在页面中。
Chrome 和其他 WebKit 浏览器尝试通过不执行响应中的任何 javascript（如果请求中存在）来降低此风险。我的邪恶攻击将被挫败，因为你的浏览器永远不会运行该 JS。
就您而言，您将其提交到表单字段中。表单字段的 Post 会导致页面渲染显示 Javascript，导致浏览器担心。但是，如果您的 JavaScript 确实已保存，则在不提交表单的情况下点击同一页面将允许其执行。
Short answer: refresh the page after making your initial submission of the javascript, or hit the URL that will display the page you're editing.
Long answer: because the text you filled into the form includes javascript, and the browser doesn't necessarily know that you are the source of the javascript, it is safer for the browser to assume that you are not the source of this JS, and not run it.
An example: Suppose I gave you a link your email or facebook with some javascript in it. And imagine that the javascript would message all your friends my cool link. So, the game of getting that link to be invoked becomes simply, find a place to send the javascript such that it will be included in the page.
Chrome and other WebKit browsers try to mitigate this risk by not executing any javascript that is in the response, if it was present in the request. My nefarious attack would be thwarted because your browser would never run that JS.
In your case, you're submitting it into a form field. The Post of the form field will cause a render of the page that will display the Javascript, causing the browser to worry. If your javascript is truly saved, however, hitting that same page without submitting the form will allow it to execute.
正如其他人所说，当 HTTP 响应包含请求中的 JavaScript 和/或 HTML 字符串时，就会发生这种情况。这通常是由于在表单字段中输入 JS 或 HTML 引起的，但也可以通过其他方式触发，例如手动调整 URL 的参数。
这样做的问题是，恶意的人可能会将他们想要的任何 JS 作为值，链接到具有恶意 JS 值的 URL，并给您的用户带来麻烦。
在几乎每种情况下，都可以通过 HTML 编码来修复响应，但也有例外。例如，这对于
正如 Kendall Hopkins 提到的，在某些情况下，您实际上想要执行表单输入中的 JavaScript，例如创建像 JSFiddle。在这些情况下，我建议您至少在盲目写回之前仔细检查后端代码中的输入。之后，您可以使用他提到的方法来防止 XSS 封锁（至少在 Chrome 中），但请注意，这会让您向攻击者敞开大门。
As others have said, this happens when an HTTP response contains a JavaScript and/or HTML string that was also in the request. This is usually caused by entering JS or HTML into a form field, but can also be triggered in other ways such as manually tweaking the URL's parameters.
The problem with this is that someone with bad intentions could put whatever JS they want as the value, link to that URL with the malicious JS value, and cause your users trouble.
In almost every case, this can be fixed by HTML encoding the response, though there are exceptions. For example, this will not be safe for content inside a
<script>tag. Other specific cases can be handled differently - for example, injecting input into a URL is better served by URL encoding.As Kendall Hopkins mentioned, there may be a few cases when you actually want JavaScript from form inputs to be executed, such as creating an application like JSFiddle. In those cases, I'd recommend that you you at least scrub through the input in your backend code before blindly writing it back. After that, you can use the method he mentioned to prevent the XSS blockage (at least in Chrome), but be aware that it is opening you to attackers.
我在提交数据库之后、从我的
_GET请求渲染脚本之前使用了这个 hacky PHP 技巧。：这对我来说是最便宜的解决方案。
I used this hacky PHP trick just after I commit to database, but before the script is rendered from my
_GETrequest.:This was the cheapest solution for me.