Web代码安全人工审计内容的研究

何斌颖，杨林海

(云南工商学院，651700，昆明)

Web代码安全人工审计内容的研究

何斌颖，杨林海

(云南工商学院，651700，昆明)

Web系统的大量应用，各种安全事故频发，除了操作系统的安全漏洞以外，web系统的代码在编制的时候，不良的编码习惯、对操作过程中在代码中显露出安全重视不够等因素，导致系统在生产线中存在或大或小的隐患。web系统上线之前，系统一般会进行白盒、黑盒测试，但是并不能保障足够的安全,还应对代码和运行环境等进行详细的人工审计，可以大大减少安全事故。

代码审计；白盒；黑盒；安全漏洞；安全渗透

0 引言

LxLabs公司开发的HyperVM在2009年被黑客发现有严重的漏洞，造成10余万站点的数据被黑客删除，造成了用户巨大的损失，诸如此类安全事故频见于各大新闻媒体或行业通告。从技术角度来说对软件造成威胁的本质其实就是软件在设计和编码时存在安全漏洞，一旦漏洞被怀有恶意的黑客发现并利用即可对系统造成严重的威胁，给服务提供商和用户造成巨大的经济损失。因此从软件需求分析、设计、编码一直到运行维护的几个阶段，完全有必要对软件代码进行安全审计，以降低软件的脆弱性。代码审计主要有2种方法：借助一些工具软件来查找问题，另外一种方法是利用人工审核主要是弥补工具软件的不足之处。

1 研究背景

Web网站在投入使用后，可能会出现操作系统漏洞、SQL注入、跨站脚本、未验证的重定向和数据传递等安全问题，安全问题一旦出现，轻者系统需要重新安装，重者数据没有备份时会造成很严重的损失。通常做的首先是对操作系统和web系统进行常规的更新，修改web系统的明显bug，在操作系统中安装软件防火墙，在网络中部署硬件防火墙或者其他类型的安全设备等，但是这些行为都属于事后弥补。而作为一个安全性足够高的web应用系统，应该将安全漏洞隐患扼杀在萌芽中，在投入使用前应该对web软件进行白盒源代码脆弱性和缺陷检查，或黑盒渗透测试，或者两者同时都进行，但这2种测试并不能完全保证软件的安全性。

本文提出对web软件代码应进行上线前安全审计，这种代码审计是从业务的角度对威胁进行分析，检查关键环节是否对业务进行了安全控制，当然此阶段需要根据企业提供的测试环境以及前期的设计文档，再结合业务数据流进行完整性研究、整理和分析。

代码审计是一种高效的检测安全漏洞的技术，分为人工和软件工具自动审计，能够对发现的安全漏洞进行验证，常见的审计工具软件有Fortify SCA、OWASP、FindBugs、PREFast、FxCop、PHPSAT等。本文主要探讨人工审计的内容和方法。

有经验的开发人员详细分析并阅读应用系统的相关文档和源程序，对程序中存在的不良编码习惯、不合理逻辑关系和安全漏洞进行审阅，找出应用系统可能存在的安全隐患，综合给出代码修改意见和评估报告，达到提高应用系统的安全性的作用。代码审计是软件安全生命开发周期(SDL)中组成安全应用非常重要的一环，在代码开发过程中即进行代码审计，能够帮助开发人员养成良好的开发习惯，减少因开发人员不良习惯导致的安全问题，有效的提高软件的安全性[1]。涉及到以下威胁分类：业务连续安全(图形验证码等)，业务逻辑安全(认证和授权等)，业务数据安全(文件上传和下载防护)和业务安全管理(日志记录等)。以下对威胁分类分别讲述人工审计代码的内容。

2 人工代码审计内容

2.1认证管理

在web代码中应检测是否包含有用户登录过程应该有图形类型的验证码，预防黑客编写程序暴力破解密码。验证码在编写上应将复杂度考虑进去，在页面显示时应加入干扰因素：如验证码有变形和底版等。验证码在用户使用过一次后应自动刷新，不能以明文方式传送给客户端，以防有cookie等进行记录。在用户对重要的操作，如修改密码等行为时，也应有验证码的有效验证。

Web页面的用户登录认证过程中，在审计代码时，较安全的编写顺序应是先校验验证码，然后检查用户名，最后比对密码的密文。用户登录提交应只有一次，在重定向时不可以将密码再次传送，以防会出现明文密码的情况。对用户名和密码进行验证时，如果出现错误的用户名或者密码，登录提示时代码应显示出相同的错误信息，如“用户名或密码错！”，代码不应单独对错误的密码或用户提示“用户名错！”或者“密码错！”，以增加用户名和密码被破解的难度，降低风险。用户登录如出现几次认证失败，在代码中应设置时间限制，如认证失败超过3次，锁定几分钟甚至一天以后才能再次进行认证登录，增加猜测密码和用户名的时间成本。用户登录后如果要退出应有注销功能的代码，清理当前用户的会话记录。

2.2授权管理

对于web系统操作和使用的用户，在代码中应明确角色的权限，授权访问的范围，尽可能详尽地分析有可能导致越权的情况。角色一般有系统管理员、管理员、普通用户和审计员(也可细分成系统审计和业务审计员)等，系统管理员应只负责对系统的维护，不能对业务数据进行操作，管理员则在系统管理员定制的权限范围内对系统数据进行操作，普通用户则只能进行有限的界面访问，以及自己权限范围内的数据修改，审计员则应定期审计各级别用户的权限和操作过的记录等。

如果是大型应用软件，应设计有统一的最好是独立的权限控制模块，并审核权限控制模块是否存在漏洞，在页面及功能设置上应体现出权限控制模块的作用。对页面权限的控制应精准，对需要和不需要控制的页面及功能进行验证，验证过程中应区别出用户的角色。

2.3输入和输出验证

对数据库的操作应设计有全局过滤器，有相应的过滤函数，过滤器应过滤所有的查询请求，对数据依据PHPIDS的规则库进行初期检查。对数据应使用预查询机制，在传入SQL语句前应明确指定传输数据的类型以执行必要的转换。对于一些复杂的组合查询，未预防可能导致的注入，应检查拼接是否存在缺陷。

预防跨站攻击，web网站的代码应有全局跨站脚本(XSS)过滤器，过滤器应符合要求，需考虑需要过滤和不需要过滤的2种输出。预防跨站请求伪造(CSRF)攻击,应使用Token或验证码加强安全性，在web表单提交成功或者是被以后token或验证码应该重置[2]。使用Token应验证其生成算法的安全性，如果是验证码则检查生成的验证码是否符合复杂性要求，如是否有干扰线或干扰点，有字符变形等。

对于服务器获取web表单数值时，如果操作代码不严格区分GET和POST的功能区别，在没有Token或验证码的辅助功能下很容易导致跨站请求伪造攻击。

Web网站一般提供文件的上传和下载，包括管理员对网站的维护也需要上传或者下载文件，在文件上传操作代码中应限制用户所传文件的扩展名，某些扩展名的文件名应禁止上传，如“.exe”文件。审计代码时查看扩展名是否是以黑白名单的方式列出，列在黑名单的扩展名是禁止上传的，白名单中的扩展名则可以上传，这样编制代码的另外一个好处是管理员可以及时调整黑白名单中的扩展名。对于上传的文件最后限制重命名的操作，防范重命名过程中会产生不可预知的风险。另外在代码中应禁止对上传文件的存放位置实现脚本执行功能。

对于web提供的文件下载中，应审计客户端是否可以指定文件名进行下载，如果存在安全隐患则应关闭此功能，如果客户端可以指定文件名进行下载，则不允许客户端指定路径。用户下载时应对不同级别的用户设置不同的权限控制，并在下载功能中对权限进行检查。对于客户端访问链接时应对客户端的重定向或转发请求进行检查，定义重定向的信任域名或主机列表。

2.4会话管理

当用户访问web页面时，应禁止session信息显示在URL里。在执行业务时，应对当前操作的用户检查session身份。成功登陆之后应强制更新SessionID，并对Session的时效性进行约定，如约定15 min或者0.5 h等。

应加强对cookie的管理，不能在cookie中存储明文或简单加密过的密码，消除存储的应用特权标识，设置cookie的有效域和有效路径，设置合适的cookie有效时间，如果生存时间为20-30 min，则建议使用session方式。

2.5密码管理

对于用户、管理员等的密码应使用哈希算法进行存储，为防止暴力破解密码，对密码进行哈希算法后还可以使用加盐(Salt)的方式来增强安全性。可以采用哈希算法或者RSA等加密算法将密码加密后传递，或者是使用SSL来做传输层加密。

用户或管理员等对密码进行修改时应进行旧密码验证或者有安全问题确认过程，如果在设置密码时保留有电子邮件、手机号码等信息时，应具备找回密码的功能。检查密码设置页面应该对密码复杂度进行检查，至少包含大、小写字母、数字中的2种，长度最少6位，避免用户输入弱口令。

2.6调试和接口

在web代码中，当应用出现错误的时候，应阻止输出给客户端，否则详细的错误输出可能会导致SQL查询泄露、程序源代码泄露、物理路径泄露等。对代码中的异常处理应能够全面覆盖所有异常行为，检查异常处理是否会导致程序流程异常，引发安全问题，如果异常情况处理不好，特定程序捕获了异常，可能会导致程序绕过一些重要的步骤而直接执行后续的操作。

在审计数据接口时，检查是否存在安全漏洞。接口服务后台登录是否存在弱密码，接口服务最好没有默认的测试页面，否则会暴露物理路径。接口服务应用是否包含身份认证，认证的帐号、密码(或密钥)的存储是否足够安全。接口服务应用传输应加密。

接口服务应用异常处理，如对特殊字符的处理，是否会在报错信息中泄露数据。代码中是否存在内置的敏感信息，如：调试帐号、外部接口帐号/密码、数据加/解密密钥等。

2.6.1 日志审计 审计对应用操作的代码时是否会将用户密码记入日志，以防密码泄露。日志记录的内容是否合理，避免日志文件增长过快，造成磁盘空间不足。

2.6.2 运行环境 对系统运行的环境进行审计时，删除不必要的网页、帐号及权限。页面包括应用服务器的默认页面、管理后台、测试页面、备份文件等；帐号指Web应用服务器的运行帐户。禁用目录浏览功能，Web容器默认帐户的密码是否更改或禁用，不能删除的管理后台是否启用了密码保护，正式发布的应用是否包含开发调试文件、代码，重要的配置信息是否进行了加密，如数据库连接配置、其它接口连接配置等。

审计是否自定义了403、404、500错误页面，错误页面是否会输出详细错误信息，服务器是否开启了用户访问日志的记录，记录的日志是否满足问题回溯的要求，是否记录了客户端地址、请求的方法、请求的URL、提交的参数(GET、POST、COOKIE参数)、请求的状态等。

2.6.3 第3方组件 分析应用使用的框架及引用的第3方组件，分析其是否存在各种已知漏洞，且当前环境漏洞是否可以重现。

2.6.4 安全功能 对于比较重要的业务系统如支付系统等，应对登录认证及数据操作进行审计。重要系统是否使用了双因素登录认证，例如数字证书、支付盾、密保卡等，防止用户密码泄露导致系统被非法登录，对用户提交的关键数据进行加密。

重要系统的后台管理界面是否限制了访问源地址，系统的密码重置短信发送等功能的使用频率是否进行了限制，例如：一个手机号一分钟只能发送一条短信，防止被恶意利用多次发送短信，用户登录时的用户名、状态、源地址等关键信息需要记录到应用日志中，管理员可以进行查询。如果用户在不常用的地址登录，系统会提示用户，并显示上一次登录的源地址，对于多次密码错误的登录尝试，系统能否检测，禁止源地址访问30 min，管理员登录后可以看到，也可以进行查询。

系统中大数据量查询等影响系统负载的功能是否进行了查询范围限制，例如：只能查询最近3个月的数据，系统中大数据量查询等影响系统负载的功能是否进行了查询频率限制，例如一分钟内只能查询一次。高可用性要求的系统中是否有用户请求频率检测，超过访问阈值时，需要用户输入页面上的图形验证码，才能进一步操作。

对报表查询等涉及大量数据的读取和导出操作，是否严格限制了查询范围，必要时可以使用双用户认证，限制单个用户大量读取业务数据的能力。

业务关键数据的读取页面，是否使用静态密码、手机动态密码等二次验证，防止敏感数据泄露，例如：交易详单的查询。业务处理过程中用户身份等关键识别信息，是否保存在服务端，禁止从客户端提交。

业务处理过程中的关键操作需要用户确认和图形验证码，手机动态验证码等保护，防止重复攻击，例如：转账操作等。关键业务操作需要记录到应用日志中，可以设置阈值，超过一定数值系统会告警，管理员可以进行查询。例如：转账金额大于20万的交易记录。涉及资金的业务用户可以设置上限，例如：用户可以设置每日最高消费限额，及转账限额。关键业务操作可以设置短信提醒，例如：用户进行资金转账，进行详单查询等。

3 结束语

本文主要是针对web系统代码的人工审计内容，对审计员要求很强的综合素质，能对代码的良好风格提出一定的建设性意见，也能对已存漏洞或可能导致安全事故的漏洞有解决的能力及预知性。代码审计带来的收益也是非常明显的，通过审计能发现漏洞及时修复，能提前预防。

[1]济南时代确信信息安全测评.源代码安全审计[EB/OL](2012-06-20)[2014-6-22].http://www.cstc.org.cn/templet/default/ show_zyfw.jspid=1294.

[2]yiyaoyuan.跨站请求伪造-CSRF防护方法[EB/OL](2013-01-24)[2014-6-22].http://www.docin.com/p-589312893.html.

AStudyofWebArtificialCodeSecurityAudit

HE Binying,YANG Linhai

(Yunnan Technology and Business University,651700,Kunming,PRC)

Web system are commonly applicated in many enterprises, frequent accidents of all kinds of security are occured,in addition to the security bugs of the operating system,during programming,poor coding practices,exhibited in the operation code factors such as insufficient attention to safety,causing the system to present on the production line or greater or lesser risk.Generally web system should make the white box and black box testing, but does not guarantee adequate security.This article before the detailed manual audit code and runtime environment,can significantly reduce safty problem.

code audit;white box;black box;bugs;security penetration

2014-06-22;

2014-07-16

何斌颖(1974-),女，湖南人，本科，主要从事计算机网络及安全方面的研究。

10.13990/j.issn1001-3679.2014.04.027

TP393

A

1001-3679(2014)04-0536-04