2

第一次使用 AntiXSS 4 用户。为了使我的应用程序更安全，我在 QueryString 参数 上使用了Microsoft.Security.Application.Encoder.UrlEncode ，在输入到表单字段中的参数上使用了Microsoft.Security.Application.Encoder.HtmlEncode 。

我有多个，如果您能尝试回答所有问题，我将不胜感激（不必同时回答或由同一个人回答 - 任何回避者都会非常有帮助）。

我的第一个问题是我是否适当地使用了这些方法（也就是说，我是否在适当的情况下使用了适当的 AntiXSS 方法）？

我的第二个问题是，一旦我编码了某些东西，它是否应该被解码。我很困惑，因为我知道HttpUtility类提供了编码和解码的方法，那么为什么在 AntiXSS 中不这样做呢？如果这有帮助，我编码的参数将永远不会被视为应用程序内的文本以外的任何内容。

我的第三个问题与第三个问题有关，但我想强调它，因为它很重要（并且可能是我整体困惑的根源）。我听说 .NET 框架会自动解码像 QueryStrings 这样的东西，因此不需要显式解码方法。如果是这样，那么如果要撤消它，那么首先对 HTML 进行编码有什么意义。它只是……似乎不安全？我错过了什么，特别是因为如上所述HttpUtility类提供解码。

最后一个问题，AntiXSS 是否有助于抵御 SQL 注入，还是仅能抵御 XSS 攻击？

4

1 回答 1

2

  1. 很难说你是否正确使用它。如果您在构建查询字符串时使用 UrlEncode，然后将其作为页面中的链接输出，那么是的，这是正确的。如果您在将某些内容写为值时是 Html 编码，那么是的，那是正确的（好吧，如果它是通过 HTML 属性设置的，您应该使用 HtmlAttributeEncode，但它们几乎相同。）

  2. .NET 解码器使用AntiXSS的编码值，所以我没有必要重写它们

  3. 编码的重点是在输出时进行。因此，例如，如果用户在表单上输入了 window.alert('Numpty!) 并且您只需将该输入原始放入输出中，javascript 就会运行。如果您先对其进行编码，您会看到 < 变为 < 等等。

  4. 不，SQL 注入是一个完全不同的问题。

于 2011-08-18T06:16:50.270 回答