c#post数据编码_确保应用安全的10件事：＃2编码数据

c#post数据编码

这是OWASP Top 10 Proactive Controls系列文章的第2部分，开发人员为确保应用程序安全可以做的10件事。 在上一篇文章中 ，我解释了为什么参数化数据库查询对于保护应用程序免受SQL注入 （最常见和最危险的攻击之一）如此重要。

SQL注入只是注入攻击的一种类型。 停止SQL注入很容易。 阻止其他类型的注入攻击（例如LDAP注入 ， XML注入或XPath注入 ， OS Command注入 ，尤其是Javascript注入（又称为跨站点脚本 ））需要做更多的工作；而停止NoSQL注入 – SSJS（服务器端Javascript）注入和针对NoSQL数据库的Schema Injection攻击-我们仍在学习如何做。

停止注射攻击

注入攻击的解决方案在概念上很简单：如果您无法清楚地将代码与数据分离（这是使用参数化API防止SQL注入的方法），则必须先确保数据安全，然后再将其传递给外部解释器（例如XML解析器或OS命令外壳或浏览器）。

您可以并且应该尝试通过编辑输入数据来做到这一点：拒绝任何不安全的数据。 但是在输入验证中可以遇到多少问题是有限制的，尤其是在您需要接受并允许使用自由格式的文本时。

因此，为了安全起见，您必须先输出编码或转义的数据，然后再将其交给解释器，以使解释器不会识别数据中的任何可执行语句。

细节在于魔鬼：您需要了解每个解释器的编码或转义规则，并且需要在特定的上下文中正确应用编码规则（并确保不要对数据进行多次编码）。 浏览器使这特别困难，迫使您知道如何以及何时在不同HTML，Javascript，XML和CSS上下文中正确编码数据。 仅对HtmlEncode数据还不够 ：

对于放置在HTML文档正文中的不受信任的数据（例如在<div>标记内），HTML实体编码是可以的。 它甚至可以处理进入属性的不受信任的数据，特别是如果您对在属性周围使用引号表示虔诚的话。 但是，如果将不受信任的数据放在任何地方的<script>标记内，或事件处理程序属性（如onmouseover），CSS内或URL中，则HTML实体编码将无法工作。 因此，即使您在各处都使用HTML实体编码方法，您仍然很可能容易受到XSS的攻击。 您必须在将不受信任的数据放入HTML文档的一部分中使用转义语法。

OWASP XSS（跨站点脚本）预防备忘单

有一些工具可以帮助您做到这一点：OWASP的ESAPI编码器 （用于CSS转义，HTMLEntity编码，URL编码和Javascript转义，以及Unix转义，Windows编码，VBScript转义，LDAP编码以及XML和XMLAttribute和XPath编码）， ，用于XSS保护的OWASP Java编码器 ，以及用于.NET的Microsoft开源Anti-XSS库 （用于XSS保护的编码器功能已从该库中获取，在.NET 4.5 AntiXssEncoder类中进行了改进和实现）。

但是即使使用这些工具，也可能难以正确完成所有工作，这就是为什么注入（尤其是XSS）是Web应用程序中最常见的主要安全漏洞之一的原因。 （要了解有关XSS的工作原理以及如何在应用程序中找到它的更多信息，请尝试玩Google的XSS游戏 ）。

CSP –停止XSS的另一种方法

一种完全不同且更简单的方法来保护您的Web应用不受XSS的侵害，特别是如果您是从头开始构建新的Web应用时，方法是建立强大的内容安全政策规则，以限制脚本和其他资源 （连接，图像，媒体，框架...），并阻止内联脚本（您需要相应地构建Javascript）。

内容安全策略：script-src'self'

这个HTTP标头就是您所需要的。 当然，这带有警告：某些情况可能无法通过内容安全策略限制来处理 ，Content-Security-Policy标头仅在较新的浏览器中实现（尽管它是向后兼容的），并且您取决于浏览器以正确实施规则，因此您的应用仍然容易受到浏览器错误的攻击。

观看真正的appsec 摇滚明星 Jim Manico讲解十大主动控制 。 如果您对此前10名列表中的内容有异议或不满，请花点时间发表评论。

翻译自: https://www.javacodegeeks.com/2014/06/10-things-you-can-do-to-make-your-app-secure-2-encoding-data.html

c#post数据编码