理解Web应用程序的安全挑战

　　随着信息技术的告诉发展，企业中的信息系统越来越复杂，就目前的趋势而言，Web应用程序在企业中占据主要地位，因此企业越来越依赖于Web应用程序，目前在安全方面考虑最多的可能是在服务器前部署防火墙，开启SSL协议和主机加固，但遗憾的是攻击的主要目标现在已经逐渐转移到Web应用程序本身了，这些保护措施已经变得越来越没有用了。

　　是什么使Web应用程序变得脆弱的呢?

　　按照OSI参考模型来看，信息的传输要通过多层网络协议，处于顶层的应用层包括HTTP、FTP等协议，本文的重点放在HTTP协议上，传统的防火墙不能有效地阻止这一层协议，因此许多攻击者都喜欢在网络层构造虚假的HTTP请求，在其中夹杂攻击代码。

　　HTTP携带式攻击允许无限制地对数据库访问，并可以执行任意系统命令，甚至修改网站内容。由于缺乏和不重视对Web应用程序的安全管理和测试，很容易将系统漏洞暴露给攻击者。主要有下面三方面的原因：

　　(1)分析人员和设计人员在考虑安全问题时，只考虑了网络安全，只有少数安全专家才会认证对待和思考应用层安全。

　　(2)开发团队认为应用程序安全是一个模糊的概念，或者在交付使用时发表声明，要求客户做好保护工作，使得安全性测试实施变得非常困难。

　　(3)即使进行了安全测试，也是放在软件生命周期的后期了，即由攻击者发起的攻击性测试。常见的Web应用程序攻击类型针对Web应用程序的攻击种类很多，切入点也有很多，通常，在一个Web系统中有下面这些攻击切入点，也正是要保护的点，如图1所示。

　　图1

　　图1 Web应用程序的安全问题

　　从上图可以看出，攻击者要发起攻击，有很多的入口点，那我们该怎么办呢?通常应该选择符合自己需要的防范措施和技术手段，而不应该一味地追求最新的攻击方式保护。下面列举出一些常见的攻击类型和防范措施，也许对你的Web应用程序有所帮助。

　　描述 常见原因 预防措施

　　(1)伪装传入一个不同用户的身份凭据、修改cookie或修改参数伪装成某个用户，或将cookie伪装成来自某个用户

　　[a]使用基于通信的身份认证，允许访问所有用户的数据。

　　[b]使用未加密的证书可能被捕获和重用。

　　[c]在cookie或参数中存储证书

　　[d]使用未经验证的认证方法或认证来自于不受信任的域。

　　[e]客户端软件不验证主机。

　　使用以下手段为证书提供严格的验证和保护：

　　[a]操作系统提供的框架

　　[b]加密令牌，如会话cookie [c]数字签名

　　(2)篡改未经认证就修改或删除资源(如丑化网站界面，修改传输途中的数据)

　　[a]未经验证就信任数据源。

　　[b]清洗输入数据，避免不想运行的代码执行。

　　[c]运行的权限越来越大。

　　[d]敏感数据位加密。

　　[a]使用操作系统锁定文件、目录和其它资源。

　　[b]验证你的数据。

　　[c]在数据传输过程中散列和签名(如使用SSL或IPsec)。

　　(3)否认试图破坏、隐藏或修改已经发生的事实(如删除日志，模仿一个用户请求修改)

　　[a]使用的是比较弱或缺乏授权的验证程序。

　　[b]不恰当的日志记录。

　　[c]允许敏感信息在无任何保护的信道中传输。

　　[a]使用严格的认证、事务记录是数字签名。

　　[b]审核

　　(4)信息泄露泄露个人身份信息，如密码和信用卡数据，加上信息来源和主机信息

　　[a]允许授权用户访问其它用户的数据。

　　[b]允许敏感信息在不安全的信道上传输。

　　[c]选择了弱的加密算法和密钥。

　　[a]在会话上存储个人身份信息而不是永久性存储。

　　[b]无论何时，对敏感数据都使用散列和加密。

　　[c]以用户身份匹配用户数据

　　(5)拒绝服务(DoS)

　　[a]洪水攻击-同时向服务发送许多消息和请求。

　　[b]封锁-突然发送大量的请求，耗光资源使服务器响应变慢，迫使应用程序重启

　　[a]在一台服务器上放置了过多的应用程序或在一台服务器上部署了相互冲突的应用程序。

　　[c]忽略了全面的单元测试。

　　[a]使用防火墙过滤数据包。

　　[b]使用负载均衡设备控制对单一资源的大量请求。

　　[c]使用异步协议处理CPU密集型请求和错误恢复。

　　(6)特权提升超过正常访问权限获得管理员特权，访问机密文件

　　[a]以root或Administrator用户运行Web服务器进程。

　　[b]使用了代码出错时允许缓冲区溢出，将应用提升到调试状态。

　　[a]无论何时尽可能使用最小的权限。

　　[b]使用类型安全语言和编译器选项，预防或控制缓冲区溢出。

　　为Web应用程序提供安全保障的基本原则

　　使用安全的方法创建的应用程序可以避免受到表1中列出的那些攻击，当然对于现有的Web应用程序也可以采取一些补救措施来加强安全保护，包括：

　　(1)发现并建立基线

　　管理一个完整的应用程序和系统产品目录，包括技术信息，如ip地址，DNS，操作系统类型等，再加上一些商务信息，如谁批准开发的，如果系统故障应该通知谁，或谁负责处理。接下来完整扫描一次你的Web架构，找出其中的漏洞，检查清单和bug跟踪网站上有你操作系统、第三方应用程序和Web服务器的全部已知威胁，在上系统前，确保服务器已经打上所有的补丁，最后，测试应用程序认证和用户权限管理功能，并终止未知的服务。

　　(2)评估和转移风险

　　评估应用程序和系统的风险，主要集中评估数据存储、访问控制、用户配置和权限管理。优先考虑评估期间发现的应用程序漏洞，评审组织、行业和政府政策的遵从性，确定哪些操作可接受，哪些操作不能接受。

　　(3)保护应用程序避免危害扩散

　　掌控已知的安全威胁，并及时打上各类补丁，如果漏洞补丁还未发布，最好使用应用层防火墙限制访问，禁用应用或重定向到其它程序。

　　(4)持续的监测和评审

　　使用文档不间断地进行记录，持续监测，发现问题及时评审，最快做出响应。系统生命周期内的安全测试在Web应用程序开发早期使用RUP框架准则，这样做在发现和修复漏洞方面具有良好的成本效益，越是到生命周期后面，发现错误和漏洞时的补救成本越高。

　　一些开发团队在前期收集需求的阶段不重视安全需求，忽略了这方面的需求分析，这样设计开发出来的系统当然不能很好地抵御威胁，在编码阶段，程序员也没有获得具体的安全需求，可能在代码中混杂了很多具有缺陷的代码，在移交给用户方时，常常缺少专业的安全人员进行评估，用户一味地信任系统开发方，当然作为系统开发方而言，肯定也不愿意找安全专家在此时来评估系统漏洞，因为此时发现的错误和漏洞要修复成本非常高昂。

　　下面一一个表列出系统生命周期内不同阶段修复漏洞的成本。

　　错误类型 设计 编码 集成 Beta 部署

　　设计 1x 5x 10x 15x 30x

　　编码 1x 10x 20x 30x

　　集成 1x 10x 20x

　　发现错误时间越晚，修复的相对成本越高

　　选择正确的测试方法