相关学习资料
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
目录
. INTRODUCTION: 代码审计介绍
. PREPARATION: 代码审计需要的准备
. SECURITY CODE REVIEW IN THE SDLC: 系统生命周期中的代码安全审计
. SECURITY CODE REVIEW COVERAGE: 代码安全审计范围
. CODE REVIEW METRICS: 代码审计指标
. 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类型的漏洞，而有些则是具有很大危害性的致命性漏洞。
而对于大多数开发者来说，它们当中很多人在学校、或者工作中并没有接收过关于安全方面的培训(当然这个情况正在快速改善)。
随着信息化的极速发展，越来越多的新业务、新技术、新系统被开发出来，它们具备越来越多的功能，并且互联程度、依赖耦合也越来越高，但是，相应的安全技术以及针对这些新技术、新系统的安全审计工作却没有跟上步伐。
造成这一现象的原因有很多，而其中最重要的一点就是软件的高度封装性，即只向用户呈现一个提供功能的黑盒子。从用户的角度来说，用户很难从外表对这个软件的安全性做出准确判断。显性安全的问题直接导致了软件开发商不愿意投入过多的资金到安全审计中去，但这一情况在近几年正在得到不断改善，最大的变化就是:
) 像乌云、XSRC这样的漏洞披露平台的出现，让更多的用户了解到了安全漏洞的危害，同时也吸引了更多的安全工作着进入这个领域
) 媒体对安全事件的危机宣传提高了公民的安全意识
) 不论是普通用户、还是软件开发团队，对安全开发流程SDL的重视程度都越来越高
0x2: 什么是代码安全审计
代码审计就是通过阅读审计目标系统的源代码，检验是否在关键的逻辑流位置设置了正确的安全控制。
代码审计的目的是保证开发人员遵循了安全的开发技术。一般来说，对目标系统进行了一次完整的代码安全审计之后，模拟渗透测试就不应该发现任何额外的应用程序代码漏洞。
安全研究员往往采用手工(直接阅读源代码)和自动化技术(静态、动态代码分析工具)进行代码安全审计，诚然，自动化的工具能够节省大量的时间，可以在短时间内扫描大量的源代码，并按照设定的策略指出"可能"存在风险的代码位置。但是自动化工具不能理解上下文语境关系(代码层的漏洞和上下文的语境关系很密切)，在工具扫描结束之后，需要安全人员逐一确认工具指出的漏洞风险点，如果某个风险点经过验证是真实漏洞，安全人员还需要评估这个风险的风险系数。
2. PREPARATION: 代码审计需要的准备
0x1: LAYING THE GROUND WORK: 基础铺垫工作
作为代码审计团队人员，除了技术性的漏洞之外，应该更多地去关注应用系统的商业目的和主要的商业风险，这能帮助审计人员在识别不同的漏洞代理、它们的动机(攻击者的动机)、漏洞爆发可能(发现率)时能更好的做出判断，并做出正确的优先级排序，优先解决高技术风险、高商业风险的漏洞。
作为风险模型中的一个重要的环节，代码安全审计的结果可以被汇编起来，成为风险模型的一环，详细的展示出当前应用系统的细节安全问题。而我们知道，风险模型是一个迭代改进的过程，代码审计的最终目的也在如果，通过不断地确保目前的最高危漏洞已经得到正确的控制、修复，让应用系统以螺旋上升的方式不断得到改进。
在SDL的范畴中，代码安全审计人员应该在应用系统的架构设计阶段就参与到开发团队中。对于代码安全审计人员来说，要将自己当成是一个建议者，和开发人员一起去改进代码，完善系统，而不要本着一个警察的态度去纠错，那么会适得其反。
0x2: BEFORE WE START: 代码审计需要的基础知识
作为代码审计人员，需要熟悉以下内容
. Code: 代码
审计人员需要熟悉目标系统所使用的开发语言、这个语言的特性、以及这个语言本身存在的漏洞。从安全的角度来看，不同的语言(例如PHP、ASP、Java)本身的一些特性和漏洞往往也会反映在代
码漏洞上(虽然代码漏洞大多数时候是程序没有遵循安全编码规范导致的逻辑漏洞)
. Context: 环境背景
在进行代码审计之前，了解目标应用系统的环境背景十分重要，我们需要了解:
) 我们正在操作什么类型的数据，即系统的输入、输出问题。我们知道，很很多漏洞和数据流的流动以及安全处理有关，所以，了解目标应用系统的数据流结构很重要
) 当发生数据泄漏时对公司的损失有多大
. Audience: 目标用户
了解当前审计的应用系统的目标用户是谁:
) 相对可信任的企业内网用户
) 面向公网的普通用户
) 外部系统、外部服务
. Importance: 稳定性
可用性对应用系统来说也是十分重要的，安全审计人员需要了解如果目标系统突然重启、停机会对企业造成多大的危害。我们知道，不管是"云机房建设标准"中对机房的服务器每年允许的"停止服
务时间"作出最大上限的规定，还是"SLA(Service Level Aggrement)"中对用户承诺的服务质量，应用系统保持稳定运行，并不受DDOS攻击的影响都是十分重要的
0x3: DISCOVERY: GATHERING THE INFORMATION: 信息收集
在开始审计攻击之前，对目前信息系统进行一些必要的信息收集对审计工作的有效开展十分有意义，一般来说，信息收集的手段有:
) 查看项目的设计文档
) 和项目开发人员、首席架构师进行交谈，了解应用系统的架构信息
) 亲身体验一下系统的UI、功能，获取一个直观的认识
) 了解目标系统的代码结构、所使用的开源库等等
0x4: CONTEXT, CONTEXT, CONTEXT: 明确你的目的
作为安全研究员，我们要明白安全代码审计并不仅仅是在使用工具或者人工对源代码进行审计(阅读)。代码审计的目的是保证代码对应用系统的机密信息和企业财产进行了合理的保护。
对于一个应用系统来说，可能会存在很多的实际漏洞(可被攻击)、和潜在的漏洞风险。
) 对于实际存在的漏洞，毫无疑问是应该立即采取措施进行修补
) 而对于潜在的漏洞风险，则应该根据企业自身的环境、商业目标来对风险进行评估，优先将资源、时间投入到那些相对高风险的漏洞修补中，以实现效益最大化
伴随着代码安全审计的开展，一个高层次的风险威胁模型应该被建立，它包括
) Threat Agents: 威胁代理
) Attack Surface: 受攻击面，即黑客可以从哪些角度对系统进行攻击
2.1) public interfaces
2.2) backend interfaces
) Possible Attacks: 可能的攻击方式
) Required Security Controls: 需要采取的安全控制机制
4.1) stop likely attacks: 组织可能发生的攻击
4.2) meet corporate policy: 满足企业、国家标准对系统安全的准入准则
) Potential Technical Impacts: 发生攻击后对企业产生的潜在的技术影响
) Important Business Impacts: 发生攻击后对企业产生的潜在的商业影响
在进行上下文环境信息收集的时候，安全人员可以简单地询问开发团队以下问题
. 信息系统包含了什么类型的数据/资产
. 敏感数据是怎么进入信息系统并被保存的
. 信息系统是对内使用的还是对外使用的，用户的可信度有多高
. 信息系统被部署的主机处于企业网络架构中的什么位置
处于安全考虑，对于未经验证的用户不允许通过DMZ区域(往往是WEB服务区)进而访问到LAN区域(后端数据库)。即使是对于内部用户，也需要通过验证，没有验证也就意味着不可问责，导致失去
追溯审计能力。
0x5: THE CHECKLIST: 检查清单
检查清单(check list)规定的是代码审计团队的审计目标，检查清单的完善性、以及是否覆盖了当前系统中的主要安全漏洞对应用系统的SDL安全开发具有重要意义。
. Data Validation
. Authentication(认证)
. Session management
. Authorization(授权)
. Cryptography
. Error handling
. Logging
. Security Configuration
. Network Architecture
3. SECURITY CODE REVIEW IN THE SDLC: 系统生命周期中的代码安全审计
虽然对于代码安全审计这项工作而言，并没有一个硬性的强制性标准规定审计过程需要的规范程度，但Karl Wiegers还是列出了一些列代码安全审计需要遵循的最基本步骤:
. Ad hoc review
. Passaround
. Pair programming
. Walkthrough
. Team review
. Inspection
SDLC的核心意义在于强调代码安全审计应该贯穿在整个项目开发过程中，在完成一个功能点后立刻进行安全方面的回归测试，这样无论是从成本效益还是有效性方面都更加得体。
我们要明白的是，代码安全审计是一个整体的生命周期，包括开发者回归测试、以及后期审计(例如CMS漏洞挖掘)，它是纵深防御中的重要一环。
SDLC的瀑布模型(Waterfall SDLC)
. Requirements definition: 需求分析
1.1 Application Security Requirements: 应用系统安全需求分析
. Architecture and Design: 架构设计
2.1 Application Security Architecture: 系统安全架构
2.2 Threat Model: 风险模型
. Development: 开发
3.1 Secure Coding Practices: 代码开发最佳安全实践
3.2 Security Testing: 安全测试
3.3 Security Code Review: 代码安全审计
. Test: 测试
4.1 Penetration Testing: 渗透测试
. Deployment: 部署
5.1 Secure Configuration Management: 安全配置
5.2 Secure Deployment: 安全部署
. Maintenance: 后期维护
敏捷开发模型(Agile Security Methodology)
. Planning
1.1 Identify Security Stakeholder Stories
1.2 Identify Security Controls
1.3 Identify Security Test Cases
. Sprints
2.1 Secure Coding
2.2 Security Test Cases
2.3 Peer Review with Security
. Deployment
3.1 Security Verification (with Penetration Testing and Security Code Review)
4. SECURITY CODE REVIEW COVERAGE: 代码安全审计范围
0x1: UNDERSTANDING THE ATTACK SURFACE: 理解受攻击面
代码安全审计的一个重要的一部分是进行"受攻击面分析"。从本质上来理解应用系统，它就是一个接收指定参数，并根据不同的业务场景产生对饮的格式化输出的系统，而攻击者要做的就是针对应用系统的所有输入点进行测试，找到存在处理漏洞的输入点，例如:
. Browser input: 浏览器输入
. Cookies: HTTP Cookie输入
. Property files: 属性文件
. External processes: 外部程序传输的数据
. Data feeds: 数据反馈
. Service responses: 服务返回数据包(例如REST)
. Flat files: 文件IO
. Command line parameters: 命令行参数
. Environment variables: 环境变量(例如环境变量PATH劫持攻击)
对"受攻击面"的代码漏洞分析包括:
. 动态数据流分析
. 静态数据流分析
具体包括以下应该思考的问题:
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文件)来维护程序的配置信息，包括:
. 身份认证
. 授权
. 错误处理、错误页面
. HTTP设置
. debug调试设置
. WEB服务设置
..
web.config
<authentication mode="Forms">
<forms name="name" loginUrl="url" protection="Encryption" timeout="" 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 +
这里的"decisions"可以简单地理解为
If....else, Switch, Case, Catch, While, do, and so on.....
随着条件判断语句的增加，路径复杂度也相应增加，而我们知道，很多时候，漏洞的产生就是因为钻了复杂业务路径的空子，过高的路径复杂度削弱了系统的稳定性、可维护性、和安全性控制性
. -: Stable code. Acceptable complexity
. -: Medium Risk. More complex
. -: High Risk code. Too many decisions for a unit of code.
REVIEW PROCESS METRICS: 后期代码安全审计中的评测指标
0x1: CODE COVERAGE: 代码覆盖率
代码覆盖率指的对代码行数、函数功能点的检查覆盖率。对于手工审计来说，目标是100%，而对于自动化工具来说，一般是80-%(因为对目标系统的理解程度的原因，自动化工具往往覆盖到代码的每个路径)
0x2: DEFECT CORRECTION RATE: 缺陷修复率
这个指标评估平均每个漏洞需要的修复时间、以及有多少已发现的漏洞已经被成功修复。
0x3: RE-INSPECTION DEFECT RATE: 漏洞重复发现率
这个评测指标往往针对这种情况，在发现了某个漏洞之后，只是针对当前的应用场景进行了修复，但没有去总结当前系统中是否还有这一类漏洞，导致在另一个模块中又发现同一类漏洞，这在代码审计和安全开发中是应该极力避免的。
为了解决这个问题，一个好的做法是将这一类漏洞的原因抽象出来，封装成一个统一的、高层的防御策略模块，并对所有潜在存在这一问题的代码位置部署这个安全模块。
6. CRAWLING CODE: 漏洞挖掘技巧
我们知道，漏洞的挖掘过程就是一个"受攻击面识别以及利用的过程"，而对应应用程序来说，受攻击面就是用户可以控制的部分，即接收数据的接口，包括:
. 特定API调用
. 文件IO
. 用户配置、用户管理界面
从本质上来说，漏洞的发生可能是因为使用了某些本身就不安全的API、函数(语言本身的漏洞)、或者是使用这些API或者组合的方式不对导致的。
安全人员在进行漏洞挖掘的时候，第一步常常是使用搜索工具进行关键标识符的搜索并定位上下文。
0x1: .NET代码审计
对于.NET程序的代码审计，我们主要关注以下几个方面
1. HTTP REQUEST STRINGS
从外部数据源获取用户输入绝对是代码安全审计的重点关注区域。对于用户输入，我们需要关注以下几点:
) 组成经过验证
验证输入中是否为"规范"的数据，防止出现SQL注入、缓冲区溢出等攻击payload
) 输入长度
用户输入的数据必须在一个[min,max]范围内
) 输入参数类型
使用参数化防御思路，保证用户输入的参数只在规定的白名单范围中。
对于这些要求，我们在进行手工搜索审计或者自动化工具搜索的时候需要重点关注以下对象
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