Javascript 在除Firefox之外的所有浏览器上都阻止了对EJS页面的XSS攻击

我使用以下非常简单的测试用例在浏览器上测试XSS：

该页面在Express+EJS上运行

在routes/index.js上，我设置了以下参数以获取关键字查询字符串值：

app.get（'/search'，函数（req，res）{
res.render（“../views/pages/index”{
标题：req.query.keyword
});
});

然后index.ejs页面接受title变量并将其呈现为：
（请注意，我没有转义title变量）
当我复制下面的URL（）时，有趣的是，我测试的每个浏览器（Chrome、Opera、Safari、IE8）都会发出警告，说他们拒绝执行脚本
因此，我想问题是，如果开发人员意外地未能像本例中那样转义字符串，并且除了Firefox之外的所有浏览器都捕捉到了这一点，那么Firefox在执行XSS审计时有问题吗？我这样想对吗

另外，作为开发人员，我们应该总是转义从URL或服务器传递的值，这是对的吗

提前感谢您的建议，如果我问了一些愚蠢的问题，请原谅——我刚刚开始学习XSS
 当然这不是一个愚蠢的问题，这是一个非常有效的问题。让我试着把一些事情整理一下

XSS的解决方案是输出编码。这意味着在将变量写入页面时，根据它们写入的上下文对特殊字符进行编码。对于html上下文（html标记之间的文本，甚至引号之间的标记属性值），它是html编码，但对于Javascript上下文（在html中的脚本标记之间或在事件属性（如onclick）中写入变量时），它必须是Javascript（字符串）编码

在一般情况下，只有对所有变量进行正确的输出编码才能阻止XSS（旁注：不必对静态和受信任的内容进行编码，但这种详细程度不适合这里的答案）

话虽如此，根据您使用的环境，还有其他一些保护措施可能在某些特定场景中有所帮助。然而，你不应该仅仅依靠这些，但它们有助于建立额外的防线

浏览器内置了这样一种防御机制。如果浏览器在查询中检测到其中一个参数是Javascript，然后相同的Javascript会反映在结果页面中，则某些浏览器实际上不会运行该参数，因为它是反映的XSS的一种明显形式。此行为由控制，在最近的浏览器中，您可以打开或关闭它。问题是到目前为止，这还不够。例如，当请求的Javascript直接反映在响应中时，它仅对反射的XSS有效。它可以在输入时存储在数据库中，并写入不同的应用程序响应（存储的XS），在这种情况下，保护是无用的。还有许多攻击向量（“利用XSS的方式”）不会被浏览器保护发现，尤其是当输入写入Javascript上下文时。请注意，由于此保护是浏览器的一项功能，它是特定于浏览器的，不同的浏览器可能会有不同的行为

还请注意，可能还有其他保护措施，例如.NET强制要求验证以尝试过滤恶意输入，以及html上下文的自动输出编码，但即使这些措施加上浏览器保护也不足以防止XSS。如上所述，XSS是一个输出编码问题，其他任何东西都无法阻止它（可能在某些特殊情况下除外）。然后我甚至没有提到DOM XSS，这是一个完全不同的类似问题类别，但在这个回答中，我想重点介绍内置在浏览器中的保护以及其运行的上下文。
感谢您的详细解释。如果你说.NET的HTML上下文+浏览器保护的请求验证和输出编码是不够的，那么在这个特定的例子中，我假设你说Javascript上下文的输出编码也是需要的？没错，例如
@HttpUtility.JavaScriptStringEncode（）
，或者更安全的
System.Web.Security.AntiXss.AntiXssEncoder
。此外，在Javascript中，您还可以通过将用户输入作为文本节点直接插入页面DOM来防止这种情况（实际上，这意味着使用jQuery的
.text（）
而不是
.html（）
，使用Knockout的
text
绑定而不是
html
，等等）。有意义-但如果您希望用户输入HTML标记并输出其HTML标记（例如，在类似这样的网站上）？您将对他们的输入进行编码，然后在输出到HTML时对其进行解码？这可能是防止XSS最困难的部分，解决方案不适合在此处添加注释，抱歉。很短的版本是你必须在某个地方进行消毒。没问题。谢谢你的帮助。：）