在《认识SOA应用安全问题（上）》中，我们为您介绍了支持Web服务应用平台要有难以置信的弹性，在实践中，这意味着它们有难以置信的复杂配置。这些配置文件的错误成为服务中的漏洞。下面将继续为年介绍相关内容。

　　由于Web服务的安全要求至少有点模糊的事实，这个情况恶化。Web服务应该是灵活的，以至于其他程序员能用他们来编排Web服务创建者也许没有想象过的应用，但这对于Web服务理解调用者的安全需求是很困难的。Web服务应该执行什么类型的输出验证呢？如果Web服务打算直接在Web浏览器中使用，那么它应该为防止跨站脚本攻击（XSS）采取预防措施。但如果Web服务的创建者不知道它将怎样被使用呢？那么就很难做出正确的安全决策。

　　考虑下面这部分代码。这是个从DionySOA拿过来的方法，DionySOA这个工程宣称它自己可以作为利用SOA和Web服务构建起来的代理商/经纪人服务平台。这个方法通过Web服务公开。（你得到一点暗示，当你看到它抛出java.rmi.RemoteException时，它也许从外部是可访问的。）这个方法包含明显的SQL注入弱点。它让它的攻击者提供了参数，将它连接成一个SQL查询字符串，并执行这个查询。尽管它在不需要Web服务的情况下也很可能产生这类错误，我们除了相信让你轻松摆脱输入验证的Web服务外没有别的办法。

　　类似地，如果一个新公开的方法常常依赖另一个应用的某个部分来完成访问控制检查，那这个Web服务接口现在就可能绕开那些检查，就会更跟不上信任边界的发展。

　　轻松地创建一个Web服务本身没有根本的错误，但创建一个好的Web服务实际上没有这么容易。我们目前关注的Web服务框架没有给程序员任何关于安全暗示的指南，这些安全暗示可能参与到程序内部的公开。

　　我们不是指这些例子不鼓励Web服务、XML和SOA框架的使用，而是让用户注意当部署这些技术时可能发生的过失。为了把安全因素作为软件开发过程的一部分考虑进去，这些例子很有希望成为催化剂。业务软件保证要求将安全融入到每一个步中，而不是在最后处理。就像质量保证对管理产品质量来说是可操作的解决方案，业务软件保证对管理软件风险而言是可操作的解决方案。下面这些活动应当成为任何软件工程的一部分：

　　像一个坏人一样思考。你会怎样来攻击这个系统？你会希望获得什么？

　　自动化的漏洞检测----源代码分析和动态安全测试----在代码部署前来鉴定漏洞。

　　一旦代码投入到生产环境中，要通过实时监测和主动防御来保护代码。

　　由于公司变得越来越依赖软件运行业务，同时也因为新技术能使旧的应用发现新的用途，公司必须把安全提升到一个优先考虑的级别。在软件安全方面，一个更主动的和系统化的方法将----最终——比随机安全策略更节省开支，更可预言。

　　关于作者：

　　Brian Chess是Fortify Software的建立者，同时也是Fortify公司的首席科学家，他的工作专注在创建安全系统的实用性方法上。
Taylor McKinley是Fortify的产品市场经理。