Code Review Engine Learning

相关学习资料

https://www.owasp.org/index.php/Code_review
https://www.owasp.org/images/8/8e/OWASP_Code_Review_Guide-V1_1.doc
http://cwe.mitre.org/about/index.html

 

目录

1. INTRODUCTION: 代码审计介绍
2. PREPARATION: 代码审计须要的准备
3. SECURITY CODE REVIEW IN THE SDLC: 系统生命周期中的代码安全审计
4. SECURITY CODE REVIEW COVERAGE: 代码安全审计范围
5. CODE REVIEW METRICS: 代码审计指标
6. CRAWLING CODE: 漏洞挖掘技巧

 

1. INTRODUCTION: 代码审计介绍

咱们知道，在Risk Threat Modeling(风险模型)中，攻击者经过开源代码或者逆向工程得到目标系统的源代码，从而发现系统潜在的漏洞利用方式是一个高危且常见的风险点，尤为在一些CMS的WEB漏洞中极为常见。所以，在整个IT系统的开发和维护周期中进行code review(代码审计)就成了一个重要且有意义的工做。
代码审计或许是一个最有效的发现安全漏洞的技术了。当配合上自动化的工具以及手工的渗透测试的时候，代码审计能显著提升一个应用系统的安全测评工做的成本不能效益。
手工的代码安全审计工做能使咱们探寻到那些真正的漏洞风险，安全人员在进行代码审计的时候，能够切实的了解到目标系统的上下文环境，并根据漏洞状况评估被攻击的可能性(发现难度、可重现性、依赖条件)、以及攻击一旦发生对商业带来的破坏影响。

0x1: 为何代码存在漏洞
MITRE在它的CWE(Commom Weakness Enumeration)项目中对700多种不一样的软件漏洞进行了分类

http://cwe.mitre.org/about/index.html

从编程开发的角度来讲，有很是多的方式会致使不安全的漏洞发生，其中有些是风险性很好的Bug类型的漏洞，而有些则是具备很大危害性的致命性漏洞。
而对于大多数开发者来讲，它们当中不少人在学校、或者工做中并无接收过关于安全方面的培训(固然这个状况正在快速改善)。
随着信息化的极速发展，愈来愈多的新业务、新技术、新系统被开发出来，它们具有愈来愈多的功能，而且互联程度、依赖耦合也愈来愈高，可是，相应的安全技术以及针对这些新技术、新系统的安全审计工做却没有跟上步伐。
形成这一现象的缘由有不少，而其中最重要的一点就是软件的高度封装性，即只向用户呈现一个提供功能的黑盒子。从用户的角度来讲，用户很难从外表对这个软件的安全性作出准确判断。显性安全的问题直接致使了软件开发商不肯意投入过多的资金到安全审计中去，但这一状况在近几年正在获得不断改善，最大的变化就是:

1) 像乌云、XSRC这样的漏洞披露平台的出现，让更多的用户了解到了安全漏洞的危害，同时也吸引了更多的安全工做着进入这个领域
2) 媒体对安全事件的危机宣传提升了公民的安全意识
3) 不管是普通用户、仍是软件开发团队，对安全开发流程SDL的重视程度都愈来愈高

0x2: 什么是代码安全审计
代码审计就是经过阅读审计目标系统的源代码，检验是否在关键的逻辑流位置设置了正确的安全控制。
代码审计的目的是保证开发人员遵循了安全的开发技术。通常来讲，对目标系统进行了一次完整的代码安全审计以后，模拟渗透测试就不该该发现任何额外的应用程序代码漏洞。
安全研究员每每采用手工(直接阅读源代码)和自动化技术(静态、动态代码分析工具)进行代码安全审计，诚然，自动化的工具可以节省大量的时间，能够在短期内扫描大量的源代码，并按照设定的策略指出"可能"存在风险的代码位置。可是自动化工具不能理解上下文语境关系(代码层的漏洞和上下文的语境关系很密切)，在工具扫描结束以后，须要安全人员逐一确认工具指出的漏洞风险点，若是某个风险点通过验证是真实漏洞，安全人员还须要评估这个风险的风险系数。

 

2. PREPARATION: 代码审计须要的准备

0x1: LAYING THE GROUND WORK: 基础铺垫工做
做为代码审计团队人员，除了技术性的漏洞以外，应该更多地去关注应用系统的商业目的和主要的商业风险，这能帮助审计人员在识别不一样的漏洞代理、它们的动机(攻击者的动机)、漏洞爆发可能(发现率)时能更好的作出判断，并作出正确的优先级排序，优先解决高技术风险、高商业风险的漏洞。
做为风险模型中的一个重要的环节，代码安全审计的结果能够被汇编起来，成为风险模型的一环，详细的展现出当前应用系统的细节安全问题。而咱们知道，风险模型是一个迭代改进的过程，代码审计的最终目的也在若是，经过不断地确保目前的最高危漏洞已经获得正确的控制、修复，让应用系统以螺旋上升的方式不断获得改进。
在SDL的范畴中，代码安全审计人员应该在应用系统的架构设计阶段就参与到开发团队中。对于代码安全审计人员来讲，要将本身当成是一个建议者，和开发人员一块儿去改进代码，完善系统，而不要本着一个警察的态度去纠错，那么会拔苗助长。
0x2: BEFORE WE START: 代码审计须要的基础知识
做为代码审计人员，须要熟悉如下内容

1. Code: 代码
审计人员须要熟悉目标系统所使用的开发语言、这个语言的特性、以及这个语言自己存在的漏洞。从安全的角度来看，不一样的语言(例如PHP、ASP、Java)自己的一些特性和漏洞每每也会反映在代
码漏洞上(虽然代码漏洞大多数时候是程序没有遵循安全编码规范致使的逻辑漏洞)
2. Context: 环境背景
在进行代码审计以前，了解目标应用系统的环境背景十分重要，咱们须要了解:
    1) 咱们正在操做什么类型的数据，即系统的输入、输出问题。咱们知道，很不少漏洞和数据流的流动以及安全处理有关，因此，了解目标应用系统的数据流结构很重要
    2) 当发生数据泄漏时对公司的损失有多大
3. Audience: 目标用户
了解当前审计的应用系统的目标用户是谁:
    1) 相对可信任的企业内网用户
    2) 面向公网的普通用户
    3) 外部系统、外部服务
4. Importance: 稳定性
可用性对应用系统来讲也是十分重要的，安全审计人员须要了解若是目标系统忽然重启、停机会对企业形成多大的危害。咱们知道，无论是"云机房建设标准"中对机房的服务器每一年容许的"中止服
务时间"做出最大上限的规定，仍是"SLA(Service Level Aggrement)"中对用户承诺的服务质量，应用系统保持稳定运行，并不受DDOS攻击的影响都是十分重要的

0x3: DISCOVERY: GATHERING THE INFORMATION: 信息收集
在开始审计攻击以前，对目前信息系统进行一些必要的信息收集对审计工做的有效开展十分有意义，通常来讲，信息收集的手段有:

1) 查看项目的设计文档
2) 和项目开发人员、首席架构师进行交谈，了解应用系统的架构信息
3) 亲身体验一下系统的UI、功能，获取一个直观的认识
4) 了解目标系统的代码结构、所使用的开源库等等

0x4: CONTEXT, CONTEXT, CONTEXT: 明确你的目的
做为安全研究员，咱们要明白安全代码审计并不只仅是在使用工具或者人工对源代码进行审计(阅读)。代码审计的目的是保证代码对应用系统的机密信息和企业财产进行了合理的保护。
对于一个应用系统来讲，可能会存在不少的实际漏洞(可被攻击)、和潜在的漏洞风险。

1) 对于实际存在的漏洞，毫无疑问是应该当即采起措施进行修补
2) 而对于潜在的漏洞风险，则应该根据企业自身的环境、商业目标来对风险进行评估，优先将资源、时间投入到那些相对高风险的漏洞修补中，以实现效益最大化

伴随着代码安全审计的开展，一个高层次的风险威胁模型应该被创建，它包括

1) Threat Agents: 威胁代理
2) Attack Surface: 受攻击面，即黑客能够从哪些角度对系统进行攻击
    2.1) public interfaces
    2.2) backend interfaces
3) Possible Attacks: 可能的攻击方式
4) Required Security Controls: 须要采起的安全控制机制
    4.1) stop likely attacks: 组织可能发生的攻击
    4.2) meet corporate policy: 知足企业、国家标准对系统安全的准入准则
5) Potential Technical Impacts: 发生攻击后对企业产生的潜在的技术影响
6) Important Business Impacts: 发生攻击后对企业产生的潜在的商业影响

在进行上下文环境信息收集的时候，安全人员能够简单地询问开发团队如下问题

1. 信息系统包含了什么类型的数据/资产
2. 敏感数据是怎么进入信息系统并被保存的
3. 信息系统是对内使用的仍是对外使用的，用户的可信度有多高
4. 信息系统被部署的主机处于企业网络架构中的什么位置
处于安全考虑，对于未经验证的用户不容许经过DMZ区域(每每是WEB服务区)进而访问到LAN区域(后端数据库)。即便是对于内部用户，也须要经过验证，没有验证也就意味着不可问责，致使失去
追溯审计能力。 

0x5: THE CHECKLIST: 检查清单
检查清单(check list)规定的是代码审计团队的审计目标，检查清单的完善性、以及是否覆盖了当前系统中的主要安全漏洞对应用系统的SDL安全开发具备重要意义。

1. Data Validation
2. Authentication(认证)
3. Session management
4. Authorization(受权)
5. Cryptography
6. Error handling
7. Logging
8. Security Configuration
9. Network Architecture 

 

3. SECURITY CODE REVIEW IN THE SDLC: 系统生命周期中的代码安全审计

虽然对于代码安全审计这项工做而言，并无一个硬性的强制性标准规定审计过程须要的规范程度，但Karl Wiegers仍是列出了一些列代码安全审计须要遵循的最基本步骤:

1. Ad hoc review
2. Passaround
3. Pair programming
4. Walkthrough
5. Team review
6. Inspection

SDLC的核心意义在于强调代码安全审计应该贯穿在整个项目开发过程当中，在完成一个功能点后马上进行安全方面的回归测试，这样不管是从成本效益仍是有效性方面都更加得体。
咱们要明白的是，代码安全审计是一个总体的生命周期，包括开发者回归测试、以及后期审计(例如CMS漏洞挖掘)，它是纵深防护中的重要一环。
SDLC的瀑布模型(Waterfall SDLC)

1. Requirements definition: 需求分析
    1.1 Application Security Requirements: 应用系统安全需求分析
2. Architecture and Design: 架构设计
    2.1 Application Security Architecture: 系统安全架构
    2.2 Threat Model: 风险模型
3. Development: 开发
    3.1 Secure Coding Practices: 代码开发最佳安全实践
    3.2 Security Testing: 安全测试
    3.3 Security Code Review: 代码安全审计
4. Test: 测试
    4.1 Penetration Testing: 渗透测试
5. Deployment: 部署
    5.1 Secure Configuration Management: 安全配置
    5.2 Secure Deployment: 安所有署
6. Maintenance: 后期维护

敏捷开发模型(Agile Security Methodology)

1. Planning
    1.1 Identify Security Stakeholder Stories
    1.2 Identify Security Controls
    1.3 Identify Security Test Cases
2. Sprints
    2.1 Secure Coding
    2.2 Security Test Cases
    2.3 Peer Review with Security
3. Deployment
    3.1 Security Verification (with Penetration Testing and Security Code Review)

 

 

4. SECURITY CODE REVIEW COVERAGE: 代码安全审计范围

0x1: UNDERSTANDING THE ATTACK SURFACE: 理解受攻击面
代码安全审计的一个重要的一部分是进行"受攻击面分析"。从本质上来理解应用系统，它就是一个接收指定参数，并根据不一样的业务场景产生对饮的格式化输出的系统，而攻击者要作的就是针对应用系统的全部输入点进行测试，找到存在处理漏洞的输入点，例如:

1. Browser input: 浏览器输入
2. Cookies: HTTP Cookie输入
3. Property files: 属性文件
4. External processes: 外部程序传输的数据
5. Data feeds: 数据反馈
6. Service responses: 服务返回数据包(例如REST)
7. Flat files: 文件IO
8. Command line parameters: 命令行参数
9. Environment variables: 环境变量(例如环境变量PATH劫持攻击)

对"受攻击面"的代码漏洞分析包括:

1. 动态数据流分析
2. 静态数据流分析

具体包括如下应该思考的问题:

1. 数据从哪里来
2. 变量被怎么赋值
3. 变量在整个工做流中被如何使用
4. 变量到哪里去
5. 对象属性是怎样影响到程序中的其余数据的

这些分析保证了程序中的参数、方法调用、数据交换都被进行了正确的安全控制。

0x2: UNDERSTAND WHAT YOU ARE REVIEWING: 理解你的审计对象
在进行代码安全审计的时候，全面地理解咱们的目标系统的代码结构(即审计对象)是十分重要的，由于现代的应用系统开发中大量使用到了框架(framework)，例如ASP.NET Framework、Java SSH(struts+spring+hibernate)、PHP中的CMS集成框架等。在大量使用框架的背景下，应用系统中出现的函数调用、对象操做就和咱们传统认识的形式会大不同，取而代之的是一些框架API的调用，若是咱们使用静态、或者动态的扫描器对应用系统进行扫描，天然不会扫描出任何漏洞。
所以，咱们必须充分了解、并识别目标应用系统所采用的开发框架，这样，才能作到深度业务逻辑扫描。

Java:

在struts程序中，struts-config.xml 以及web.xml这两个文件是获取整个应用系统函数结构的关键核心
struts-config.xml: 它包含了系统的全部HTTP访问的URL映射关系

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 1.0//EN"
"http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd">
    <struts-config>
        <form-beans>
            <form-bean name="login" type="test.struts.LoginForm" />
        </form-beans>
        <global-forwards>
        </global-forwards>
        <action-mappings>
            <action path="/login" type="test.struts.LoginAction" >
                <forward name="valid" path="/jsp/MainMenu.jsp" /> 
                <forward name="invalid" path="/jsp/LoginView.jsp" /> 
            </action>
        </action-mappings>
        <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
            <set-property property="pathnames" value="/test/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>
        </plug-in>
    </struts-config>

在structs framework框架中提供了一个"基于正则表达式的验证引擎(validator engine)"，使用这种机制，程序员不须要在代码中编写任何和表单验证有关的代码，struct会自动帮咱们完成。
在这种状况下，若是没有对structs的一个先验知识，而只是简单的对java代码进行审计，会认为目标应用系统没有采用任何规则和控制函数进行输入验证，从而形成误报。

.NET:
ASP.NET/IIS应用程序使用web.config(XML文件)来维护程序的配置信息，包括:

1. 身份认证
2. 受权
3. 错误处理、错误页面
4. HTTP设置
5. debug调试设置
6. WEB服务设置
..

web.config

<authentication mode="Forms">
    <forms name="name" loginUrl="url" protection="Encryption" timeout="30" path="/" requireSSL="true|" slidingExpiration="false">
        <credentials passwordFormat="Clear">
            <user name="username" password="password"/>
        </credentials>
    </forms>
    <passport redirectUrl="internal"/>
</authentication>

回顾这两个例子的意义在于，代码安全审计人员须要认识到，这些基于框架开发的程序，将安全控制放在了配置文件中，而不是硬编码在代码中，在进行审计工做和审计工具的编写的时候须要充分认识到这一点，对目标系统架构的理解越深入，才能更好地进行深层次的代码审计。

 

 

5. CODE REVIEW METRICS: 代码审计指标

对于代码安全审计工做来讲，意识到可使用一些评测指标来对目标进行全面的客观评估而不是仅仅依靠"挖出了多少漏洞"是很重要的。

SECURE DEVELOPMENT METRICS: 安全开发过程当中的代码审计的评测指标

0x1: DEFECT DENSITY: 缺陷密度

所谓缺陷密度，简单来讲就是系统中平均每行代码的编程错误的比例，这能从必定程度上侧面反映出目标系统的代码安全度

0x2: LINES OF CODE(LOC): 代码行数

通常来讲，系统的代码量越多，产生漏洞的可能性就越大。

0x3: FUNCTION POINT: 函数功能点

统计系统中有多少函数声明

0x4: RISK DENSITY: 漏洞密度

经过这个指标: 
[X Risk / LoC]
或
[Y Risk / Function Point]
(X/Y Risk表明发现的漏洞数量)

0x5: 路径复杂度

Thomas McCabe在20世纪70年代建立了路径复杂度理论，这很容易理解:
CC = Number of decisions +1
这里的"decisions"能够简单地理解为
If....else, Switch, Case, Catch, While, do, and so on.....
随着条件判断语句的增长，路径复杂度也相应增长，而咱们知道，不少时候，漏洞的产生就是由于钻了复杂业务路径的空子，太高的路径复杂度削弱了系统的稳定性、可维护性、和安全性控制性
1. 0-10: Stable code. Acceptable complexity
2. 11-15: Medium Risk. More complex
3. 16-20: High Risk code. Too many decisions for a unit of code.

REVIEW PROCESS METRICS: 后期代码安全审计中的评测指标

0x1: CODE COVERAGE: 代码覆盖率

代码覆盖率指的对代码行数、函数功能点的检查覆盖率。对于手工审计来讲，目标是100%，而对于自动化工具来讲，通常是80-90%(由于对目标系统的理解程度的缘由，自动化工具每每覆盖到代码的每一个路径)

0x2: DEFECT CORRECTION RATE: 缺陷修复率

这个指标评估平均每一个漏洞须要的修复时间、以及有多少已发现的漏洞已经被成功修复。

0x3: RE-INSPECTION DEFECT RATE: 漏洞重复发现率

这个评测指标每每针对这种状况，在发现了某个漏洞以后，只是针对当前的应用场景进行了修复，但没有去总结当前系统中是否还有这一类漏洞，致使在另外一个模块中又发现同一类漏洞，这在代码审计和安全开发中是应该极力避免的。
为了解决这个问题，一个好的作法是将这一类漏洞的缘由抽象出来，封装成一个统一的、高层的防护策略模块，并对全部潜在存在这一问题的代码位置部署这个安全模块。

 

6. CRAWLING CODE: 漏洞挖掘技巧

咱们知道，漏洞的挖掘过程就是一个"受攻击面识别以及利用的过程"，而对应应用程序来讲，受攻击面就是用户能够控制的部分，即接收数据的接口，包括:

1. 特定API调用
2. 文件IO
3. 用户配置、用户管理界面

从本质上来讲，漏洞的发生多是由于使用了某些自己就不安全的API、函数(语言自己的漏洞)、或者是使用这些API或者组合的方式不对致使的。
安全人员在进行漏洞挖掘的时候，第一步经常是使用搜索工具进行关键标识符的搜索并定位上下文。

0x1: .NET代码审计
对于.NET程序的代码审计，咱们主要关注如下几个方面
1. HTTP REQUEST STRINGS
从外部数据源获取用户输入绝对是代码安全审计的重点关注区域。对于用户输入，咱们须要关注如下几点:

1) 组成通过验证
验证输入中是否为"规范"的数据，防止出现SQL注入、缓冲区溢出等攻击payload
2) 输入长度
用户输入的数据必须在一个[min,max]范围内
3) 输入参数类型
使用参数化防护思路，保证用户输入的参数只在规定的白名单范围中。

对于这些要求，咱们在进行手工搜索审计或者自动化工具搜索的时候须要重点关注如下对象

request.accepttypes
request.browser
request.files
request.headers
request.httpmethod
request.item
request.querystring
request.form
request.cookies
request.certificate
request.rawurl
request.servervariables
request.url
request.urlreferrer
request.useragent
request.userlanguages
request.IsSecureConnection
request.TotalBytes
request.BinaryRead
InputStream
HiddenField.Value
TextBox.Text
recordSet

2. HTML OUTPUT
对于HTML OUTPUT，咱们关注的重点是系统向用户返回的数据，大多数状况下，针对客户端的攻击都是因为没有进行有效的输出验证致使的，例如XSS攻击
对于这些要求，咱们在进行手工搜索审计或者自动化工具搜索的时候须要重点关注如下对象

response.write
<% =
HttpUtility
HtmlEncode
UrlEncode
innerText
innerHTML

3. SQL & DATABASE
对于SQL注入漏洞的识别和发现涉及到和数据库操做相关的API，做为代码安全审计人员须要维护一份完整的SQL Database Relative API来对目标应用中的数据库操做进行准肯定位。
而相对的，要检测应用系统是否针对SQL注入进行了必要的防护，须要判断在相应的数据流动路径中是否采用了对应的参数化防护函数
对于这些要求，咱们在进行手工搜索审计或者自动化工具搜索的时候须要重点关注如下对象

exec sp_executesql
execute sp_executesql
update
delete from where
delete
exec sp_
execute sp_
exec xp_
execute sp_
exec @
execute @
executestatement
executeSQL
setfilter
executeQuery
GetQueryResultInXML
adodb
sqloledb
sql server
select from
Insert
driver
Server.CreateObject
.Provider
.Open
ADODB.recordset
New OleDbConnection
ExecuteReader
DataSource
SqlCommand
Microsoft.Jet
SqlDataReader
ExecuteReader
GetString
SqlDataAdapter
CommandType
StoredProcedure
System.Data.sql

4. COOKIES
Cookie污染是致使系统漏洞的一大因素，例如session hijacking、session fixation、参数污染(HPP攻击)。
须要明白的是，COOKIE的安全问题同时会影响到SESSION的安全问题
对于这些要求，咱们在进行手工搜索审计或者自动化工具搜索的时候须要重点关注如下对象

System.Net.Cookie
HTTPOnly
document.cookie

5. HTML TAGS
对HTML标签的关注主要是为了防护针对客户端的攻击，例如XSS。
对于这些要求，咱们在进行手工搜索审计或者自动化工具搜索的时候须要重点关注如下对象

HtmlEncode
URLEncode
<applet>
<frameset>
<img>
<style>
<layer>
<ilayer>
<meta>
<embed>
<frame>
<html>
<iframe>
<object>
<body>
<frame security
<iframe security

6. INPUT CONTROLS
在.NET程序中，有不少服务端类库负责生成接收用户输入的表单，对这些关键类进行定位和安全分析可以评测应用系统接收数据的安全性

system.web.ui.htmlcontrols.htmlinputhidden
system.web.ui.webcontrols.hiddenfield
system.web.ui.webcontrols.hyperlink
system.web.ui.webcontrols.textbox
system.web.ui.webcontrols.label
system.web.ui.webcontrols.linkbutton
system.web.ui.webcontrols.listbox
system.web.ui.webcontrols.checkboxlist
system.web.ui.webcontrols.dropdownlist

7. WEB.CONFIG
对于.NET这类基于框架开发的程序来讲，依靠.config文件来管理应用程序的配置设置，主要包括:

requestEncoding
responseEncoding
trace
authorization
compilation
CustomErrors
httpCookies
httpHandlers
httpRuntime
sessionState
maxRequestLength
debug
forms protection
appSettings
ConfigurationSettings
appSettings
connectionStrings
authentication mode
allow
deny
credentials
identity impersonate
timeout
remote

8. LOGGING
日志模块的设计缺陷可能致使应用系统数据泄漏的发生。一个最多见的漏洞是系统对用户的登陆请求进行了日志记录(在日志中包含明文的账号、密码)、或者对数据库的操做进行的日志记录(数据库账号、密码、用户隐私数据直接明文记录)。这些都属于严重的安全漏洞。
对于这些要求，咱们在进行手工搜索审计或者自动化工具搜索的时候须要重点关注如下对象

log4net
Console.WriteLine
System.Diagnostics.Debug
System.Diagnostics.Trace

9. REFLECTION, SERIALIZATION
咱们知道，除了静态的编写代码并编译运行外，程序中还存在动态的代数输入，即具体运行的代码在运行时中动态决定。我更倾向于把它归类于代码注入，由于动态的代码注入，使本来的代码逻辑发生了更大的改变，同时也引入了安全漏洞，例如序列化、反序列化漏洞
对于这些要求，咱们在进行手工搜索审计或者自动化工具搜索的时候须要重点关注如下对象

Serializable
AllowPartiallyTrustedCallersAttribute
GetObjectData
StrongNameIdentityPermission
StrongNameIdentity
System.Reflection

10. EXCEPTIONS & ERRORS
代码安全开发和代码安全审计的过程当中须要确保程序进行了正确的"错误处理"，即:

1. 合理使用了try-catch块保证隐私信息不被泄漏
2. 合理使用finnally块保证资源被正确释放 3. 使用自定义错误页面，即错误代理处理模式对错误信息进行逐层封装，保证底层的错误不被泄漏到表层UI

对于这些要求，咱们在进行手工搜索审计或者自动化工具搜索的时候须要重点关注如下对象

catch{
Finally
trace enabled
customErrors mode

11. CRYPTO
若是目标系统包含"加密处理模块"，则做为安全审计人员须要重点关注如下几个方面

1. 加密算法是否强度足够高
    1) AES 2) 3DES 2. 密钥长度是否足够长 3. HASH算法的强度 1) MD5 2) SHA1 4. 是否保证HASH不可逆存储 5. 随机算法、随机种子的安全性 1) PRNG

0x2: JAVASCRIPT / WEB 2.0代码审计

javascript和Ajax技术将函数功能的控制权带到了客户端，这在带来WEB2.0的新特性的同时也引入了新的安全问题。 
安全人员在审计代码的时候，须要额外关注这些将被返回到客户端浏览器的.js文件、或者javascript代码。

eval(
document.cookie
document.referrer
document.attachEvent
document.body
document.body.innerHtml
document.body.innerText
document.close
document.create
document.createElement
document.execCommand
document.forms[0].action document.location document.open document.URL document.URLUnencoded document.write document.writeln location.hash location.href location.search window.alert window.attachEvent window.createRequest window.execScript window.location window.open window.navigate window.setInterval window.setTimeout XMLHTTP

 

 

Copyright (c) 2014 LittleHann All rights reserved