应用程序：清楚应用程序的默认配置和安全环境

从网络和操作系统的观点看，许多问题都会把WEB服务器置于风险中。但管理员做的最糟糕的事情之一就是部署了IIS等产品后，就觉得“完活”了。保障IIS的安全本身就身就是一项艰巨的任务，不过，为使WEB 应用程序成为一个难以攻克的目标，你不必成为一个IIS权威。你只需要理解哪个WEB应用程序服务器的默认配置会增加风险，以及如何快速解决这些问题就可以了。

攻击者非常熟悉IIS，所以他们知道默认的IIS站点是放在c:inetpubwwwroot目录下。在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应用程序安全需要耗费很多时间和努力，但在与不付出这些时间和努力所造成的巨额代价相比，这是完全值得的。

请继续阅读提升WEB应用程序安全需要打“组合拳”（一）