由于WEB应用程序对于当今许多企业的内部和外部操作都极端重要，所以其可用性和安全性既是客户的期望又是其要求。因而，企业应该在WEB应用程序问题上不惜一切代价。同时，WEB应用程序的重要性也给安全专家带来巨大压力，因为没有什么会比企业的关键网站或应用被攻击、破坏更恐怖了。不幸的是，在构建应用程序的竞赛中，许多企业给开发者施加压力，要求其重点关注应用程序的安全。
本文将探讨如何在WEB应用程序的性能、可用性、安全性上达到平衡。
安全策略
在WEB应用程序安全问题上保持前瞻性和主动性应当成为IT的头等大事。如果WEB应用程序遭受破坏，企业往往会遭受极大损失。对于大型企业，丢失的不仅仅是金钱，更重要的是声誉的丧失。重要WEB应用程序经常遭受攻击会使客户和公司的CEO不满。不管是否可以避免攻击，IT往往会遭受谴责，虽然这未必公平。
在CIO和CFO们谈到“安全”时，他们往往会为高额费用而震惊。但是，企业未必需要将大把的金钱用于强化WEB应用程序。要赢得WEB安全的保卫战，企业需要打“组合拳”：将相关解决安全问题的最佳方法和工具结合起来。
你不必请一位资深的CISSP来加固你的WEB应用程序，也不必花太多金钱。但成功地强化企业的WEB应用确实需要花费时间、努力和一些交涉技巧(你对安全的担忧和关注在项目经理眼中也许就是在大惊小怪)。在固化企业的WEB应用程序时,你需要综合利用过程、工具、优化及最佳方法。一般说来，这些策略就是关于网络、与应用程序和过程相关的性质等。
WEB应用的最佳方法应从网络层开始，从WEB应用程序的开发到投入使用的整个过程中，都要将安全性作为头等大事。
网络：将服务器隐藏在DMZ(隔离区)
如果你是安全专家，可能会觉得此方法有点儿小儿科。但是，并非人人都是安全专家，而且即使最好的安全专家有时也会犯困。将WEB服务器放在DMZ 不会从技术上使WEB应用或网站更安全，但是一旦WEB服务器被成功攻击或破坏，该方法可以保护基础架构的其余部分免受攻击。
如果企业网站或WEB应用程序在自己的服务器上，那么，外围防御每天都会遭受各种扫描。你无法阻止攻击者探测外围的开放服务，但你可以在攻击者成功损害了一台WEB服务器后，使他难以造成更大的危害。将面向外部的WEB服务器放在DMZ中的要旨在于，将攻击者限制在一个较小的范围内，在一台服务器被攻克后，这样做可以限制其危害。例如，如果你将所有进入的连接都进行地址转换，使其到达内部网络，那么黑客就可以成功地利用未打补丁的漏洞或使用SQL注入实现特权提升，从而可以无限制地访问内部网络。
网络：重新审查防火墙规则
减少WEB应用程序攻击面的最简捷的方法之一就是保证丢弃所有进入WEB服务器群端口的连接。如果你暴露了一个WEB应用，就没有理由在WEB服务器上允许RDP，也没有理由允许ICMP。暴露WEB服务器上的其它TCP/UDP服务可能需要测试或诊断，但除却TCP的80端口或443端口，没有理由允许任何进入的连接到达WEB服务器。安全管理专家应经常检查防火墙的规则的异常情况，特别是如果企业有几个人在管理防火墙，经常审查就尤其重要了。
工具：保护前端
如果你要保护内部的WEB应用程序，一般并不需要WEB应用程序防火墙。但是大型企业往往拥有面向外部世界的WEB应用程序，如果这些程序出现问题，企业将丧失大量金钱，因而企业非常需要WEB应用防火墙。
无疑，一个遵循谨慎原则而开发的应用程序不可能需要WEB应用防火墙级的保护。但是，有时WEB的开发者们不验证用户提供的输入，此时最大敌人恰好是开发者自己。而且，从编码的观点看，WEB开发者也无法保护WEB应用程序免受旷日持久的DoS攻击;虽然我们应当责备开发者因粗心大意而使网站遭受SQL注入攻击，但如果系统管理员没有正确地强化WEB服务器，也没有及时打补丁，是不是也应承担责任呢?在出现问题时，再去探究漏洞是否是人为错误造成的就没有太大意义了。关键的问题是，WEB应用防火墙对于保护WEB应用程序免于遭受各种攻击和漏洞利用可谓意义重大，最根本的问题是防止漏洞被利用。企业需要判定不部署WEB应用防火墙的风险是否超过其益处。
应用程序：强化WEB服务器
脆弱的WEB应用程序会将企业暴露在不必要的风险中。将WEB服务器部署在Linux而非Windows上未必会更安全。配置错误的Apache部署与配置错误的IIS一样脆弱。同样的理论也适用于底层的操作系统。
事实上，如果你仅仅固化WEB服务器自身却没有强化底层的操作系统，那么你就不可能覆盖攻击WEB应用程序的所有漏洞。正如企业应当过滤防火墙上所有不必要的协议一样，移除那些对于WEB应用程序非必需的系统服务也非常重要。
例如，Windows Server 2008的默认部署包含50个正在运行的服务，而Windows Server Core的默认部署仅包含36个服务。虽然IIS会增加少量服务，但是借助用于部署WEB服务器的方法来进行简单优化，就可以极大地减少WEB应用程序的攻击面。当然，在Linux中，禁用一些不必要的正在运行的进程从而强化底层操作系统，也可以达到同样的优化目的。花时间从服务器中清除不必要的服务是改善WEB应用程序安全状况的最简捷步骤。
工具：经常使用漏洞扫描器
不管企业的变更控制过程如何严格，业务的自然过程(无论是否受到控制)都会产生新漏洞。这些漏洞有可能是防火墙变化的结果，也可能是更新WEB应用程序或底层操作系统、新发现的零日漏洞、错误配置的结果。
新发现漏洞的原因并不重要，因为最重要的问题是能够发现并解决安全问题。不幸的是，你不能依靠某个安全专家甚至不能依靠某个安全团队，去发现WEB应用程序环境中的漏洞。在一个WEB应用程序投入使用时，发现新漏洞的责任最好交给可以主动发现安全问题并在问题发时生发出警告的自动化工具。
没有什么可以替代一个健全的漏洞扫描器，我们也没有理由不去使用这种工具，因为这种扫描器便宜且易于部署。
应用程序：清楚应用程序的默认配置和安全环境
从网络和操作系统的观点看，许多问题都会把WEB服务器置于风险中。但管理员做的最糟糕的事情之一就是部署了IIS等产品后，就觉得“完活”了。保障IIS的安全本身就身就是一项艰巨的任务，不过，为使WEB 应用程序成为一个难以攻克的目标，你不必成为一个IIS权威。你只需要理解哪个WEB应用程序服务器的默认配置会增加风险，以及如何快速解决这些问题就可以了。
攻击者非常熟悉IIS，所以他们知道默认的IIS站点是放在c:\inetpub\wwwroot目录下。在IIS中，WEB应用程序运行在用以隔离应用程序从而实现更好安全的应用程序池中。不过，狡猾的攻击者知道默认的应用程序运行在网络服务(Network Service)账户下。网络服务(Network Service)账户拥有的权利超过了用户给予应用程序池的权利。所以，禁用默认配置并创建一个由新账户保障其安全的新应用程序池是最简单有效的安全建议。攻击者还知道，默认情况下，应用程序池运行在iUSR_Host_Name账户下。如果攻击者可以发现WEB服务器的主机名，就可以知道答案并关闭iUSR账户，并通过发送假冒的认证请求而攻克WEB服务器。
为保障IIS服务器的安全，管理员应当做的事情有很多，但是保留WEB服务器的默认设置是一个很容易避免的安全问题。
过程：参加设计会议
技术不可能完全解决安全方面的每一个问题，因为我们还需要其它方面的工作。
有些开发者可能会认为，在开发应用程序时，安全并非头等大事。这并不是说开发者不关心安全问题，但紧迫时间表和资源可能会阻止开发者重视安全问题。另外，有的开发者还可能缺乏安全编程所需要的知识。
例如，安全专家都知道当开发者在WEB应用程序中使用动态查询却没有对用户提供的输入信息进行净化时，就有可能面临SQL注入风险。如果安全专家在在WEB应用程序的设计会议上询问一下，就会发现几乎所有的开发人员因为执行速度问题而偏爱动态查询。但通过使用存储过程或参数化查询，开发者就可以防止攻击者歪曲查询结果。如果你无法提出建议，你就不可能影响关键的设计决策，无法对最终的产品的安全性产生重要影响。
在设计阶段安全专家应当解决的另一个问题是，将要增加到WEB应用程序上去的数据验证方法。不正确地验证数据就会给SQL注入和跨站脚本攻击敞开大门。WEB应用程序不应当允许用户在一个字段中输入指向恶意脚本的URL。同样地，WEB应用程序也不应当允许用户在一个本该输入电话号码的字段中输入SQL命令。
多数开发者知道，在涉及到数据验证问题时，首要的规则就是绝对不相信用户提供的输入。但是，数据验证并不是安全专家在WEB应用程序的设计会议期间应当提出的唯一的问题，“数据消毒”问题也必须解决。例如，在多数情况下，用户不应当能够在一个字段中输入由HTML标记封装起来的数据。在一个期望捕获基本的用户信息的WEB表单中，在将一个字符串的值写到数据库中时，我们有什么合理的理由可以存储HTML标记吗?
这里你就需要做出判断了：如果此时谈论的WEB应用程序的某些字段要求使用HTML标记来构建更好看的清单，那么由于业务需要，你就需要在某些实例中处理HTML。但这类WEB应用程序也会强化安全策略，禁止使用可能有破坏性的HTML。所以，在设计阶段，这类WEB应用程序可以提供一个很好的范例，它会启发安全专家或具有安全意识的开发者对最终的WEB应用程序产品发挥重大影响。
处理：安全团队和质量保证团队应当紧密团结
在有些情况下，在一个新WEB应用程序的开发期间安排安全专家留在开发小组中也许不太可能或无法令人接受。但对于管理良好的开发项目来说，你一定要确保质量保证专员留在开发者的房间内。
在理想情况下，在涉及新WEB应用程序的测试过程中，安全和质量保证团队应当紧密团结。其原因很简单：质量保证团队的专家通常几乎没有应用程序的安全概念背景。所以，在与一个不使用相关安全最佳方法的开发团队进行合作时，最可能的产品有可能是一个漏洞百出的应用程序。
改变这种产品的最好而且是唯一的机会是，在发布新WEB应用程序的公共测试版本时，使安全团队或至少一个安全专家与质量保证团队在一起。如果你工作在一个中小型企业，开发团队还有可能就是质量保证团队，或企业将应用程序的开发外包出去。
无论怎样，安全专家必须能够阐述明白：具体的SQL注入攻击、XSS攻击或LFI/RFI攻击如何实现。这将会给开发过程带来巨大价值。
最终目标是部署一个稳定而安全的WEB应用程序。所以，从安全的观点看，安全专家们的思考和行动能够像质量保证团队一样是非常重要的。这可能意味着主动提供质量保证服务或关注发布版本日期，关注何时准备部署现有的产品更新(因为新版本需要进行测试)。虽然你作为一名安全专家出现在开发团队有时不太受欢迎，但日后你可能因帮助开发了一个更稳健和安全的WEB应用程序而得到感谢。而且，在此过程中，如果你能够教育WEB开发者黑客如何利用WEB应用程序的漏洞，就自然有助于确保未来的软件会包含使WEB应用程序更强健更安全的特性。
总体而说，WEB应用程序的安全并不是一个那么难的目标。虽然许多安全项目的成功存在于安全专家的手中，实现强健的WEB应用程序的安全要求企业各方的协同努力。
WEB应用程序的安全更应当是一个过程驱动的而不是技术驱动的问题，而且必须一直如此。我们不能用一个防火墙和反病毒软件来保障WEB应用程序的安全后就觉得万事大吉了。正如历经开发生命周期的其它任何软件一样，我们应当用一种可预测的和结构化的方法来实现保障WEB应用程序的过程。有时，保障WEB应用程序安全需要耗费很多时间和努力，但在与不付出这些时间和努力所造成的巨额代价相比，这是完全值得的。
