代码安全介绍

4
第二章、代码安全问题分类介绍
2.1 输入验证与表示 2.2 API误用 2.3安全特性 2.4时间与状态 2.5错误处理 2.6代码质量 2.7环境和封装
目前软件代码中的风险非常多，根据CERT的统计，最近 几年都稳定在5000多个。对这些安全漏洞的分类目前有很多 种，本文主要采用了McGraw提出的分类方法。本文将软件 代码中存在的安全漏洞分为8类，分别是：输入验证与表示 ，API误用，安全特征，时间与状态，错误处理，代码质量 、环境和封装。
这样如果在输入验证逻辑里发现问题时就可以比较方便的修改。 4. 失败控制：
如果一个集中处理输入验证框架收到它不知道如何处理的输入， 很容易就拒绝掉该输入，如果没有采取集中输入验证，开发者很容易 忘记进行输入验证。
13
第三章、安全建议—输入处理
3.1集中输入验证 3.2保证所有输入信息 被验证过 3.3建立可信边界 3.4检测输入长度 3.5拒绝验证失败数据 3.6验证HTTP请求中的 所有组成 3.7对来自命令行、环 境以及配置文件的输入 进行校验 3.8控制写入日志信息 3.9输入验证时使用最 强的形式 3.10防范元字符攻击
3.1集中输入验证 3.2保证所有输入信息 被验证过 3.3建立可信边界 3.4检测输入长度 3.5拒绝验证失败数据 3.6验证HTTP请求中的 所有组成 3.7对来自命令行、环 境以及配置文件的输入 进行校验 3.8控制写入日志信息 3.9输入验证时使用最 强的形式 3.10防范元字符攻击
不要允许攻击者能够写任意的数据到日志里
2.7环境和封装 6
第二章、代码安全问题分类介绍
2.1 输入验证与表示 2.2 API误用 2.3安全特性 2.4时间与状态 2.5错误处理 2.6代码质量 2.7环境和封装
API是调用者与被调用者之间的一个约定，大多数的API 误用是由于调用者没有理解约定的目的所造成的。
比如如果一个编码人员继承了SecureRandom，返回 的却是一个非随机值，那么他就违背了约定。
验证来自HTTP请求中的所有数据，恶意数据可以从表单域， URL参数，cookie，http头以及 URL自身传入。
无论一个 HTTP请求看起来多么的“正常”，都应该对 它进行完整的检查。
攻击者可以在你提供给他们的 web页面里输入任何内 容，他们可以完全脱离浏览器和浏览器的一切验证，修改 Cookie、隐藏区域、 name与 value的对应关系，他们可 以为了“错误”的目的在“错误”的时间按“错误”的顺序 提交 URL请求。
正确的和长期的记录对于在已部署的软件系统中寻找缺 陷和发现安全弱点是很重要的。我们可以手工或者自动的分 析日志来查找重要的事件、一段时间内的趋势，它是检测系 统和用户行为的宝贵资源。
由于日志的价值，它也成为了攻击者的目标。如果攻击 者可以控制写进日志文件的信息，他们就可以在输入中混入 伪造的日志条目来伪造系统事件，更严重的是，如果负责进 行日志分析的代码存在漏洞，特定的有恶意的输入很可能触 发该漏洞，并引发更加严重的危害。
3
第一章、序言
1.1 背景 1.2 编码中的安全问题
这些威胁主要是由于开发人员缺乏安全编码的意识和自 身对软件安全知识了解不足、所适用的对开发语言和开发技 术的缺陷了解不足、没有以黑客思维去看待软件而导致的， 表现为攻击者可以利用开发技术自身的漏洞、恶意输入以及 异常连接等问题，对应用软件系统进行攻击，发现并利用软 件中存在的安全漏洞。
不要使你的软件的安全性依赖于配置和维护它的人
对来自命令行、系统属性，环境变量以及配置文件的输 入都需要进行校验来保证它们是一致的和健全的。如果攻击 者对系统的属性进行修改，可以通过命令行，环境以及配置 文件来威胁软件系统，这里要求软件开发者不要相信来自命 令行、环境以及配置文件的输入。
19
第三章、安全建议—输入处理
当程序混淆了可信和不可信数据的界限时会导致安全边 界发生问题，最容易导致这种错误的情况是把可信和不可信 数据混合在一个数据结构里。这里举了一个例子：
15
第三章、安全建议—输入处理
3.1集中输入验证 3.2保证所有输入信息 被验证过 3.3建立可信边界 3.4检测输入长度 3.5拒绝验证失败数据 3.6验证HTTP请求中的 所有组成 3.7对来自命令行、环 境以及配置文件的输入 进行校验 3.8控制写入日志信息 3.9输入验证时使用最 强的形式 3.10防范元字符攻击
确保在输入验证之前，新输入的数据不要被添加到程序 中（输入的数据不能进入程序代码中被执行）。也就是说， 程序默认情况下就要对输入的信息进行验证，不能通过验证 的数据将会被拒绝。这样的话，开发者就不会忘记进行输入 验证了。
14
第三章、安全建议—输入处理
3.1集中输入验证 3.2保证所有输入信息 被验证过 3.3建立可信边界 3.4检测输入长度 3.5拒绝验证失败数据 3.6验证HTTP请求中的 所有组成 3.7对来自命令行、环 境以及配置文件的输入 进行校验 3.8控制写入日志信息 3.9输入验证时使用最 强的形式 3.10防范元字符攻击
18
第三章、安全建议—输入处理
3.1集中输入验证 3.2保证所有输入信息 被验证过 3.3建立可信边界 3.4检测输入长度 3.5拒绝验证失败数据 3.6验证HTTP请求中的 所有组成 3.7对来自命令行、环 境以及配置文件的输入 进行校验 3.8控制写入日志信息 3.9输入验证时使用最 强的形式 3.10防范元字符攻击
5
第二章、代码安全问题分类介绍
2.1 输入验证与表示 2.2 API误用 2.3安全特性
输入验证和表示问题通常是由特殊字符、编码和数字表 示所引起的，这类安全问题的发生是对输入的信任所造成的 。一些较大的安全问题往往都是由于对输入的信息过度信任 造成的。
2.4时间与状态
2.5错误处理
2.6代码质量
验证的时候应该验证允许输入的最小和最大长度
如果对最大输入长度进行限制，攻击者就很难对系统的 其它弱点进行攻击。譬如，对于一个很可能被用来进行跨站 脚本攻击的输入域，如果攻击者可以输入任意长度的脚本， 那么这显然要比限制输入长度更加危险。而对最短长度的检 测可以使攻击者无法忽略强制要求输入的域，同时也无法输 入与预期不符的数据。
7
第二章、代码安全问题分类介绍
2.1 输入验证与表示 2.2 API误用 2.3安全特性 2.4时间与状态 2.5错误处理 2.6代码质量 2.7环境和封装
安全特征主要关系认证，访问控制，机密性，密码，权 限管理等方面的内容。
8
第二章、代码安全问题分类介绍
2.1 输入验证与表示 2.2 API误用 2.3安全特性 2.4时间与状态 2.5错误处理 2.6代码质量 2.7环境和封装
这些问题可能涉及到线程、进程、时间和信息之间的非 法交互。这些交互通过共享的状态产生：如信号量、变量、 文件系统以及任何能够存储信息的东西。
9
第二章、代码安全问题分类介绍
2.1 输入验证与表示 2.2 API误用 2.3安全特性 2.4时间与状态 2.5错误处理 2.6代码质量 2.7环境和封装
错误和错误处理代表了一类API。与错误处理有关的错 误是很常见的。与API误用相比，和错误处理相关的安全漏 洞一般是两种方式造成的：
代码安全介绍
1
第一章、序言
1.1 背景 1.2编码中的安全问题
据美国IDC 公司2006年对企业信息安全的调查和统计， 70%以上的信息安全问题是因为应用系统自身的安全问题而 遭到黑客的攻击，而不是因为网络;同时 NIST对近几年的信 息安全的事故的跟踪调查显示，几乎92%的信息安全事故都 与软件相关。
如果我们能够引导用户，使他们提交的请求能够通过输 入验证，就能比专注于自动错误恢复代码有效得多。
17
第三章、安全建议—输入处理
3.1集中输入验证 3.2保证所有输入信息 被验证过 3.3建立可信边界 3.4检测输入长度 3.5拒绝验证失败数据 3.6验证HTTP请求中的 所有组成 3.7对来自命令行、环 境以及配置文件的输入 进行校验 3.8控制写入日志信息 3.9输入验证时使用最 强的形式 3.10防范元字符攻击
低劣的代码质量会导致不可预测的行为。从用户的角度 来看，这通常会表现为低劣的可用性。对于攻击者而言，低 劣的代码使他们可以以意想不到的方式威胁系统。
百度文库11
第二章、代码安全问题分类介绍
2.1 输入验证与表示 2.2 API误用 2.3安全特性 2.4时间与状态 2.5错误处理 2.6代码质量 2.7环境和封装
分布式计算是与时间和状态有关的。也就是说，为了让 多个部件之间交互，需要状态共享，而这要花费时间。
大多数程序员将他们的工作人格化。他们认为控制器的 一个线程会按照他们所想的方式来执行整个程序。然而，现 在的计算机能在多任务之间快速切换，采用多核、多CPU或 者说分布式系统，两个事件甚至能在同一时间发生。这样一 来，在程序员所想的程序执行模式和实际发生的情况之间就 会产生问题。
封装就是划定强力的分界线。在 web浏览器中，这就意 味着你的代码模块不能被其他代码模块滥用。在服务端，这 意味着要区分校验过的数据和未经校验的数据，区分不同用 户的数据，或者区分用户能看到的和不能看到的数据。
12
第三章、安全建议—输入处理
3.1集中输入验证 3.2保证所有输入信息 被验证过 3.3建立可信边界 3.4检测输入长度 3.5拒绝验证失败数据 3.6验证HTTP请求中的 所有组成 3.7对来自命令行、环 境以及配置文件的输入 进行校验 3.8控制写入日志信息 3.9输入验证时使用最 强的形式 3.10防范元字符攻击
将可信和不可信数据分别储存来保证输入验证总是被执行。
可信边界可以被认为是在程序中划定的一条分隔线，一 边的数据是不可信的而另一边则是可信的。当数据要从不可 信的一侧到可信一侧的时候，需要使用验证逻辑进行判断。
需要在程序中定义清晰的可信边界。在一些代码中使用 的保存可信数据的数据结构，不能被用来在其它代码中存储 不可信数据。使数据穿越可信边界的次数降到最低。
拒绝验证失败的数据，不试图对其进行修复
通过设置默认值来保存一个丢失的输入，处理密码域时 自动剪裁掉超过最大长度的输入，替换掉在输入框输入的 JavaScript字符等行为是很危险的，不要试图修复一个未能 通过输入验证的请求，直接拒绝掉，这样才是安全的。
输入验证本身就很复杂，如果和自动错误恢复的代码混 合在一起的话，将会造成更大的复杂性，自动错误恢复代码 很可能改变请求的含义或者截断验证逻辑。
第一种是：根本忘记处理错误或者只是简单的处理，并 没有彻底解决； 第二种则是：程序对可能的攻击者泄露了过多的信息或 者涉及面太广没有人愿意去处理这些问题。
10
第二章、代码安全问题分类介绍
2.1 输入验证与表示 2.2 API误用 2.3安全特性 2.4时间与状态 2.5错误处理 2.6代码质量 2.7环境和封装
对输入长度的检测是输入验证最基本的要求，但是，好 的输入验证并不是仅仅检测输入长度，还可以根据被验证程 序的上下文进行更深入的检测。如果程序需要验证一个输入 域，验证逻辑对该域的合法值限定得越详细，验证逻辑就能 越好地工作。
16
第三章、安全建议—输入处理
3.1集中输入验证 3.2保证所有输入信息 被验证过 3.3建立可信边界 3.4检测输入长度 3.5拒绝验证失败数据 3.6验证HTTP请求中的 所有组成 3.7对来自命令行、环 境以及配置文件的输入 进行校验 3.8控制写入日志信息 3.9输入验证时使用最 强的形式 3.10防范元字符攻击
把输入验证作为软件框架的一部分。
集中处理输入验证框架带来的好处如下：
1. 所有的输入使用一致的输入验证： 如果每个模块各自独立实现自己的输入验证，将会很难建立一个统
一的输入验证策略。 2. 有效降低工作量：
输入验证比较灵活，分别实现输入验证会导致其工作量成倍的增 加。 3. 对输入验证进行统一的升级和修改：
2
第一章、序言
1.1 背景 1.2 编码中的安全问题
在软件的编码阶段，主要软件安全问题来源于如下几个 方面：
软件自身的代码缺陷 用户恶意输入 不期望的连接
在整个软件系统中主要体现在如下几个方面带来安全隐 患：
输入验证与表示 API误用 安全特征 时间与状态 错误处理 代码质量 封装和环境等安全漏洞