一旦某个内容被 HTML 或 URL 编码，它就应该被解码吗？编码足够了吗？
第一次使用 AntiXSS 4 用户。为了使我的应用程序更安全，我在 QueryString 参数上使用了 Microsoft.Security.Application.Encoder.UrlEncode 在表单字段中输入的参数上的 Microsoft.Security.Application.Encoder.HtmlEncode。
我有多个问题，如果您能尝试回答所有问题（不必同时回答或由同一个人回答 - 任何回答都会非常有帮助），我将不胜感激。
我的第一问题是我是否正确使用这些方法（即我是否在适当的情况下使用适当的 AntiXSS 方法）？
我的第二问题是一旦我编码了一些东西，它是否应该被解码。我很困惑，因为我知道 HttpUtility 类提供了编码和解码的方法，那么为什么 AntiXSS 中不做同样的事情呢？如果这有帮助，我编码的参数永远不会被视为应用程序内文本以外的任何内容。
我的第三问题与第三个问题相关，但我想强调它，因为它很重要（并且可能是我整体困惑的根源）。我听说 .NET 框架会自动解码诸如 QueryStrings 之类的东西，因此不需要显式的解码方法。如果是这样的话，那么如果 HTML 编码会被撤销，那它还有什么意义呢？只是……看起来不太安全？我缺少什么，特别是因为，正如前面提到的，HttpUtility 类提供了解码功能。
最后问题是，AntiXSS 是否有助于抵御 SQL 注入，还是只能抵御 XSS 攻击？
First time AntiXSS 4 user here. In order to make my application more secure, I've used Microsoft.Security.Application.Encoder.UrlEncode on QueryString parameters and
Microsoft.Security.Application.Encoder.HtmlEncode on a parameter entered into a form field.
I have a multiple and I would appreciate it if you could try to answer all of them (doesn't have to be at once or by the same person - any abswers at all would be very helpful).
My first question is am I using these methods appropriately (that is am I using an appropriate AntiXSS method for an appropriate situation)?
My second question is once I've encoded something, should it ever be decoded. I am confused because I know that HttpUtility class provides ways to both encode and decode so why isn't the same done in AntiXSS? If this helps, the parameters that I've encoded are never going to be treated as anything other then text inside the application.
My third question is related to the third one but I wanted to emphasize it because it's important (and is probably the source of my overall confusion). I've heard that the .NET framework automatically decodes things like QueryStrings, hence no no need for explicit decode method. If that is so, then what is the point of HTML encoding something in the first place if it is going to be undone. It just... doesn't seem safe? What am I missing, especially since, as mentioned the HttpUtility class provides for decoding.
And the last question, does AntiXSS help against SQL injection at all or does it only protext against XSS attacks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
很难说你是否正确使用它。如果您在构建查询字符串时使用 UrlEncode，然后将其作为页面中的链接输出，那么是的，这是正确的。如果您在将某些内容写为值时进行 Html 编码，那么是的，这是正确的（好吧，如果它是通过 HTML 属性设置的，您应该使用 HtmlAttributeEncode，但它们几乎相同。）
.NET 解码器使用 AntiXSS 的编码值，因此我重写它们是没有意义的 grin
编码的要点在于你在输出时进行编码。因此，例如，如果用户在表单上输入 window.alert('Numpty!) 并且您只需将该输入原始数据放入输出中，JavaScript 就会运行。如果你先对其进行编码，你会看到 <成为<等等。
不，SQL 注入是一个完全不同的问题。
It's hard to say if you're using it correctly. If you use UrlEncode when building a query string which is then output as a link in a page then yes that's correct. If you're Html Encoding when you write something out as a value then yes, that's correct (well kind of, if it's set via an HTML attribute you ought to use HtmlAttributeEncode, but they're pretty much the same.)
The .NET decoders work with AntiXSS's encoded values, so there was no point in me rewriting them grin
The point of encoding is that you do it when you output. So, for example, if a user has, on a form, input window.alert('Numpty!) and you just put that input raw in your output the javascript would run. If you encoded it first you would see < become < and so on.
No, SQL injection is an entirely different problem.