写一个安全的应用程序
写一个安全的应用程序
Foundstone亚太总监 陈彦铭 2004/02/16
上周提到应用程序在设计阶段时，就可能因为疏忽于考虑许多安全因素，而埋下其后的开发生命流程中的安全炸弹。如果等到测试阶段时才发现问题，不只得花上数倍的时间与资源进行修补，往往也会是治标不治本。换言之，在不舍弃原有投资的情况下，几乎是不可能改变原先设计以解决根本的安全问题。
从此之后，这个应用程序将处于挨打的阶段，等待着一个个的安全问题相继发现，再一个个进行解决，而修修补补所要的资源可能远超过当初投入开发所使用的资源。本篇文章将提出在实行阶段(Implementation) 时所可能发生问题与相对的解决方式。
在实行阶段，必须考虑的是如何撰写出安全的应用程序。我们先忽略设计阶段因为忘了将安全考虑导入应用程序设计中所出现问题，暂时专注在论述程序设计与实行的安全问题。
在这阶段内，容易出现的问题有两大类：第一类是程序错误 (Code defect)；第二类是逻辑错误 (Logic error)。前者可利用不同的自动化工具，侦查错误之处且加以解决，但若是发生第二种错误，就很难透过自动化工具来除错。
程序错误
常见的程序错误 (Code defect) 有几种。第一种是使用不安全的函数呼叫，例如，在 C 里面使用 strcpy 呼叫时，如果没有注意相关的数据检查，就很容易造成缓冲区溢位的漏洞。正也因此，易于衍生第二种程序错误－「数据有效性检查」。
大部分的 Web 应用程序都接受使用者输入数据，而大部分的程序也都相信使用者输入的数据且直接使用。如果程序在接收数据输入时，设有检查数据长度等关卡，就能避免前述的缓冲区溢位漏洞。另外，还有一些常见的程序错误也是安全症结，例如，没有处理程序执行时发生的意外情况 (Exception Handling)。
逻辑错误
每一个应用程序设计时，都会依照一定的商业逻辑考虑，而程序设计与实作只不过是将那些考虑中的商业逻辑与要求，进一步转化成为计算机语言。当程序设计师对于将商业逻辑转化为程序逻辑的认知不同时，就可能产生一些逻辑上的程序错误。有时候，这些错误也可能是程序设计师的疏忽。
去年微软 Passport 惊爆的安全漏洞就是这类的逻辑错误。在使用者重设密码的步骤中¬，原本是有一系列步骤要完成，每一步都依赖上一步的结果来进行，以保持程序执行时的状态 (State)。可能是在程序更新版本中出错，或者是其它的开发过程发生问题，导致原来设计的逻辑未能保持，任何人都可直接忽略前面的三个步骤，而直接跳到最后一步去重设任意一个账号的密码。
其它类似的问题还有很多，早期微软 IIS 上的 Unicode 与 superfluous decode 漏洞也是相似的情况。此外，逻辑错误也可能是存有恶意的。例如，在线银行程序开发设计人员在在线银行里预先埋设后门程序，等待离职之后便能利用「后门」从事不法勾当。
实际上，在整个软件开发的生命流程中，写一个应用程序时所出现安全问题数目，向来高于其它阶段。我们先前曾简单描述了几种常见的错误，接下来就要看看如何弥补，若还是来不及更改现有的软件开发生命流程，注重程序设计安全与加强事后检测，就成了亡羊补牢犹未晚矣的作法。
解决方案
要增进软件开发在程序实作阶段的安全性，教育程序开发人员开发安全应用程序的重要性，以及如何正确地写出安全的程序是治本之道。其它的辅助措施包括提供程序撰写指南与一般化的安全模块，例如，数据验证接口 (Input Validation API)，同时强化安全测试与检查原始程序代码等步骤。
在程序开发人员的教育方面，传授开发技术之外，也需让程序开发人员了解开发安全程序的必要性。另外，针对项目管理人员也必须教育他们，如何能追踪且控制整个应用程序开发流程中的各项安全问题。 提供程序撰写指南 (Guideline) 是让程序开发人员依一定的规则开发程序，并且增加应用程序的可维护度，同时降低隐藏的安全危机。在此原则下，也容易让接受的人检查软件是否符合一定的要求。
对于大型企业来说，提供一般化的安全模块更为重要。一些安全方面的模块可以由一组人员开发维护再交付给予其它的研发团队使用，如此，不只能提高可维护性，也能避免程序开发人员自以为是的天马行空，其背后所可能产生的安全问题。
从以往企业多依赖内部聘雇人员开发所需的应用软件，发展至今日越来越多的公司选择将软件开发业务委外，在这样的改变下，若要妥善控制软件质量本来就相当困难，现在又要考虑避免与管控软件的安全问题，如果不自根本的开发生命流程下手，可能还是会停留「找洞补洞」而疲于奔命的情况。�*埽颐墙徊教致鄄馐杂τ贸绦虬踩潭鹊姆椒ǎ峁└魑欢琳卟慰肌�
搜索更多相关主题的帖子:
应用程序
