代码审计服务
依据贵司的具体安全规范和要求，对贵公司的重要应用系统代码审计，发现是否存在安全技术漏洞，避免应用程序漏洞被攻击者利用，导致应用系统被入侵，逐步建立持续改进的工作机制。
我们针对甲方提供的系统源代码，进行全量的代码安全审计，从业务逻辑层面、应用实现架构层面进行全面的评估，并通过专业工具及人工干预相结合、分批对核心系统开展代码审计工作，对程序可能存在的后门、陷阱、SQL注入、跨站漏洞、输入输出注入等风险进行有效的封堵，从源头保证应用安全。
（1） 在源代码白盒审计基础上结合使用安全扫描、黑盒渗透测试等手段，发现常规OWASP漏洞如SQL、XSS等，对业务型逻辑性等漏洞进行挖掘，同时对重要系统的架构和系统重要模块如输入输出等进行重点审查，深度对重要系统进行全面的代码审计。
（2） 审计业务系统源代码代码程序中是否被植入的恶意代码、后门程序以及特洛伊程序后门程序、恶意访问数据代码、权限控制缺陷等漏洞，避免系统资源被内部滥用和非授权访问。
（3） 规范代码开发人员（供应商开发人员）的编写规范，提高应用系统开发安全性。
（4） 重点进行业务流程的安全审计，重点审计查找系统在使用中出现的逻辑错误、BUG等问题。
（5） 建立完善源代码安全审计平台，有效控制保护源代码流通范围。
包括网上银行系统：
在本项服务中，我们将结合贵公司的业务安全需求，针对业务应用系统对应用安全功能、数据安全、业务安全和代码漏洞进行安全分析，对应用系统代码进行安全审计，检测相关安全控制缺失。
区别与传统的代码审计方法，我们所提供的代码安全审计结合了白盒与黑盒的方法，对应用程序程序代码进行病毒代码审计、工具审计人工审计和业务逻辑安全的审计，审计内容涵盖应用系统的数据安全、业务功能安全、代码编写安全三个层面，从应用系统的整体角度看代码安全。
代码审计工作方法主要包括以下四方面：
◇应用访谈：主要通过对开发人员的安全访谈，审计应用系统整个安全架构和相应安全防护措施，评估其是否符合国际主流的安全架构设计要求
◇工具审计：主要对和安全相关的几大环节代码进行工具扫描，发现程序代码是否存在病毒、常见安全漏洞等问题。
◇人工审计：人工对关键环节的代码以及进行逐行代码审计，分析程序代码安全性，发现安全漏洞，并对工具审计和应用访谈结果进行核实和验证，保证检查的完整性和真实性
◇模糊测试：通过渗透测试的方法（渗透测试的工作方法及工作内容描述，详见本文第3章节具体内容），以模拟黑客攻击的手段，从外部访问者的角度对应用系统程序代码进行安全漏洞发现和漏洞利用的验证
○针对人工审计，其实施方法通常是由客户提供被审计的程序代码，我们工程师遵循一定的保密原则针对程序代码进行审计，审计完毕提交审计报告，因此这个过程不存在风险。
○针对工具审计，其实施方法是把程序代码导入审计工具中，由工具自动进行漏洞检测，我们工程师将导出检测结果，工具中既不保存检测结果，也不会保存源代码本身，因此客户提交的源代码不会被泄露。
本次代码审计服务的内容从应用系统的整体架构考虑，针对以下10个方面的程序代码安全性进行审计：
Ø 输入验证
Ø 身份验证
Ø 授权及访问控制
Ø 配置管理
Ø 敏感数据
Ø 会话管理
Ø 加密技术
Ø 参数操作
Ø 异常管理
Ø 审核和日志记录
审计应用程序输入是安全的重要环节，也是攻击者执行代码的一种方式。应用程序盲目地信任输入时，应用程序可能会很容易受下列威胁影响，因此是审计重点：
△缓冲区溢出
△跨站点脚本编写
△SQL 注入
△标准化
缓冲区溢出缺陷可以导致拒绝服务攻击或者代码注入。拒绝服务攻击可以引起进程崩溃；代码注入可以更改程序的执行地址，从而运行攻击者的注入代码。
当浏览器和某个可信的 Web 站点连接时，贵S 攻击可以引起任意代码在用户的浏览器中运行。攻击的目标为应用程序的用户而非应用程序本身，但是它以应用程序作为攻击的工具。
由于是从一个可信的站点用浏览器下载了脚本代码，浏览器无从知道这些代码是非法的。Internet Explorer 的安全区不能提供任何防护。由于攻击者的代码可以访问与可信站点相关的 cookie，这些 cookie 存储在用户的本地计算机上。一般情况下，用户的身份验证 cookie 就成为了攻击的目标。
SQL 注入式攻击利用输入验证中的缺陷来运行数据库中的任意命令。当应用程序使用输入来构造访问数据库的动态 SQL 语句时就会发生这种攻击。如果代码使用存储过程，传递给该过程的字符串中包含有未筛选的用户输入时，也会发生这种攻击。利用 SQL 注入攻击，攻击者可以执行数据库中的任意命令。如果应用程序使用一个越权帐户来与数据库连接，问题会更严重。在这种情况下，除了能够检索、操作和破坏数据外，利用数据库服务器来运行操作系统命令是可能的，并有可能危及其他服务器的安全。
将不同形式的输入转化成相同的标准名称（规范名称），这被称为标准化。 如果代码是根据传递给程序的资源名称（它作为输入）来进行安全决策，这样的代码就特别容易受到标准化问题的影响。文件、路径和 URL 都是容易受标准化影响的资源类型，因为每种情况都有许多表示相同名称的不同方法。文件名称也有这样的问题。
主要审计身份验证方面的控制措施。如果选择和实现不正确，身份验证机制就会暴露出缺陷，攻击者利用这些缺陷可以访问系统。主要审计如下方面：
如果将身份验证凭据以明文形式从客户端传递到服务器，在同一网络的某台主机上配备有基本网络监控软件的攻击者可以捕获传递的信息并获取用户的名称和密码。
如果应用系统在认证页面没有采用验证码机制或者没有限制用户登录失败尝试次数，则系统很容易遭受工具暴力破解，如：
■暴力破解密码
暴力破解依靠计算能力来破解散列的密码或者破解其他用散列和加密保护的秘密。为降低风险，可以使用强密码。
■词典破解密码
利用词典攻击，攻击者利用一个程序循环访问字典中的所有的单词（或多种语言的多个字典）并计算每个单词的散列值，将获得的散列值与数据存储区中的值进行比较。脆弱密码，例如“Yankees”（一个喜爱的团队）或者“Mustang”（一辆喜欢的轿车），将会很快被破解。较强的密码，例如“? You'LlNevaFiNdMeyePasSWerd!”，被破解的可能性要小一些。
■利用这类攻击，攻击者可以利用监控软件捕获用户的身份验证cookie，并且将它重放给应用程序以便能够以假身份进行访问。
■防止cookie重放的对策包括：
■当传输身份验证cookie时，使用SSL提供的加密通信通道。
■利用一个cookie超时时间值，强迫在某个相对短的时间间隔后进行身份验证。虽然这种方法不能防止进行重放攻击，但它减小了攻击者重放请求的时间间隔，这期间无需强迫进行再次身份验证，因为会话已经超时。
根据用户的身份和角色成员身份，对特殊的资源或者服务进行授权，要么允许访问，要么拒绝访问。授权层面主要存在的漏洞包括：
■权限过高
■未授权访问
■篡改数据
■引诱攻击
在设计授权模型时，必须要考虑攻击者试图提升特权，以成为一个超级帐户如本地管理员组成员或者本地系统帐户的威胁。这样做，攻击者就完全能够控制应用程序和本地计算机。例如，利用传统的ASP编程，从一个组件调用 RevertToSelf API 可能会造成正在执行的线程以本地系统帐户身份运行，而该本地系统帐户拥有本地计算机的超级特权。
如果未授权用户可以查看敏感数据，就会发生机密数据泄漏的问题。机密数据包括应用程序专用的数据，例如信用卡号、雇员详细资料、财务记录等，还包括应用程序配置数据，例如服务帐户凭据以及数据库连接字符串。为了防止泄漏机密数据，应在网络上传输时对其进行保护，还应在持久性存储区中进行保护（例如数据库和配置文件）。只有经过身份验证和授权的用户才能访问他们专用的数据，应当限制只有管理员才能访问系统级配置数据。
许多应用程序支持配置管理界面和功能，以允许操作者和管理员更改配置参数，更新Web站点的内容，以及进行日常的维护。配置管理层面主要的漏洞包括：
○管理界面缺乏保护
○管理操作缺乏日志记录
应通过另外的Web页或者单独的Web应用程序提供管理界面，它允许管理员、操作者和内容开发人员来管理站点内容和配置。这些管理界面只应当由有限的和授权的用户使用。恶意的用户能够访问配置管理功能可能会破坏Web站点、访问下游系统和数据库，或者通过破坏配置数据而使应用程序出现故障。
防止未授权访问管理界面的对策包括：
■将管理界面的数量减到最少。
■使用强身份验证，例如：使用证书。
■使用带有多个网关守卫的强授权。
■考虑只支持本地管理。如果完全需要远程管理，那么利用加密通道，例如，VPN技术或者SSL，这是由于在管理界面上传递的数据的敏感性所导致的。为了进一步降低风险，还要考虑使用IPSec 策略来限制对 Internet 网络上的计算机进行远程管理。
缺乏对更改配置信息的审核和日志记录就会威胁识别以下情况的能力：什么时候进行的更改以及谁做的更改。当由诚实操作者的错误或者恶意的更改导致出现中断更改，从而允许特权访问时，首先要采取行动纠正这些修改。
金融行业的敏感数据（如用户身份信息、银行帐号信息等）易遭受各种威胁，是攻击者的主要攻击目标。因此应重点审计应用系统程序对敏感数据的处理、存储和传输。
在针对敏感数据的代码审计过程中，将首先对敏感数据相关的系统功能模块进行以下方面的安全分析：
■敏感数据相关功能模块主要处理流程
■相关功能模块在整个业务系统的布局
■相关功能模块代码结构
■敏感数据的数据流走向
■针对敏感数据的访问、存储、处理和传输进行程序代码审计，重点针对以下几方面：
■敏感数据访问的代码是否业务必须（重点关注批量获取数据的代码）
■本地以非数据库形式保存敏感数据的代码
■监听本地端口并提供服务的代码
■向其他服务器发起网络连接并传输敏感数据的代码
■敏感数据在网络传输中是否采取安全保护措施
■ 敏感数据在存储时是否采取加密或编码后存储
■是否存在特洛伊木马等后门程序
■在敏感数据方面可能存在的主要漏洞包括：
■敏感数据存储缺乏保护
■ 敏感数据明文传输
审计程序代码是否保护存储区的敏感数据，以防止恶意的或者其他的用户访问和读取这些数据。
保护存储区的敏感数据的对策包括：
■ 对包含敏感数据的持久性数据存储区使用受限ACL。
■ 存储加密数据。
■ 使用基于身份和角色的授权，确保只有具有适当授权级别的用户才允许访问敏感数据。用基于角色的安全机制来区分用户，谁可以查看数据，谁可以更改数据。
Web应用程序的HTTP数据以明文的形式在网络上传输，并遭受网络窃听攻击，攻击者利用网络监视软件捕获并有可能更改敏感数据。
防止网络窃听并提供私密性的对策包括：
■加密数据
■使用加密通道，例如：SSL
Web应用程序的会话管理是应用程序层的一项职责。会话的安全性对于应用程序的整体安全性非常重要。
会话管理层面的主要弱点包括：
◎认证会话明文传输
◎没有设置会话超时时间
当攻击者利用网络监视软件捕获用来表示用户与应用程序进行会话的身份验证标记（通常是一个cookie）时，就会发生会话劫持攻击。利用捕获的cookie，攻击者可以欺骗用户会话，访问应用程序，攻击者具有和合法用户同级的特权。
防止会话劫持的对策包括：
◇利用SSL创建一条安全的通信通道，并只在HTTPS连接上传输身份验证cookie。
◇实现注销功能，允许用户在启动另一个会话时结束强制身份验证会话。
◇如果不使用SSL，确保要限制会话cookie的有效期。虽然这不能防止会话劫持，但是它减小了攻击者可利用的时间。
没有设置会话超时时间容易遭受会话重放攻击。
当用户的会话标记被攻击者中途截取和提交以绕过身份验证机制时，就会发生会话重放。例如，如果会话标记为cookie或者URL中的明文，攻击者可以探查到它。然后，攻击者利用被劫持的会话标记来发出请求。
大多数应用程序利用加密技术来保护数据，确保它的私密性并不被更改。围绕应用程序使用加密技术的主要漏洞包括：
Ø糟糕的密钥生成或者密钥管理机制
Ø脆弱的或者自定义的加密技术
如果攻击者得到密钥或者可以推导出密钥，他们就可以解密加密的数据。如果不妥善管理密钥或者不以随机的方式产生密钥，攻击者就可以找出密钥。
解决糟糕的密钥生成和密钥管理机制的漏洞的对策包括：
Ø使用内置的加密例程，这种例程包含安全密钥管理。数据保护应用程序编程接口 (DPAPI)就是一个加密服务示例，它由Windows 2000及其以后的操作系统提供，其中操作系统管理密钥。
Ø使用强随机密钥生成函数，并将密钥存储在一个受限制的地方 - 例如，存储在用受限制的ACL保护的注册表密钥中 - 如果使用需要生成或管理密钥的加密机制。
Ø用DPAPI加密密钥，增加安全性。
Ø定期使密钥过期。
如果加密技术被破解或者很容易被强力破解，加密算法就不具有安全性。如果没有经过测试，自定义的算法特别容易受到攻击。相反，要使用公布的、著名的加密算法，它们都经受住了多年的苛刻攻击和审查。
针对脆弱的或者自定义的加密技术容易受到攻击的对策包括：
Ø不开发自己自定义的算法。
Ø使用由平台提供、经受考验的加密服务。
Ø了解被破解的算法和用来破解算法的技术。
操作参数攻击是一种依靠更改在客户端和Web应用程序之间发送的参数数据的攻击。这包括查询字符串、窗体字段、cookie和HTTP标头。主要的操作参数层面漏洞为：
Ø以HTTP HEAD信息作为安全判断依据
用户很容易就可以操作由HTTP HEAD传递的从客户端到服务器的查询字符串值。如果应用程序依靠这些信息来进行安全决策，或者如果该值代表的是诸如资金数量的敏感数据，那么该应用程序就很容易受到攻击。
允许传播给客户端的异常可以泄漏内部实现的详细资料，它对最终用户没有意义，但对攻击者却非常有用。不使用异常处理或者异常处理实现得非常糟糕的应用程序，也会遭受拒绝服务攻击。
主要的异常处理层面漏洞包括：
Ø泄漏系统敏感信息
如果系统出错时向客户端显示详细出错信息，这些资料对于开发人员具有极大价值。如果这同样的信息落到攻击者的手中，它将会大大帮助攻击者利用潜在的缺陷以及规划将来的攻击。可以被返回的信息类型包括平台版本、服务器名称、SQL 命令字符串以及数据库连接字符串。
应当使用审核和日志记录来帮助发现可疑的活动，例如足迹或者真正攻击之前的可能破解密码企图。它还有助于处理否认威胁。如果多个服务器上的一系列同步日志条目表明用户执行过某项交易，那么用户就很难否认执行过这项操作。与审核和日志记录有关的主要漏洞包括：日志记录不完整。
Ø日志记录不完整
如果系统记录的日志不完整，会存在否认威胁。
否认问题就是用户否认他或她执行过某个操作或者发起过某项交易。需要适当的防护机制来确保可以追踪和记录所有的用户活动。
由于目前重要系统围内的系统多数为第三方厂商开发，代码中是否包含恶意代码是本次审计的重点，主要目的是发现应用程序在授权等关键业务逻辑安全控制方面的缺陷。
恶意代码的审计范围主要包括应用程序在授权、访问控制等关键业务逻辑安全控制方面的代码。
恶意代码的审计内容主要包括但以下两个方面：
■后门、恶意代码审计
Ø 大批量获取数据库表数据（尤其是存有重要数据的数据库表）的代码
Ø 监听本地端口并提供服务的代码
Ø 向其他服务器发起网络连接并传输数据的代码
■授权及访问控制恶意代码
Ø 检查低权限用户是否可以访问高权限用户的页面或功能
Ø 检查重要业务功能中是否缺乏安全保护
通过人工和工具审计相结合的方式，对静态页面进行安全审计。
■审计文件类型
静态页面安全审计主要审计htm、html、js、css格式的HTML文件。
■安全审计内容
安全审计可以发现以下安全问题：
Ø 是否存在嵌入调用外部站点恶意script脚本的代码
Ø 是否存在利用window.location方法，使浏览器跳转到恶意外部站点页面的代码
Ø 是否存在利用Meta标记，使浏览器跳转到恶意外部站点页面的代码
Ø 是否存在利用iframe标记嵌入恶意外部站点页面
Ø 是否存在利用frameset框架，使浏览器打开恶意外部站点页面的代码
Ø 是否存在利用location.replace方法，使浏览器跳转到恶意外部站点页面的代码
Ø 是否存在利用样式表的URL方法，使浏览器调用恶意外部站点页面的代码
Ø 是否存在利用样式表的expression方法，使浏览器执行恶意脚本的代码
Ø 是否存在利用表单(FORM)的action方法，使浏览器跳转到恶意外部站点页面的代码
Ø 是否存在利用window.open方法，使浏览器浏览器弹出窗口访问到恶意外部站点页面的代码
Ø 是否存在利用body标记的onload和onunload方法，使浏览器载入页面时或离开页面时弹出窗口访问恶意外部站点页面的代码
Ø 是否存在恶意调用系统功能的Script脚本
Ø 是否存在利用<link>标记，调用恶意外部站点页面的代码
Ø 是否存在利用<object>或<embed>标记恶意调用系统功能的代码
Ø 是否存在执行恶意script脚本的样式表代码
Ø 是否存在调用恶意外部页面的样式表代码
Ø 页面中的所有外部链接是否包含恶意站点地址
在实际环境中，来自源代码方面的问题并不是产生安全风险的唯一途径。要全面保证应用的安全，不仅要对源代码自身进行安全审计，还需要保证应用配置的安全性、源代码所引用的第三方组件、程序的安全性等。
主要包括应用的配置文件、第三方组件以及应用平台环境等。
■应用配置文件
■第三方组件安全
■应用平台配置
应用的配置文件中通常会定义应用的相关环境信息，如：数据库连接、配置存储是否安全、是否使用最少特权进程和服务帐户、管理界面是否安全、是否单独分配管理特权等。如果配置文件安全性存在漏洞将导致这些信息的泄露，为应用的相关服务带来安全威胁，建议采用以下措施进行保护：
Ø 通过加密确保应用配置安全，然后限制包含加密配置数据的注册表项、文件或表的访问权限；
Ø 确保为这些帐户设置最少特权；
Ø 配置管理功能只能由经过授权的操作员和管理员访问，在管理界面上实施强身份验证；
Ø 用基于角色的授权策略分别为每个角色授权
应用在开发过程中或多或少会引用一些第三方的组件、框架等来简化开发过程。这些内容的安全问题同样会给应用的安全造成威胁，如近期的Struts 2远程代码执行漏洞就是Struts2框架存在漏洞未及时修补，主要检查以下相关内容：
Ø 查看各检查系统是否使用Struts2框架；
Ø 使用K8_Struts2_EXP工具进行检查、验证；
所有的应用平台都会基于一种应用平台来发布，如流行的Apache Tomcat、Weblogic等。如果应用服务器程序的配置不当或者其存在的安全性问题，很有可能给应用的安全带来很大的威胁。另外，应用访问日志记录也是重点关注的项目，如果未配置或配置不当，都会影响安全事件的事后取证和追查等工作。
针对以上平台，不同的版本，有不同的漏洞利用方法，以上应用平台容易产生以下漏洞：
●不安全的HTTP方法：
以上平台均可能存在，但IIS、Apache经常出现此类问题。当web目录权限配置不严格时，可能导致使用不安全的HTTP方法写入、删除或是更改文件，可能导致直接向web目录植入web页面或是木马。
●源代码泄露：
以上平台均可能存在，在Tomcat中很容易出现。由于版本过低或是补丁更新不及时，导致提交特殊请求，服务器会直接返回页面源代码。如Windows下Tomcat对大小写扩展名处理导致源代码泄露，IIS对空格处理导致源代码泄露等，利用得到的源代码，能进一步分析应用程序的结构。例如提交：http://aa.com/aa.jSP可能造成源代码泄露。
●错误处理：
以上平台均可能存在，web服务器未配置自定义错误页面，当应用程序运行出错的时候，可能会向用户返回详细的错误信息，可能会包含路径信息、数据库信息等。
●缓冲区溢出：
以上平台均可能存在，由于版本过低或是补丁更新不及时，导致缓冲区溢出漏洞，轻则造成DOS攻击，重则取得应用平台运行权限。
●关键传输未加密：
以上平台均可能存在，敏感页面的数据传输未加密，例如登录页面，使用sniff则可能嗅探到网络中传输的明文信息，渗透测试中不会利用此漏洞进行攻击测试。
●目录遍历：
以上平台均可能存在，但是IIS、Apache、tomcat、Weblogic中出现非常频繁，是因为web软件配置不正确导致，利用此漏洞可以完整的看到web目录结构，结合其它攻击，能给应用系统带来新的威胁。
以下是代码审计工作的总体工作流程：
■我们职责
1．提交《代码审计方案》，方案中包括：代码审计范围，审计方式、方法，实施步骤，风险规避等。
2．提交《审计数据提交申请》，该表中包括代码审计相关说明，扫描时间，执行人，客户协调人，需要客户提供的相关资源：
3．和客户维护人员讨论，并修订《代码审计方案》和《审计数据提交申请》
■贵公司配合。
客户相关维护人员参与《代码审计方案》的讨论和确定，并准备代码审计申请表中涉及的相关代码资源。
■我们职责
1.制定访谈接话，提交访谈内容列表
2.对开发人员、业务系统负责人进行访谈，了解应用系统整个安全架构
3.对贵公司业务系统相运维负责人进行访谈，了解当前应用系统的安全防护措施
4.整理访谈结果，评估应用系统架构是否符合国际主流的安全架构设计要求
■贵公司配合
协调相应人员，接受访谈，并对访谈结果进行确认。
■我们职责
使用专门工具和病毒检测工具扫描应用程序。
■贵公司配合
客户指派一名工程师配合我们工程师的工具扫描，监视被扫描应用系统状态。
■我们职责
针对扫描的结果进行人工检查核对，对扫描出的漏洞进行手工检查，确认其真实性。同时对本项工作涉及的相关内容进行人工审计。
■贵公司配合
客户相关人员提供我们工程师需要审计的应用代码
针对所审计的应用系统进行渗透测试工作。操作步骤与渗透测试服务相同。
■贵公司配合
1.填写并签字确认《渗透测试申请表》
2.提供被测试的内外网应用系统访问地址。如：URL
3.确认测试时间
4.提前通知相关系统运维人员测试时间和注意事项
■我们职责
1．整理代码审计结果，形成评估中间报告，描述本次代码审计发现漏洞情况，并提出改进建议。
2．向客户汇报代码审计的结果和相关改进建议
■贵公司配合
相关人员配合我们工程师就代码审计发现问题的沟通
我们将通过对源代码进行复查，同时采用渗透测试方法对修改后的代码进行验证，确保代码复查的准确。
根据代码审计结果，提供相应的安全技术培训，对软件开发人员、系统应用程序维护人员进行技术建议，协助贵公司完善应用系统开发方面的代码编写、应用开发管理方面的安全规范。
代码审计方面的技术培训内容主要包括：
■应用系统安全攻防的基本概念
■OWASP十大类web应用安全威胁介绍及对应的代码安全编写规范应用开发安全管理的安全意识