《Web安全开发编程规范》由会员分享，可在线阅读，更多相关《Web安全开发编程规范（26页珍藏版）》请在金锄头文库上搜索。
1、Web安全开发编程规范XXX2016.12安全编码规范安全编码规范输输入输输出安全规规范文件系统规统规 范数据库规库规 范随机数网络络系统规统规 范WEB技术规术规 范安全编码规范31.需要集中处处理输输入验证验证 具体要求如下： 要求所有的输入使用一致的输入验证； 如果每个模块各自独立实现自己的输入验证，将会很难建立一个统一的输入验 证策略。 需要对输入验证进 行统一的升级和修改；这样如果在输入验证逻辑 里发现问题时 就可以比较方便的修改。 要求进行统一的失败控制； 如果一个集中处理输入验证框架收不到不知道如何处理的输入，很容易就拒绝掉 该输入；如果没有采取集中输入验证，开发者很容易忘记进行
2、输入验证。输入输出安全规范2.必须验证须验证 所有的输输入信息 必须对输 入的信息进行验证。程序默认情况下就要对输入的信息进行验证，不 能通过验证 的数据将会被拒绝，以确保在输入验证之前，输入的数据不能进入程 序代码中被执行。3.使用可信任边边界 当数据要从不可信的区域到可信区域的时候，需要使用验证逻辑进 行判断。具体 要求如下：要求在程序中定义清晰的可信边界。4在一些代码中使用的保存可信数据的数据结构，不能被用来在其它代码中存储不可 信数据。使数据穿越可欣边界的次数将到最低。 当程序混淆了可信和不可信的界限时会导致安全边界发生问题，把可信和不可信数 据混合在一个数据结构里最容易导致这种错误的
3、出现。 需要维护一个可信的边界。 不可信数据应该单 独存放不可信数据的数据结构内，在经过验证 之后才被放在可 信区域。 如果输入的数据在处理前通过一些用户的交互发生了改变，可信边界就会遇到一定 的问题，因为它很可能在所有数据进入之前不能做出完全的输入验证。4.必须验证输须验证输 入数据的长长度 具体要求如下： 对输入长度进行检测。 验证的时候应该检查输 入的最小和最大长度。如果对最大输入长度进行限制，攻 击者就很难对系统的其它弱点进行攻击。而对最短长度的检测可以使攻击者无法 忽略强制要求输入的域，同时也无法输入与预期不符的数据。 输入验证可以根据被验证程序的上下文进行更深入的检测。 如果程序需
4、要验证一个输入域，验证逻辑对该 域的合法值限定得越详细，验证逻 辑就能越好地工作。输入输出安全规范55.检测检测 整数输输入的边边界值值 必须检测 整数输入的边界值，否则程序对一个未知大小的值进行运算，得出的结 果可能不符合为其分配的地址。这种情况下，结果会被误识别 ，产生明显的错误 ，从而导致整数溢出风险。 在C/C+中整数溢出常常是缓冲区溢出攻击的一部分，虽然JAVA不会产生缓冲区 溢出，但是在JAVA里的整数溢出仍会造成一定的问题。6.不能接受验证验证 失败败的数据 不允许试图 修复一个未能通过输入验证的请求，必须直接拒绝掉。 通过设置默认值来保存一个丢失的输入，处理密码域时自动剪裁掉超
5、过最大长度 的输入，替换掉在输入框输入的JavaScript字符等行为是很危险的，输入验证本 身就很复杂，如果和自动错误 恢复的代码混合在一起的话，将会造成更大的复杂 性，自动错误 恢复代码很可能改变请求的含义或者截断验证逻辑 。7.验证验证 HTTP请请求中所有内容 要求对每一个HTTP 请求都进行完整的检查。 因为攻击者可以在提供给他们的Web页面里输入任何内容，他们可以完全脱离浏 览器和浏览器的一切验证，修改Cookie、隐藏区域、name 与value 对应关系，他 们可以为了“错误”的目的在“错误”的时间按“错误”的顺序提交URL请求。输入输出安全规范68.校验验所有来自命令行、环环
6、境以及配置文件的输输入 软件开发者不能 相信来自命令行、环境以及配置文件的输入。要求对来自命令 行、系统属性，环境变量以及配置文件的输入都进行校验来保证它们是一致的和 健全的。9.控制日志的写入 防止攻击者控制写进日志文件的信息，否则就可以在输入中混入伪造的日志条目 来伪造系统事件。更严重的是，如果负责进 行日志分析的代码存在漏洞，特定的 有恶意的输入很可能触发该漏洞，并引发更加严重的危害。10.要求使用最严严格的形式进进行输输入验证验证 具体要求如下： 要求在一定程度上间接的验证用户输入的信息。如，创建一个 用户输入的合法取 值区间，并只允许用户输入在这个区间内的数据。 不允许用户输入的数据
7、被直接用到程序的逻辑中。 创建一个白名单，白名单中存储了允许输入的内容的一套字符串。有效的输入是 由白名单中的特征字组成的。如果一个应用程序中的输入值或者字母在特定环境 中代表了新的含义，验证方法必须被升级来适应这些变化。否则，其会被作为非 法输入所拒绝。 不要使用黑名单技术。因为黑名单技术的目标是拒绝那些不安全的字母或字符串 ，任何不安全字符串的列表一般都是不完全的并且会过期。输入输出安全规范711.防止元字符攻击击 不允许输入那些具有特定含义的字符。在具体环境中，这个问题和其解决方案在 不同的语言环境中是有很大差别的。 所有类似脚本语言以及标记语 言之类的强调易用性与交互性的技术都有一个共
8、性 ，即可以接受可变的控制结构与数据。这个通用的问题在很多系统的都有出现， 在一些系统中的有比较显著特点的问题如下： SQL： SQL注入 HTML： 跨站脚本 文件系统：资源注入 命令shells： 进程控制要求正常的输入验证过 程捕获通用的错误并提供易于理解的输入验证反馈，而以 安全为目标的输入验证过 程则只针对于那些不正常的输入。输入输出安全规范8WEB 技术规范开发安全的Web应用程序是很有挑战性的，主要原因如下： 由于用户可以很容易的访问应 用程序，恶意用户也可以这样做。 HTTP 不是为应用设计的，自然更不是为安全的应用设计的。HTTP 的安全问 题与标准C库中的字符串函数带来的缓
9、冲区溢出问题一样麻烦。程序员需要通 过自己的方法来确认应用是安全的。 应用不只需要防护恶意用户，还需要帮助正常用户防御恶意用户。换句话说， 恶意用户希望通过应用作为其攻击的跳板。 本章覆盖了创建安全Web应用最重要的方面，包括：会话，SSL，认证等方 面。 1.使用POST 不能使用GET 禁止使用Get方法可以防止很多跨站脚本攻击漏洞，这样可以使攻击者无法向用 户发送含有恶意Get参数的URL。“禁止使用Get”建议修改为“限制使用Get”，对 于通过Get方式进行数据提交，必须进行验证以确保数据安全。2.使用SSL进进行通信 要求合理的使用SSL，它能对嗅探攻击和中间人攻击做出有效的防御，
10、同时还 可以为主机和客户机提供可信的验证。 不允许SSL是可选的方案。一个安全的程序不能在使用443端口（SSL通信端口 ）的同时也接受80端口（一般的HTTP服务端口）请求，不允许用户选择 安全 级别。93.假设浏览设浏览 器已被监监控 要求在验证之前不相信来自客户端的任何数据，包括那些不常被客户修改的值（ 如cookies, 被隐藏的域）。因为Web程序总会接受到来自攻击者的请求，对客户 习惯做出的任何假设都有可能会被用来对程序发起攻击。4.需要在服务务端进进行安全验证验证 要求在服务器端进行安全验证。 因为攻击者很容易就可以绕过用户设定的那些请求页面和浏览器，直接与应用 服务器通信，这就
11、意味着攻击者可以绕过在客户端所做的任何设置，如 JavaScript 验证逻辑 。JavaScript可以帮助合法的用户对不正常的输入信息进行 检测，但是不能确保服务器接收到数据的安全性。5.不能依赖赖Request到达的顺顺序 不能依赖Request到达的顺序。 因为攻击者可以随意控制request 到达的顺序来适合自己的需要。例 如，如果程序通过不同页面来搜集 信息，在较早的表单里验证了信 息，而在修改信息的表单则没有 进行验证，那么攻击这就可以利 用后者来绕过输 入验证。6.要求在恶恶意环环境中保护浏览护浏览 器 不能让出现问题 的浏览器成为攻击者可以 利用的工具，来攻击存在漏洞的客户端
12、。 这一问题可以理解为输入验证的问题，但 是从深度防御的角度考虑，它也是一个输 入编码（加密）的问题。例如，可以通过 对HTTP请求进行校验来防御来自外部的跨 站脚本攻击，如果对HTTP应答都进行了 编码，这样就可以防御来自外部和内部的 跨站脚本。WEB 技术规范107.要求创创建默认认的错误页错误页 面 要求为HTTP错误创 建一个默认的错误页 面，丢弃掉所有的异常，来防止攻击 者从应用程序的默认出错页面中得到系统信息。8.要求使用通用错误错误 消息 要求构造错误提示信息来防止诸如用户id ,网络，应用程序以及服务器环境的细 节等重要的敏感信息的泄漏。包括： 不区分错误的用户名和错误的密码；
13、 在返回的报告中不能包含主机信息、网络信DNS信息、软件版本信息、错误代 码或者其它发生的错误的详细信息； 不允许把错误的细节放在错误页 面的注释里。9.必须须使用强的会话话ID 会话id 长度不能低于64位，建议使用128位长度的会话id。 要求在确定session 的id的长度以及生成id的随机种子之前，不相信web程序的容 器。 因为会话id太短很容易被暴力猜解。如果攻击者猜到授权用户的会话id就可以接 管用户的会话。 WEB 技术规范1111.必须须在会话终话终 止时时清空数据 不允许会话数据在会话终止后继续存在，否则该数据会被攻击者利用。10.必须须保护护Cookie 要求在建立Se
14、ssion时用户以SSL方式连接，并且将该会话的安全标识设 置为 cookie 只能通过安全连接进行传输。 不能只依赖HttpOnly cookie带来的任何安全保障，因为其只限于在IE下使用， 攻击者也可以很方便的窃取到它。不相信来源于网络络的一切数据 要求对来源于网络的一切数据进行一定的校验来保证数据包的大小和内容都符 合预期要求。 这些威胁体现网络通信的一切行为中，例如：从DNS返回的信息可能被假冒； 数据包中非负荷数据也可能被伪造；攻击者可以专门构造数据包用语进行某些 攻击等等。网络系统规范WEB 技术规范12文件系统规范1.必须须使用文件系统访问统访问 控制 具体要求如下： 要求文件
15、被指定的用户访问 ，并且该用户的权限被限制为最小权限。 当应用程序使用被其控制的已存在文件时，必须首先验证是否存在防止文件被篡 改的许可权限。 不能将许可权限的管理交给系统管理员一个人处理 。 为另外安全的使用临时文件，要求在程序初始化时创建一个只能被该程序读写的 文件夹。 不能将该文件夹放在用户可访问到的地方，并将所有的临时文件都放在其中，这 样就可以防止攻击者猜测被使用的临时文件的名字，提前创建该文件来进行内容 操纵或者拒绝服务攻击的风险。2.注意文件访问竞访问竞 争条件 确保在程序对某文件进行一系列操作之后，不再能被替换或者修改。 在C语言中，避免使用操作文件名的函数，应该首先打开该文件
16、获得文件句柄， 然后通过使用操作文件句柄的函数来进行操作，因为不能够保证在函数调用域之 外的空间上，它指向的仍是硬盘上同一文件。 当用户可以访问本地文件时，不要Java使用 来实现具有特定权限的程序。因为 在Jaba中，虚拟机对文件的操作是基于路径的，而不是操作系统的文件句柄的， 所以文件访问竞 争条件是不可避免的。133.不相信文件名或文件内容 要求对来自文件系统的所有值都进行合适的输入验证，因为文件的大小和名字 很难得到保证。 例如，在C/C+中，开发者经常会错误地认为Windows系统的变量MAX-PATH 以及Unix/Linux系统的变量PATH-MAX可以限制在文件系统中出现的最大路径的 长度。而这些变量的实际作用是限制传递给 某些操作的最大路径，而在系统中 是可以存在更大路径的。在C/C+中，很经常出现过长 的文件名导致的缓冲区 溢出，除去这种过长路径名的风险，根据操作系统的不同，某些操作系统中正 常的文件名还可能包含在其他系统中作为关键字的字符。 数据库规范1.必须须使用参数化的SQL语语句 具体要求如下： 要求开发者在构造SQL请求时
