Chrome：ERR_BLOCKED_BY_XSS_AUDITOR详细信息

Question

我试图发布然后获得一个简单的表格时会得到这个chrome标志。

问题是开发者控制台没有显示任何相关内容，我自己无法找到问题的根源。

有更多细节可供选择吗？ 查看触发错误的代码片段来修复它......

Answer 1

在开发过程中绕过此错误的简单方法是将标题发送到浏览器

  

在将数据发送到浏览器之前放置标题。

在 php 中，您可以发送此标头以绕过此错误send header reference：

header('X-XSS-Protection:0');

在 ASP.net 中，您可以发送此标头并send header reference：

HttpContext.Response.AddHeader("X-XSS-Protection","0");
or 
HttpContext.Current.Response.AddHeader("X-XSS-Protection","0"); 

在 nodejs 发送标题中，send header reference：

res.writeHead(200, {'X-XSS-Protection':0 });
// or express js
res.set('X-XSS-Protection', 0);

Answer 2

Chrome v58 可能 或 可能不会 修复您的问题......这实际上取决于您和＃ 39;实际上是POST。例如，如果您尝试在输入/ select / textarea元素中发布一些原始HTML / XML数据，则您的请求可能仍会被审核员阻止。

在过去的几天里，我在两个不同的场景中遇到了这个问题：一个WYSIWYG 客户端编辑器和一个以某种内容预览为特色的交互式上传表单。我设法通过在 POST之前对原始HTML 进行base64编码来修复它们，然后在接收PHP页面上对其进行解码。这很可能会解决问题，最重要的是，提高开发人员对来自POST请求的数据的认知水平，希望推动他采用有效的数据编码/解码策略，并通过XSS类攻击加强他们的Web应用程序

要在客户端上对您的内容进行base64编码，您可以使用现在大多数浏览器都支持的native btoa() function，或者使用第三方替代方案，例如jQuery插件（我最终使用了this，这样就可以了。）

要对POST数据进行base64解码，您可以使用PHP的base64_decode(str)函数，ASP.NET的Convert.FromBase64String(str)或其他任何东西（取决于您的服务器端场景）

有关详细信息，请查看我就该主题撰写的this blog post。

Answer 3

在这种情况下，作为Creative forums（某种vBulletin构造）的第一次撰稿人并减少在论坛访问之前向主持人发布PM，很容易从上面比较流行的答案中概括了问题的本质。 命令是

http://forums.creative.com/private.php?do=insertpm&pmid=

如上所述，实际数据是“输入/选择/ textarea元素中的原始HTML / XML数据”。

在用户端处理此类错误（或功能）的一般要求是某种快速修改或旋转。 This post讨论了清除缓存，重置Chrome设置，创建new_user或使用新的Beta版本重试操作的选项。 还有人建议用以下方法启动一个新实例：

google-chrome-stable --disable-xss-auditor

在此修改后的版本中，该推出实际上适用于此W10 1703 Chrome 061 版本：

chrome --disable-xss-auditor

但是，在重新登录到站点并再次尝试发布时，会生成相同的错误。也许语法想要提炼或其他东西都是错误的。

然后启动Edge并从那里重新发布似乎是合理的，结果证明完全没问题。

Answer 4

在某些情况下，此可能有帮助。修改Apache httpd.conf文件并添加

ResponseHeader set X-XSS-Protection 0

可能已修复Version 58.0.3029.110 (64-bit)。

Answer 5

我注意到如果文字中有撇号'，Chrome会屏蔽它。

Answer 6

当我在 POST请求页面中将javascript:void(0)从#更新为<a href="javascript:void(0)" id="loginlink">login</a> 时，就可以了。

例如：

<a href="#" id="loginlink">login</a>

更改为：

export MONGO_URL= mongodb://<dbuser>:<dbpassword>@ds035693.mlab.com:35693/abcd

Answer 7

这是一个Chrome错误。唯一的补救措施是使用FireFox，直到他们修复此Chrome错误。 XSS审核员破坏了一个已经工作了20年的页面似乎是一种症状，而不是原因。

Answer 8

我解决了这个问题！

在我的情况下，当我创建submmit时，我将HTML发送到操作，在模型中我有一个属性，接受HTML＆＃34; AllowHTML＆＃34;。

解决方案包括删除这个＆＃34; AllowHTML＆＃34;财产和一切都好！

显然我不再将HTML发送到动作，因为在我的情况下我不需要它