【51CTO.com 独家特稿】随着信息技术的告诉发展，企业中的信息系统越来越复杂，就目前的趋势而言，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]数字签名 #p#
（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框架准则，这样做在发现和修复漏洞方面具有良好的成本效益，越是到生命周期后面，发现错误和漏洞时的补救成本越高。
一些开发团队在前期收集需求的阶段不重视安全需求，忽略了这方面的需求分析，这样设计开发出来的系统当然不能很好地抵御威胁，在编码阶段，程序员也没有获得具体的安全需求，可能在代码中混杂了很多具有缺陷的代码，在移交给用户方时，常常缺少专业的安全人员进行评估，用户一味地信任系统开发方，当然作为系统开发方而言，肯定也不愿意找安全专家在此时来评估系统漏洞，因为此时发现的错误和漏洞要修复成本非常高昂。
下面一一个表列出系统生命周期内不同阶段修复漏洞的成本。#p#
错误类型 设计 编码 集成 Beta 部署
设计 1x 5x 10x 15x 30x
编码 1x 10x 20x 30x
集成 1x 10x 20x
发现错误时间越晚，修复的相对成本越高
选择正确的测试方法
为了避免出现在部署时才发现问题，系统研发团队应该建立一套良好的安全测试方法，在开发过程中和质量管理一起形成一个有机的保障屏障。下面列出已知安全测试的方法及对应的优缺点，以供大家参考：
描述 优点 缺点
（1）手动测试由安全专家利用工具和脚本进行渗透和安全验收测试 对具体的应用功能发起有针对性的测试
[a]受限于测试专家
[b]可能导致更高的错误率和循环成本
[c]由于时间限制，限制了应用的覆盖率
（2）自动化测试包括两种方法：
[a]自底向上 - 测试具体的个别功能，有开发人员自己实现
[b]自顶向下 - QA团队从最终用户的角度建立测试 质量高，减少测试和迭代开发过程 比手动测试需要更大的开销
（3）黑盒或系统测试只查看系统的输入输出，修改正常的用户输入查看应用程序的行为 使用成熟度非常高的自动化测试工具，学习难度较低
[a]可能只有当所有应用程序组件都就绪后才能开始测试（通常是在产品开发后期或在生产环境中使用）
[b]可能产生无法忽略，无法回退的事务
（4）白盒测试为特定功能错误评估个别组件，通常结合代码扫描工具和同级评审 可以使用与开发IDE环境集成的工具
[a]不能暴露需求和设计缺陷
[b]可能不会暴露包含在多个组件内的漏洞，或在单元测试时段可能不会暴露
[c]需要编码人员承担安全测试表3 Web应用程序安全测试方法说了半天，那究竟该如何保护Web应用程序呢？下面就谈谈保护Web应用程序的四个最佳实践。
保护Web应用程序的四个最佳实践
（1）增强安全意识这包括通过培训、交流增强团队成员的安全意识，当然有一个安全专家作顾问就更好了。最少每年也得在团队成员之间开展一次安全培训，包括开发人员、质量保证人员、分析人员和部门经理。
描述当前的攻击方式和推荐的补救措施，讨论组织的当前安全实践，开发人员必须参加培训，要掌握框架内置的安全功能。另外值得一试的是持续收集和整理其它团队分享的经验，团队之间经常保持交流，团队内部更是应该经常开展安全编程讨论。
（2）分类应用程序风险和责任每个组织的资源都是有限的，必须为其设置优先级，通过以下手段可以帮助你设置安全优先级：
[a]定义风险阀值，指定什么时候安全团队应该终止应用程序服务。
[b]按风险因素对应用程序进行分类，如互联网、局域网和外部网。
[c]定期进行安全扫描，生成安全报告。
[d]创建一个数据库，按风险分析和排列应用程序。
（3）建立零误差执行政策在开发和部署阶段建立零误差执行政策，可以降低部署含有缺陷的系统的风险，在开始阶段就要确定好在系统真正部署前必须经过什么测试才能上线，并把这个决定通知给所有团队成员，在开始编码前必须评审需求说明书和设计说明书，真的不能少了这些必要的步骤，这点时间是节约不得的。
（4）从开发到交付的整个周期要不停地测试通过不停的测试、评审对设计、开发都有正面影响，在整个软件生命周期内都应该有测试活动，并且确定你的测试框架包括以下内容：
[a]使用自动化测试工具，使得测试工作可以随时开始。
[b]包括单元测试和系统测试。
[c]允许在生成系统中进行审核测试。
[d]包括事件驱动测试。
[e]使用一个敏捷的开发方法。
[f]可以在编码、测试、集成和生成时运行测试。
因为越到后面缺陷修复的成本越高，故做好前几个阶段的工作，能够提前预知可能发生的潜在风险那是最好不过了，因此本文限于篇幅，也只限于整理开始阶段和建模编码阶段的建议。
（1）开始阶段 - 定义好安全需求应用相关 要考虑的限制和需求应用环境
（1）确定并认可组织安全策略
（2）认识基础设施的限制，如防火墙、协议和服务
（3）确定托管环境的限制，如VPN
（4）确定应用程序部署配置
（5）确定网络域结构、集群和远程应用服务器
（6）确定数据库服务器
（7）确定环境支持哪些安全通信功能
（8）确定可扩展性和性能指标输入数据校验
安全性考虑 详细说明 建议编码实践
（1）未测试时不要减少或修改默认安全设置
（2）代码不要含糊
（3）不要暴露不需要的信息
（4）尽早发现并修复安全错误
（5）不显示堆栈跟踪或有关敏感信息输入数据校验
小结
纵观这几年信息技术的发展势头，越来越多的政府机关和企事业单位都积极投身于自身的信息化建设，几乎每个企业都运行有与自身相关的业务系统和网站。
而且今后的发展趋势会是Web化，集成化，越来越多的数据在网络上传输，而且正在逐步向互联网方向进化，攻击事件逐年递增，攻击手段越来越先进，越来越傻瓜化，安全如果不从源头抓起，那就只是一句空话，过分信任安全设备和软件厂家潜在的风险实在太大，只有多方积极配合，相互协调才能真正应对Web应用程序未来的挑战。
【51CTO.COM 独家特稿，转载请注明出处及作者】
