Web安全趋势与核心防御机制
孟飞阳 2012年1月16日
一． WEB安全技术产生原因
早期：万维网（World Wide Web）仅有Web站点构成，这些站点基本上是包含静态文档的信息库。这种信息流仅由服务器向浏览器单向传送。多数站点并不验证用户的合法性。
如今：已与早期的万维网已经完全不同，Web上的大多数站点实际上是应用程序。他们功能强大，在服务器和浏览器之间进行双向信息传送。他们处理的许多信息属于私密和高度敏感信息。因此，安全问题至关重要，Web安全技术也应运而生。
二． Web程序常见漏洞
（1）不完善的身份验证措施：这类漏洞包括应用程序登陆机制中的各种缺陷，可能会使攻击者攻破保密性不强的密码，发动蛮力攻击或者完全避开登陆。
（2）不完善的访问控制措施：这一问题涉及的情况包括：应用程序无法为数据和功能提供全面保护，攻击者可以查看其他用户保存在服务器中的敏感信息，或者执行特权操作。
（3）SQL注入：攻击者可通过这一漏洞提交专门设计的输入，干扰应用程序与后端数据库的交互活动。攻击者能够从应用程序中提取任何数据、破坏逻辑结构，或者在数据库服务器上执行命令。
（4）跨站点脚本：攻击者可利用该漏洞攻击应用程序的其他用户、访问其信息、代表他们执行未授权操作，或者向其发动其他攻击。
（5）信息泄露：这一问题包括应用程序泄露敏感信息，攻击者利用这些敏感信息通过有缺陷的错误处理或其他行为攻击应用程序。
三． 核心安全问题
如今的Web程序的核心安全问题为：用户可提交任意输入。具体为：
（1）用户可干预客户与服务器间传送的所有数据，包括请求参数、cookie和HTTP信息头。
（2）用户可按任何顺序发送请求。
（3）用户并不限于仅使用一种Web浏览器访问应用程序。大量各种各样的工具可以协助攻击Web应用程序，这些工具既可整合在浏览器中，也可独立于浏览器运作。这些工具能够提出普通浏览器无法提供的请求，并能够迅速生成大量的请求，查找和利用安全问题达到自己的目的。
四．目前针对Web安全问题提出的核心防御机制
Web应用程序的基本安全问题（所有用户输入都不可信）致使应用程序实施大量安全机制来抵御攻击。尽管其设计细节与执行效率可能千差万别，但几乎所有应用程序采用的安全机制在概念上都具有相似性。
Web应用程序采用的防御机制由以下几个核心因素构成。
（1）处理用户访问应用程序的数据与功能，防止用户获得未授权访问。
（2）处理用户对应用程序功能的输入，防止错误输入造成不良行为。
（3）处理攻击者，确保应用程序在成为直接攻击目标时能够正常运转，并采取适当的防御与攻击措施挫败攻击者
（4）管理应用程序本身，帮助管理员监控其行为，配置其功能。
五． 理论具体措施
针对以上四种原因，还有一些理论做法：
5.1处理用户访问
几乎任何应用程序都必须满足一个中心安全要求，即处理用户访问其数据与功能。大多数Web应用程序使用三层相互关联的安全机制处理用户访问：
（1）身份验证
（2）会话管理
（3）访问控制
5.2处理用户输入
许多情况下，应用程序可能会对一些特殊的输入实行非常严格的确认检查。例如，提交给登陆功能的用户名的最大长度为8个字符，且只能包含字母。
在其他情况下，应用程序必须接受更广泛的输入。例如，提交给个人信息页面的地址字段可合法包含字母、数字、空格、连字符、撇号与其他字符。但是仍然可以对这个字段实施有效的限制。例如，提交的数据不得超过某个适当的长度限制（如50个字符），并不得包含任何HTML标记（HTML mark-up）。
输入处理的几种方法：
（1）“拒绝已知的不良输入”
（2）“接受已知的正常输入”
（3）净化输入的数据：数据中可能存在的恶意字符被彻底删除掉，只留下已知安全的字符，或者再进一步处理前对他们进行适当编码或“转义”。
（4）安全数据处理：以不安全的方式处理用户提交的数据，是许多Web应用程序漏洞形成的根本原因。有些时候，可使用安全的编程方法避免常见问题。
（5）语法检查：为防止未授权访问，应用程序必须确认所提交的账号属于之前提交该账号的用户。
（6）边界确认：服务器端应用程序第一次收到用户数据的地方是一个重要的信任边界，应用程序需要在此采取措施防御恶意输入。
5.3边界确认的必要性
当我们开始分析一些实际的漏洞时，执行这种简单的输入确认是不够的，原因为：
（1）基于应用程序所执行功能的广泛性以及所采用技术的多样性，一个典型的应用程序需要防御大量各种各样的基于输入的攻击，且每种攻击可能采用一组截然不同的专门设计的数据，因此，很难在外部边界建立一个单独的机制，防御所有这些攻击。
（2）许多应用程序功能都涉及组合一系列不同类型的处理过程。
（3）防御不同类型的基于输入的攻击可能需要对相互矛盾的用户输入执行各种确认检查。例如：防止跨站点脚本攻击可能需要将“>”字符HTML编码为“>”，而防止命令注入攻击则需要防止包含 & 与 ; 字符的输入。有时候，想要在应用程序的外部边界同时阻止所有类型的攻击几乎是不可能的事情。
边界确认（boundary validation）是一种更加有效的模型。此时，服务器端应用程序的每一个单独的组件或功能单元将其输入当做来自潜在恶意来源的输入对待。除客户与服务器之间的外部边界外，应用程序在上述每一个信任边界上执行数据确认。这种模型为前面提出的问题提供了一个解决方案。每个组件都可能防御它收到的特殊类型的专门设计的输入。当数据通过不同的组件时，即可对前面转换过程中生成的任意数据值执行确认检查。而且，由于在不同的处理阶段执行不同的确认检查，他们之间不可能发生冲突。
5.4 多步确认与规范化
如为防御某些跨站点脚本攻击，应用程序可能会从任何用户提交的数据中删除表达式：<script>，但攻击者可通过应用以下输入避开过滤器：<scr<script>ipt>。由于过滤无法递归运行，删除被阻止的表达式后，表达式周围的数据又合并在一起，重新建立恶意表达式。同样，如果对用户输入执行几个确认步骤，攻击者就可以利用这些步骤的顺序来避开过滤。例如，如果应用程序首先递归删除脚本标签，然后删除引号，就可以使用以下输入避开确认检查：<scri*ipt>。
数据规范化（data canonicalization）会造成另一个问题。当用户浏览器送出输入时，它可对这些输入进行各种形式的编码。之所以使用这些编码方案，是为了能够通过HTTP安全传送不常见的字符与二进制数据。规范化是指将数据转换或解码成一个常见字符集的过程。如果在实施输入过滤之后才执行规范化，那么攻击者就可以通过使用编码避开确认机制。例如，应用程序可能会从用户输入删除撇号，以防止某些SQL注入攻击。但是，如果应用程序随后对净化后的数据进行规范化，那么攻击者就可以使用URL编码的输入避开确认。
有时候可能很难避免多步确认与规范化造成的问题，也不存在解决这类问题的唯一方案。
一种解决方法是递归执行净化操作，直到无法进一步修改输入。如果可能，最好避免清除某些不良输入的做法，完全拒绝这种类型的输入。
5.5 处理攻击者
为处理攻击者而采取的措施一般由以下任务组成：
（1）处理错误
（2）维护审计日志
（3）向管理员发出警报
（4）应对攻击
5.6 处理错误
应用程序的一个关键防御机制是合理地处理无法预料的错误，要么纠正这些错误，要么向用户发送适当的错误消息。再生产环境下，应用程序不应在其响应中返回任何系统生成的消息或其他调试信息。过于详细的错误消息非常有利于恶意用户向应用程序发动进一步攻击。有些情况下，攻击者能够利用存在的缺陷的错误处理方法从错误消息中获得敏感信息；此时，错误消息成为攻击者从应用程序中窃取数据的重要渠道。
大多数Web开发语言通过Try-catch块和受查异常提供良好的错误处理支持。应用程序代码应广泛使用这些方法查明特殊与常规错误，并作出相应处理。而且，还可以配置大多数应用程序服务器，使其以自定义的方式处理无法处理的应用程序错误，如提供不包含太多信息的错误消息。
5.7 维护审计日志
审计日志（audit log）在调查针对应用程序的入侵尝试时会发挥很大作用。发生入侵后，有效的审计日志功能能够帮助应用程序所有者了解实际发生的情况。
在任何注重安全的应用程序中，日志应记录所有重要事件。一般这些事件应至少包括以下几项。
（1）所有与身份验证功能有关的事件，如成功或失败的登录、密码修改。
（2）关键交易，如信用卡支付与转账
（3）任何包含已知攻击字符串，公然表明恶意意图的请求。
5.8 向管理员发出警报
审计日志可帮助应用程序所有者调查入侵企图，如有可能，应对侵入者采取法律行动。警报监控的反常事件一般包括以下几点：
（1）应用反常，如收到由单独一个IP地址或用户发出大量请求，表明应用程序正受到自定义攻击
（2）交易反常：如单独一个银行账户转入或转出的资金数量出现异常
（3）包含已知攻击字符串的请求
（4）请求中普通用户无法查看的数据被修改。
5.9 管理应用程序
许多应用程序一般通过相同的Web界面在内部执行管理功能，这也是它的核心非安全功能，在这种情况下，管理机制就成为应用程序的主要受攻击面。它吸引攻击者的地方主要在于它能提升权限，举例说明：
1.身份验证机制存在的薄弱环节使得攻击者能够获得管理员权限，迅速攻破整个应用程序。
2.许多应用程序并不对它的一些管理功能执行有效的访问控制。利用这个漏洞，攻击者可以建立一个拥有强大特权的新用户账户。
3.管理功能通常能够显示普通用户提供的数据。界面中存在的任何跨站点脚本缺陷都可能危及用户会话的安全
4.因为管理用户被视为可信用户，或者由于渗透测试员只能访问低权限的账户，所以管理功能往往没有经过严格的安全测试。而且，他通常需要执行相当危险的操作，包括访问磁盘上的文件或操作系统的命令。如果一名攻击者能够攻破管理功能，就能利用它控制整个服务器。
来源：oschina
链接：https://my.oschina.net/u/2391658/blog/709328