软件安全问题
有趣的《黑客帝国》终极解释：
《黑客帝国》故事里面的人物关系，就像电脑里面的各种程序的关系一样：
电脑里面的系统程序：Matrix；
病毒程序：以Neo为首的人类；
防病毒软件：Agent特工、机器章鱼、先知（迷惑和引导病毒程序的）；
以及出错程序：Smith和Merovingian。
第一集：病毒程序入侵Matrix，唤醒被隔离的病毒源代码Neo，并通过破坏Agent特工这些防毒软件取得控制部分机器系统的胜利。
第二集：讲述Matrix系统通过蒙骗的方法将Neo等病毒代码或受感染的程序收集引导到一个Zion区域，进行杀毒，结果在片尾，病毒程序Neo意识到了这一点。
第三集：Matrix系统软件通过利用Agent防病毒软件和Smith出错程序来对付Neo这些病毒程序，并且成功地消灭了这两方，达到系统防御能力升级。
其实故事一开头就注定了Neo的悲剧结局和人类的失败。因为病毒如果最后导致系统崩溃，病毒也将被消灭。所以病毒要不被系统消灭，要不导致系统崩溃，和系统一起灭亡。
软件安全问题的根源：内因：软件有错误
* 脆弱点
* 缺陷(设计层)
* Bug(实现层)
* 软件开发方法存在问题
外因：软件的运行环境
* 网络对软件的发展产生了巨大的影响（负面居多）
外部环境：黑客、恶意代码
内部环境：误操作、报复、经济犯罪
7+1的软件安全问题领域：1.输入验证和表示法
2.滥用API
3.安全特性
4.时间和状态
5.错误处理
6.代码质量
7.封装
*.环境
1.输入验证和表示法输入验证和表示问题由元字符、替换编码、数字表示法引起。如果选择使用输入验证，那么就要使用白列表、而不是黑列表。
由于轻信输入而造成的大问题包括：缓冲区溢出、跨站脚本攻击、SQL注入、缓存毒药和其它脚本小子们非常轻易吃到的“低挂的果实”（这里只安全性较低的软件设计）。
2.滥用APIAPI规定了调用者和被调用程序之间的使用约定。滥用API的常见模式是由调用者错误地信任被调用方造成的。例如，调用者希望从被调用程序那里返回获取用户信息，而被调用程序并没有任何的安全性保证其信息的可靠性。于是调用者就假定了调用程序返回数据的正确性和安全性。当然，也存在“坏人”有意破坏调用者-调用程序之间约定的行为。
3.安全特性软件安全不是安全软件。世界上所有的加密算法都不能满足真正的安全需要。尽管使用SSL保护网络流量的手段，而认证、访问控制、机密性保障、加密算法、权限管理等都可能存在着安全缺陷。
4.时间与状态分布式计算与时间和状态相关。为了使多个组件进行通信，状态必须在组件之间共享，而所有这些都需要花费时间。因此在时间和状态之间可能存在着巨大的、未发现的天然攻击资源。
多数开发者人格化了他们的工作（将程序看作“它”的单体）。他们自以为单一、全能的控制线程能够孜孜不倦地日夜工作，以同一种方式支撑整个应用。而现代计算机在任务之间切换速度与日俱增，并且多核、多CPU或者分布式系统的应用使两件事情完全可以在同一时间发生。因此缺陷便出现在开发者所设想的程序执行模型和实际情况之间的差异中。这些缺陷与在线程、进程、时间和信息之间的无法预期的交互相关。而这些交互往往通过共享状态发生：信号、变量、文件系统、全局信息等。
5.错误处理如果想破坏软件，那么就让它抛出一下垃圾数据，并看看你导致了哪些错误。在现代面向对系统中，异常的想法取代了被禁止的goto概念。
与错误处理相关的安全缺陷在开发中很常见。在API被滥用的情况下，安全缺陷主要存在于两种方式：第一，开发者忘记处理错误或者粗略得处理错误；第二，在产生错误时要么给出过于详细的信息，要么错误过于太具放射性以至于没有可处理它们的方式。
6.代码质量安全是可靠性的子集。如果可以完整地描述你的系统和其存在的正面、负面的安全可能性，那么安全成为了可靠性的子集。劣质代码将导致无法预期的行为，从软件使用者的观点，它将被认为是很差的可用性；而从攻击者的视角看，糟糕的代码将提供给系统施压的可乘之机。
7.封装封装是指在事物之间的边界和它们之间建立的界限。在web浏览器中，它确保了移动代码不能够强行我们的硬盘攻击。在web服务端，它意味着在经过认证的有效数据和私密数据之间的差别。这里的边界非常重要，如今在类之间的一些方法构成了重要的边界，因此信任模式需要谨慎的设置。
8.环境这是上面七种领域的外部领域，它包括在代码外部的所有东西，并对于我们建立的软件安全同样重要。
十大web安全问题：1.未验证输入 问题描述：web 请求信息在被Web应用使用之前都是未验证的，攻击者能够利用其中的弱点攻击服务器；攻击者通过伪造HTTP请求的各个部分，例如URL，查询字符串，头，cookies，表单域，隐藏域等绕过站点的安全机制。
这些常见的伪造输入攻击通常包括：强制浏览，命令插入，跨站脚本，缓冲区溢出，格式化字符串，SQL注入，cookie中毒，隐藏域操作等等。
保护方法：过滤恶意输入；客户端输入验证、服务器端验证。
2.破坏访问控制 问题描述：对认证用户能够进行的操作缺乏合理的限制。攻击者利用其中的缺陷访问其他用户的账户，浏览敏感文件，或使用未授权的功能。
保护方法：
加强对会话的保护（会话ID）；
防止暴力浏览绕过访问控制检查；
合理设置访问权限；
禁止客户端缓存。
3.破坏认证和会话管理 问题描述：账户信用和会话令牌没有被合理保护，攻击者能够危及密码、密钥、会话cookies或其他限制而冒用他人的账户
保护方法：
加强密码强度；
限制登录次数；
使用SSL保护传输中的认证信息；
使用SSL保护会话ID；
禁止客户端缓存。
4.跨站脚本缺陷 问题描述：web应用能被利用将攻击转送到端用户的浏览器。成功的跨站攻击能够暴露用户的会话令牌，攻击本地计算机或者用虚假信息欺骗用户。
保护方法：
对用户提供的输出进行编码；
根据白列表，严格验证查询字符串；
过滤、清除页面请求中的活动内容。
5.缓冲区溢出漏洞 问题描述：Web应用组件可能存在缓冲区溢出漏洞，对它的攻击会造成严重的攻击后果。这种漏洞是由于CGI，库函数，驱动程序、应用服务器组件等没有合理地验证输入。
保护方法：
密切跟踪Web应用产品的最新错误报告，及时打补丁；
使用漏洞扫描工具定期对系统进行缓冲区溢出漏洞扫描；
严格审查Web应用程序中从用户请求接收数据的代码，确保对缓冲区长度进行了检查。
6.注入缺陷 问题描述：Web应用在访问外部系统或本地操作系统时需要传递参数，这些参数可能会被攻击者利用嵌入恶意代码，这样导致外部系统能以应用服务器的权限执行系统命令。
保护方法：
避免使用外部解释器；
对于涉及到的后台数据库调用，应对数据进行严格验证；
将Web应用程序设置为能满足需要的最小权限运行；
不得不使用外部命令时进行严格检查；
应该检查调用的所有输出、返回代码和错误代码，最低限度要能确定何时发生了错误。
7.不合理的错误处理 问题描述：正常操作中的错误条件没能合理处理，如果攻击者使Web应用产生未作处理的错误，就能得到具体系统信息，使安全机制失效，使服务器崩溃。
保护方法：
设计合理的错误处理策略并作好文档，包括要处理的错误类型、错误提示信息、日志需记录的信息；
处理所有可能的错误，但不暴露不该暴露的细节；
遇到重复的错误尝试时发出警告。
8.不安全存储 问题描述：Web应用经常使用加密函数保护信息和身份证明，这些函数和保护其完整性的代码很难完全正确地实现，从而导致弱保护问题。
保护方法
除非必要，尽量少保存数据；
存储密码的摘要（例如SHA-1）而非加密的密码；
必须使用加密算法时，尽量采用公开的密码算法库。并妥善存储秘密信息，如密钥、证书、密码等。
9.拒绝服务 问题描述：攻击者能够消耗Web应用的资源，使其无法正确为合法用户服务，或封闭用户账户甚至使服务瘫痪。
保护方法：
限定分配给每个用户最少量的资源；
限制每个合法用户仅有一个连接，并采用适当的丢弃部分请求的策略；
避免非认证用户对数据库或其他关键资源的非必要访问；
使用内容缓存的方法减少对数据库的访问。
10.不安全配置管理 问题描述：对服务器合理配置是实现安全性的重要因素，服务器通常都有损害安全性的不合理配置。
保护方法：
为特定服务器和Web服务器建立强化安全配置策略，关闭无用服务，建立角色、权限和账户，使用日志和告警措施；
始终维护服务器的安全配置，跟踪最新安全漏洞，应用最新补丁，升级安全设置，定期漏洞扫描，定期进行内部审查。
两种安全模型：微软的安全软件开发模型：1.安全开发生命周期（SDL）：
SDL总计为四步：
第一步：安全教育，通过教育才能提高安全意识。 设计人员：学会分析威胁
开发人员：跟踪代码中每字节数据、质疑所有关于数据的假设
测试人员：关注数据的变化
第二步：设计阶段，利用威胁建模技术建立系统模型。第三步：开发阶段，编码与测试并行。第四步：发行与维护阶段，使用标准的修复机制修复安全缺陷。2.威胁建模：威胁模型是一种基于安全的分析，有助于人们确定给产品造成的最高级别的安全风险，以及攻击是如何表现出来的。
其目标是确定需要缓和哪些威胁，如何来缓和这些威胁。
主要分为四个步骤：第一步：分解应用程序。使用DFD（数据流图）或者UML（统一建模语言）描述威胁模型，作为分析应用程序的重要组成部分。对应用程序进行形式化分解，自顶向下，逐层细化，在分解过程中关注过程之间的数据流。
例如：
第二步：确定系统面临的威胁。按照“STRIDE”威胁模型：
S：身份欺骗(Spoofing identity)，造成冒充合法用户、服务器欺骗(DNS 欺骗，DNS缓存中毒)。
T：篡改数据(Tampering with data)。
R：否认(Repudiation)、。
I：信息泄露(Information disclosure)。
D：拒绝服务(Denial of service, DOS)。
E：特权提升(Elevation of privilege)。
第三步：威胁评估。按照“DREAD”算法为威胁分级，并建立攻击树：
D：潜在的破坏性(damage potential)
R：再现性(reproducibility)
E：可利用性(exploitability)
A：受影响的用户(affected users)
D：可发现性(discoverability)
例如：
Threat #1: 恶意用户浏览网络上的秘密工资数据
潜在的破坏性: 读取他人的私密工资并不是开玩笑的事。——风险值为8
再现性:100%可再现。——风险值为10
可利用性: 必须处于同一子网或者处于同一路由器下。——风险值为7
受影响的用户: 每个人都将受到影响。——风险值为10
可发现性: 让我们假设它已经发生。——风险值为10
计算风险DREAD: (8+10+7+10+10) / 5 = 9
攻击树描述了攻击者利用系统漏洞破坏各组件，对威胁目标进行攻击所经历的决策过程。建立攻击树需要考虑的几个方面：
安全威胁：潜在的事件，当攻击有动机并付诸实施时，威胁转变为攻击事件。
安全漏洞：系统中的弱点。
资源：受威胁(或攻击)的目标。
例如：
对Threat #1的威胁描述表格：
Threat #1的攻击树：
第四步：建立缓和方案，选择适当的安全技术。
接触点开发模型:
根据有效性排列的接触点:
代码审查（Code review）
架构风险分析（Architectural risk analysis ）
渗透测试（Penetration testing ）
基于风险的安全测试（Risk-based security tests ）
滥用用例（Abuse cases ）
安全需求（Security requirements ）
安全操作（Security operations ）
1.代码审查代码审查的目标是找到bug，架构风险分析的目标是找到缺陷。在很多情况下，这两个主要的接触点的执行顺序能够交换。
静态分析工具：
静态分析工具在代码中查找固定的模式或规则集合。
静态分析工具的输出仍然需要人为判断。
错报（false negatives）问题，程序中含有bug但工具没有报告。
误报(false positives)问题，工具报出的bugs程序中不存在。
动态分析工具：
执行程序、错误注入。
二进制分析：
反汇编和反编译都是攻击者最常用的黑客工具。
例如：Fortify Source Code Analysis Suite
2.架构风险分析架构风险分析的主要活动是从适当的高度建立一个目标系统的视图，避免“只见树林不见森林”，提倡一页纸的总览, “forest-level”视图。
例如：
在forest-level视图中主要分析以下几个方面：
威胁（谁可能攻击系统）、每一层环境中的风险、每个组件和数据流中可能存在的漏洞、技术风险可能造成的商业破坏、风险被实现的可能性、任何在每一层能够实现的可行对策、考虑整个系统范围内的可用保护机制。
3.渗透测试渗透测试，针对系统威胁尝试对系统进行渗透，包括：积极（正向）测试，验证软件正常执行了规定的任务；消极（负向）测试，安全测试人员必须深入研究安全风险（可能由滥用用例和体系风险驱动）以便确定系统在攻击之下如何反应。
测试工具：
错误注入工具。
其他工具:Fortify Software, CANVAS。
攻击者的工具包。
4.基于风险的安全测试此测试旨在揭示可能的软件风险和潜在攻击。
实施人员：
使用传统方式的标准测试组织可以执行功能安全测试；
基于风险的安全测试更依赖于专门技术和经验，而不是测试经验和安全经验；
教会测试专业人员学会在测试时如何象一个攻击者一样思考。
实施方式：
有源码：白盒测试，静态分析－－发现程序中的错误；
根据基于对软件体系深入的理解而进行的风险分析的结论，进行白盒测试；
无源码：黑盒测试，运行程序－－恶意输入。
5.滥用用例滥用用例指软件开发人员需要在正常特性之外思考软件系统的固有特性，如可靠性、安全和性能。
实施方式：
对系统的异常行为必须事先有所预期；
象攻击者一样思考你的系统，利用“反需求”尝试出错点。
例如：你的系统有一个使用加密保护通过序列化将关键数据写到磁盘上的安全需求，与这个需求对应的反需求就是要确定当缺少加密的时候会发什么情况。
6.安全需求设计系统的安全需求。
7.安全操作注重配置管理的安全性，由于配置的改变是必然的，因此我们在开发和维护过程中需要控制配置的改变，建立开发活动（程序、数据、文档）的快照，验证配置的任何修改，防止恶意修改配置。
常用工具：
Rational ClearCase，MS Visual SourceSafe等。
实用的安全Web开发“药方”规划体系结构和设计解决方案时：识别和评估威胁：使用威胁建模系统地识别威胁，而不是以任意的方式应用安全性。接着，根据攻击或安全损害产生的风险和可能造成的潜在损失，对威胁进行评价。这样就可以适当的次序对威胁进行处理。
创建安全的设计：使用尝试或检验过的设计原则。集中处理关键区域，在这些区域，方法正确是必须的，而且经常会出现错误。这里将它们称为应用程序缺陷类别。其中包括输入验证、身份验证、授权、配置管理、敏感数据保护、会话管理、密码系统、参数处理、异常管理和审核与日志记录各项。要特别注意部署问题，包括拓扑、网络基础设施、安全策略和步骤。
执行体系结构和设计复查：应用程序设计的复查与目标部署环境和相关的安全策略有关。需要考虑底层基础设施层安全性（包括边界网络、防火墙、远程应用程序服务器等）带来的限制。使用应用程序缺陷类别帮助我们对应用程序进行分类，并分析适合于每个领域的方法。
进行应用开发时：开发工具的安全性：充分了解开发工具（包括语言、虚拟机、IDE环境、引用的第三方工具包），最好选择开放源代码的开发工具，这样以便仔细审核其安全性。检查开发工具是否提供了用户和代码安全模型，是否允许对用户和代码可以执行的操作进行限制。如果开发中涉及公开对称和不对称的加密与解密、散列、随机数生成、数字签名支持等算法，最好选用可靠的公开算法，避免自己炮制算法。
编写安全代码库：对程序集进行数字签名，使它们不能随意改动。通过遵守面向对象设计原理，减小程序集受攻击面，然后使用代码访问安全性，进一步限制哪些代码可以调用您的代码。使用结构化的异常处理方法防止敏感信息蔓延到当前信任边界之外，并开发更加可靠的代码。避免常规问题，特别是输入文件名和 URL 的问题。
安全地处理异常：不要显示内部系统或应用程序的详细信息，如堆栈跟踪、SQL 语句片断等。确保这类信息不被允许蔓延到最终用户或当前信任边界以外。在异常事件中安全地“失败”，确保应用程序拒绝非法访问，而且没有停留在不安全的状态下。不记录敏感或私有数据，如密码，以免造成危害。在记录或报告异常时，如果用户的输入包括在异常消息中，对其进行验证或清理。例如，如果返回一个HTML错误消息，那么应该对输出进行编码，以避免脚本注入。
执行第三方代码的安全复查：使用分析工具分析二进制程序集，确保它们符合安全设计准则，并修复分析工具识别出的所有安全缺陷。复查具体的应用程序元素，包括 Web 页面和控件、数据访问代码、Web 服务、服务组件等。要特别注意 SQL 注入和跨站点脚本编写缺陷。
保证开发人员工作站的安全性：使用一套方法保证工作站的安全性。保证帐户、协议、端口、服务、共享、文件与目 录和注册表的安全。最重要的是，保持工作站具有当前最新的补丁与更新。例如如果在 Microsoft Windows_ XP 或 Windows 2000 上运行 Internet 信息服务 (IIS)，则运行IISLockdown。IISLockdown 应用安全的IIS配置，并安装URLScan Internet 安全应用程序编程接口 (ISAPI) 筛选器，该筛选器用于检测和拒绝潜在的恶意 HTTP 请求。
编写具有最低权限的代码：可以限制代码能够执行的操作，这与运行该代码所使用的帐户无关。通过配置策略或编写代码，可以使用代码访问安全性控制来限制代码允许被访问的资源和操作。如果代码不需要访问某种资源或执行某种敏感操作，可以安全性配置/控制来确保代码不会被授予这种权限。
防止SQL注入：使用数据访问的参数化存储过程。使用参数要确保输入值的类型和长度都 得到检查。将参数视作安全文本值和数据库内的不可执行代码。如果不能使用存储过程，也可以使用带有参数的SQL语句。但不要通过连接SQL命令和输入值来构建 SQL 语句。还要确保应用程序使用具有最低权限的数据库登录，以限制它在数据库中的功能。
防止跨站点脚本编写：对输入类型、长度、格式和范围进行验证，并对输出进行编码。如果输出包括输入（包括 Web 输入），则对输出进行编码。例如，对窗体字段、查询字符串参数、cookie等进行编码，以及对从无法确定其数据是安全的数据库（特别是共享数据库）中读取的输入进行编码。对需要以HTML返回客户端的自由格式的输入字段，对输出进行编码，然后选择性地清除在许可元素（如用于格式化的 <b> 或 标记）上的编码。
管理机密：最好寻找避免存储机密的替代方法。如果必须存储它们，则不要在源代码或配置文件中以明文的方式存储。
安全地调用代码接口：特别注意传递给接口和接口返回的参数，防止潜在的缓冲区溢出。验证输入和输出字符串参数的长度，检查数组边界，并特别小心文件路径的长度。
执行安全的输入验证：对输入进行限制、拒绝和清理，因为验证已知有效类型、模式和范围的数据要比通过查找已知错误字符来 验证数据容易得多。验证数据的类型、长度、格式和范围。对字符串输入，请使用正则表达式。有时候可能需要对输入进行清理。一个例子是在对数据编码后清理编码元数据，以保证其安全性。
保证页面访问身份验证的安全性：安全地划分Web站点，隔离匿名用户可以访问的公共可访问页面和需要身份验证访问的限制性页面。使用安全套接字层 (SSL) 来保护窗体身份验证凭据和窗体身份验证 cookie。限制会话生存时间和确保身份验证 cookie 只在 HTTPS 上传输。对身份验证 cookie 加密，不要在客户端计算机上保留它，也不要将其用于个性化目的；对个性化使用单独的 cookie。
管理和维护系统时：实现补丁管理：针对Microsoft平台，那么可以使用 Microsoft Baseline Security Analyzer (MBSA) 检查当前安装可能漏掉的补丁和更新。定期运行该操作，保持服务器当前安装有最新的补丁和更新。在应用补丁前，对服务器数据进行备份；在将补丁安装在生产服务器上之前，先在测试服务器上进行测试。还要使用 Microsoft 提供的安全通知服务，并订阅通过电子邮件接收安全布告。针对Unix/Linux平台，可以 订阅有关漏洞及补丁的邮件列表，定期使用工具，检查服务器上安装的补丁是否与Unix/Linux厂商发布的最新补丁列表相一致。
保证Web服务器的安全性：针对Microsoft平台上运行的IIS服务，可以使用IISLockdown应用安全的IIS配置，并安装URLScan Internet 安全应用程序编程接口 (ISAPI) 筛选器，该筛选器用于检测和拒绝潜在的恶意 HTTP 请求。针对Unix/Linux平台上运行的Apache服务，可以采用选择性访问控制（DAC）和强制性访问控制（MAC）的安全策略，或者安装安全相关的modules。针对WebService常用的协议（如soap），可以使用 XML 加密以确保敏感数据保持其私有性。使用数字签名保证消息的完整性，尤其重要的数据应使用SSL加密。最重要的是，保持服务器安装了当前最新的补丁和更新，并使其按照最小权限运行。
保证数据库服务器的安全性：应用一种常见方法评估帐户、协议、端口、服务、共享、文件与目录和注册表。还要评估 SQL Server的安全设置，如身份验证模式和审核配置。评估身份验证方法和 SQL Server登录、用户与角色的使用。确保安装最新的服务包，定期监测操作系统和 SQL Server 补丁与更新。
防止拒绝服务攻击：确保加强了服务器上的 TCP/IP 堆栈配置，以应对如 SYN flood 这样的攻击。对web服务的配置做适当的修改以限制接受的 POST 请求的规模，并对请求的执行时间做出限制。
限制文件 I/O：可以配置代码访问安全策略，以确保限制单个程序集或整个 Web 应用程序只能访问文件系统。例如，通过配置运行在媒体信任级上的 Web 应用程序，可以防止应用程序访问其虚拟目录层次结构以外的文件。同时，通过为特定程序集授予受限的文件 I/O 权限，可以精确控制哪些文件可以被访问以及应该如何访问它们。
执行远程管理：针对Microsoft平台，其终端服务提供了一种专用的协议 (RDP)。它支持身份验证，并可以提供加密。如果需要文件传输工具，可以从 Windows 2000 Server 资源包中安装文件复制实用工具。建议不要使用 IIS Web 管理，如果运行 IISLockdown 该选项将被清除。应该考虑提供一个加密的通信通道，并使用 IPSec 限制可以用于远程管理您的服务器的计算机。还应该限制管理帐户的数量。针对Unix/Linux平台，建议采用SSH进行远程管理，文件传输使用SFTP。