《应用系统安全开发技术规范V3.docx》由会员分享，可在线阅读，更多相关《应用系统安全开发技术规范V3.docx（54页珍藏版）》请在课桌文档上搜索。
1、应用系统安全开发技术规范V3应用系统安全开发技术规范（版本号VI.3）朗新科技股份有限公司二。一五年十二月更换履历版本号修改编号更换时间更换的图表与章节号更换简要描述更换人批准人0.52013-11-24初稿施伟施伟1.02015-11-19修改宋月欣陈志明1.12015-11-30修改宋月欣陈志明1.22015-12-3修改宋月欣施伟1.32015-12-3修改施伟注：更换人除形成初稿，以后每次修改在未批准确认前均需使用修订的方式进行修改。目录1背景与目标12 安全编程概念12.1 安全编程12.2 结构化编程22.3 脆弱性22.4 可信计算22.5 安全可信模块32.6 不可信任模块32
2、.7 敏感信息32.8 特权32.9 信息隐藏32.10 中间件42.11 死锁42.12 可信边界42.13 元字符42.14 参数化查询42.15 UNlXJAlL环境42.16 临时文件42.17 信息焙52.18 SSL52.19 TLS52.22 Cookie53 安全编程原则53.1 统一的安全规范53.2 模块划分63.3 最小化功能63.4 最小化特权63.5 对多任务、多进程加以关注63.6 界面输出最小化73.7 使代码简单、最小化与易于修改73.8 避免高危的服务、协议73.9 数据与代码分离73.10 关键数据传输保护73.11 禁止给予用户进程特权73.12 使用适当
3、的数据类型83.13 使用通过验证的安全代码83.14 使用应用中间件83.15 设计错误、特殊处理机制83.16 提供备份机制83.17 检查传递变量的合法性83.18 检查所有函数返回代码83.19 修改面向用户的操作的反馈缺省描述93.20 文件操作的要求93.21 其他编码原则94 应用安全分析104.1 安全需求104.2 安全威胁104.2.1 Web安全漏洞104.2.2 拒绝服务攻击114.2.3 嗅探攻击114.2.4 中间人攻击124.3 安全约束125安全编程要求125.1 输入处理125.1.1 建立可信边界125.1.2 验证各类来源的输入135.1.3 保证所有的输
4、入信息是被验证过的145.1.4 对输入内容进行规范化处理后再进行验证145.1.5 选择合适的数据验证方式145.1.6 防范元字符攻击145.1.7 拒绝验证失败的数据145.1.8 在服务端进行验证155.1.9 建立统一的输入验证接口155.1.10 操纵写入日志的信息155.1.11 从服务器端提取关键参数155.2 输出处理155.2.1 限制返回给客户的信息155.2.2 建立错误信息保护机制155.3 数据库访问155.3.1 合理分配数据库访问权限155.3.2 合理存放数据库连接帐号与密码信息165.3.3 使用参数化请求方式165.3.4 对SQL语句中来自于不可信区域的
5、输入参数进行验证175.3.5 对数据库操作的返回数据进行验证175.3.6 分次提取数据175.3.7 通过row（行）级别的访问操纵来使用数据库175.3.8 确保数据库资源被释放175.4 文件操作185.4.1 对上传文件进行限制185.4.2 把文件名与文件内容作为不可信的输入对待185.4.3 安全的使用文件名185.4.4 使用文件系统访问操纵185.4.5 注意文件访问竞争条件185.4.6 安全使用临时文件195.4.7 确保文件系统资源被释放196安全特征196.1 关注应用的对象重用196.2 用户访问操纵信息的机密性196.3 不要在客户端存放敏感数据196.4 避免内
6、存溢出206.5 可配置数据保护206.6 禁止在源代码中写入口令206.7 随机数206.8 使用可信的密码算法216.9 特殊管理217应用安全设计规范227.1 应用安全规划227.2 数据安全等级划分227.3 数据库规划227.3.1 用户权限227.3.2 数据源设计227.3.3 外部系统访问227.4 角色划分237.5 URL规划237.6 程序文件目录规划237.6.1 数据及程序分离237.6.2 静态程序资源237.6.3 程序文件分类237.7 Cookie237.8 文件安全247.8.1 文件存储247.9.3组件配置247.10 WebService247.11
7、 RESTfulWebService257.12 应用安全关注点267.13 应用安全限制应对方案277.13.1 外网隔离277.13.2 外网文件操作277.13.3 正向与反向隔离装置（国网系统）278应用安全开发规范288.1 Java及Web安全编程规范288.1.1 不信任未知288.1.2 数据层开发288.1.3 会话管理308.1.4 Cookie318.1.5 输入验证318.1.6 输入文件名的验证328.1.7 输出处理328.1.8 敏感信息处理348.1.9 特殊信息处理348.1.10 特殊页面跳转348.1.11 文件操作348.1.12 资源释放358.1.1
8、3 内存操纵358.1.14 外部程序调用漏洞368.1.15 整数溢出368.2 C+安全编程规范378.2.1 不信任未知378.2.2 免缓存区溢出378.2.3 免缓整数溢出408.2.4 域名合法性检查428.2.5 检查返回值438.2.6 产生随机数448.2.7 验证输入文件名458.2.8 类设计注意事项458.2.9 外部程序调用漏洞478.2.10 临时文件处理471背景与目标在Internet大众化及Web技术飞速演变的今天，Web安全所面临的挑战日益严峻。黑客攻击技术越来越成熟与大众化，针对Web的攻击与破坏不断增长，Web安全风险达到了前所未有的高度。许多程序员不明
9、白如何开发安全的应用程序，开发出来的Web应用存在较多的安全漏洞，这些安全漏洞一旦被黑客利用将导致严重甚至是灾难性的后果。这并非危言耸听，类似的网上事故举不胜举，公司的Web产品也曾多次遭黑客攻击，甚至有黑客利用公司Web产品的漏洞敲诈运营商，造成极其恶劣的影响。本规范为解决Web应用系统安全问题，对要紧的应用安全问题进行分析，并有针对性的从设计及开发规范、开发管理、安全组件框架、安全测试方面提供整体的安全解决方案。使本组织能以标准的、规范的方式设计与编码。通过建立编码规范，以使每个开发人员养成良好的编码风格与习惯；并以此形成开发小组编码约定，提高程序的可靠性、可读性、可修改性、可保护性与一致
10、性等，增进团队间的交流，并保证软件产品的质量。2安全编程概念2.1 安全编程安全编程是指开发人员首先需要具备一定的安全知识，然后识别数据在流转（输入、处理与输出）过程中可能面对的威胁，对这些威胁进行分析得出其利用的漏洞，通过合理地编写代码消除这些漏洞，降低软件面临的风险。本规范对开发人员的编码提出统一的安全要求，要紧涉及输入处理、输出处理、数据库访问、文件操作、特殊管理等方面，如下图：输入处理部分能指导开发者避免用户的不良输入；输出处理能指导开发者对输出内容进行过滤；数据库访问、文件操作部分则能指导开发者进行数据库查询,写入文件等操作时进行防护；而特殊管理、敏感数据保护、对象重用等技术则指导开
11、发者改进软件的自身缺陷。WEB开发规范部分则指导用户在WEB系统（B/S架构应用）的研发方面时如何增加对应用软件的保护。2.2 结构化编程结构化编程，一种编程典范。它使用子程序、程式码区块、for循环与WhiIe循环等结构，来取代传统的goto。希望借此来改善计算机程序的明晰性、品质与开发时间，同时避免写出面条式代码。2.3 脆弱性脆弱性指计算机系统安全方面的缺陷，使得系统或者其应用数据的保密性、完整性、可用性、访问操纵、监测机制等面临威胁。2.4 可信计算可信计算的行为会更全面地遵循设计，而执行设计者与软件编写者所禁止的行为的概率很低。2.5 安全可信模块审计与访问操纵模块是唯一的安全可信模
12、块。2.6 不可信任模块除审计与访问操纵模块外其它所有模块均为不可信模块。2.7 敏感信息系统的敏感信息包含用户身份信息、认证信息、授权信息、交易过程中的私密或者隐私信息、其它的敏感信息。2.8 特权特权只是同意去做并不是每个人都能够做的情况。2.9 信息隐藏信息隐藏指在设计与确定模块时，使得一个模块内包含的特定信息（过程或者数据），关于不需要这些信息的其他模块来说，是不可访问的。信息隐藏基本原理框图：祓体依息源:I我体豺象CI*I-1一秘密信息信息嵌入算法，一X*不安全信道M信息提取算法秘密信息MXBi一伪装对象Cl1-：i：:伪装密钥k，：2.10 中间件2.11 死锁死锁是操作系统或者软
13、件运行的一种状态：在多任务系统下，当一个或者多个进程等待系统资源，而资源又被进程本身或者其它进程占用时，就形成了死锁。2.12 可信边界可信边界能够被认为是在程序中划定的一条分隔线，一边的数据是不可信的而另一边则是可信的。当数据要从不可信的一侧到可信一侧的时候，需要使用验证逻辑进行推断。2.13 元字符元字符就是在编程语言中具有特定含义的字符或者者字符串。比如在SQL查询中，单引号(D是危险的字符；在文件系统路径中两个点号(.)是危险的字符；在命令shell中，分号(；)与双&(&)符号同样是危险的字符，而换行符(n)对日志文件很关键。2.14 参数化查询参数化查询(ParameteriZed
14、QUery或者ParameterizedStatement)是指在设计与数据库链接并访问数据时，在需要填入数值或者数据的地方，使用参数(Parameter)来给值，这个方法目前已被视为最有效可预防SQL注入攻击(SQLInjection)的攻击手法的防御方式。2.15 UNIXJAIL环境一个被改变根目录的程序不能够访问与命名在被改变根目录外的文件，那个根目录叫做“chroot监狱(chrootjail,chrtprison),2.16 临时文件创建临时文件的程序会在完成时将其删除。2.17 信息燃信息燧指信息的不确定性,一则高信息度的信息燧是很低的,低信息度的墙则高。2.18 SSL安全套接
15、层（SeCUreSocketsLayer,SSL）,一种安全协议,是网景公司（NetSC叩e）在推出Web浏览器首版的同时提出的，目的是为网络通信提供安全及数据完整性。SSL在传输层对网络连接进行加密。2.19 TLS在计算机科学领域来说，特别是在网络领域，会话（SeSSiOn）是一种持久网络协议，在用户（或者用户代理）端与服务器端之间创建关联，从而起到交换数据包的作用机制，SeSSion在网络协议（比如telnet或者FTP）中是非常重要的部分。当客户端在多个服务器调取数据时，保持会话状态的一致性是需要注意的，客户端需用同时保持与某一个主机的连接，或者者多个服务器端需要共享一个储存会话信息的
16、文件系统或者者数据库。否则，当用户在一个新的而不是一开始储存会话信息的主机上提交访问请求的时候，主机会由于无法获知原先主机的会话的访问状态而产生问题。2.20 CookieCoOkie（复数形态COOkies）,中文名称之小型文本文件或者小甜饼，指某些网站为了辨别用户身份而储存在用户本地终端（ClientSide）上的数据（通常通过加密）。定义于RFC2109o为网景公司的前雇员LOUMomUHi在1993年3月所发明。3安全编程原则1.1 统一的安全规范每个软件项目在设计阶段都应明确在项目实施过程中项目组应遵循的统一规范，具体包含：1 .命名规则、组件使用规范、特殊处理规范、日志处理规范、工
17、具使用要求、代码集成规范。2 .针对本规范提出的要紧代码脆弱性应进行相应的防范设计，具体内容应在软件概要设计中表达或者有单独的文档表达。1.2 模块划分1 .软件应该按照安全性划分模块，审计与访问操纵模块为安全可信模块，其它模块为不可信任模块。只有安全可信模块才能够执行安全操纵功能，其它的模块不能访问安全可信模块的安全信息、功能或者者权限。安全可信模块应该与其它模块分离，由经授权的内部专人进行管理。2 .只有安全可信模块，才能以高安全等级访问系统的敏感信息，关于其他模块限制其访问敏感信息。1.3 最小化功能根据“没有明确同意的就默认禁止”的原则，软件应只包含那些为达到某个目标而确实需要的功能，
18、不应包含只是在将来某个时间需要但需求说明书中没有的功能。软件在最小化功能建设方面应遵循如下原则：1 .只运行明确定义的功能。2 .系统调用只在确实需要的时候。3 .一次只执行一个任务。4 .只有在上一个任务完成后才开始下一个任务。5 .只在确实需要的时候访问数据。3.4 最小化特权1 .只为程序中需要特权的部分授与特权。2 .只授与部分绝对需要的具体特权。3 .将特权的有效时间或者者能够有效的时间限制到绝对最小。3.5 对多任务、多进程加以关注软件开发应尽量使用单任务的程序。假如软件需要使用多任务与多进程，应该认真分析研究多任务与多进程会不可能发生冲突，同步所有的进程与任务以避免冲突。同时作为
19、结构化的编程，每个原子化组件都要保证一个入口与一个出口。假如进程之间需要交互，则这些交互操作应同步。关于每一种可能的交互情况都要考虑有关的安全策略。3.6 界面输出最小化软件应保持用户界面只提供务必的功能，没有多余的、不必要的功能，确保用户不能通过用户界面直接访问数据或者者直接访问被保护对象。3.7 使代码简单、最小化与易于修改开发时应尽量使代码简单、最小化与易于修改。使用结构化的编程语言，尽量避免使用递归与Goto声明。使用简单的代码，清除不必要的功能，防止使用信息隐藏方式进行数据保护。3.8 避免高危的服务、协议软件应尽量避免使用不加保护的及已被证明存在安全漏洞的服务与通信协议传输文件，如
20、FTP、SMTPo3.9 数据与代码分离软件应该把数据与程序放置在不一致的目录中，这里的数据包含远程下载文件等。3.10 关键数据传输保护1 .软件在传输关键数据时，使用加密算法保证数据在通信过程不被破译，使用数字签名保证数据在传输过程中的一致性与不可否认性。有关的加密算法与签名技术等应符合国家有关法律法规要求。2 .信息隐藏是不可靠、效率低的做法，软件应该使用正确的安全保护措施，不要依靠隐藏进行数据保护。3.11 禁止给予用户进程特权用户进程的授权应使用最小授权法，关于软件的普通用户进程，禁止给予该类进程特权用户权限。特权用户类型包含:1 .超级用户。2 .直接操作数据库用户。3 .安全管理
21、用户。3.12 使用适当的数据类型应该小心使用数据类型，尽量使用占用内存较小的数据类型，如可用整型数据的不用实型，特别是在程序接口部分。比如，在一些编程语言中Signed与unsigned的数据类型是视为不一致的(如C或者者C+语言)。3.13 使用通过验证的安全代码使用通过验证的安全代码模块与外部源程序，防止潜在的安全风险。3.14 使用应用中间件中间件作为一种应用层架构，软件设计应尽可能使用中间件，中间件选型时应选择成熟的、业界主流的中间件产品。3.15 设计错误、特殊处理机制软件设计开发时应建立防止系统死锁的机制，特殊情况的处理与恢复机制，具体包含错误与特殊检测、数据回滚、安全错误通知、
22、错误与特殊记录、断点保护等。3.16 提供备份机制为保证运行数据的完整性与可用性，软件开发应设计有效的备份策略，根据业务与系统保护需要提供定期或者不定期、自动或者手动方式的备份机制。3.17 检查传递变量的合法性应检查所有传递给系统函数调用(SyStemCaHS)或者本地调用(NatiVeCanS)的变量的合法性。3.18 检查所有函数返回代码应检查所有函数调用返回代码(错误代码)，对每个期望的返回值设置相应的处理程序。3.19 修改面向用户的操作的反馈缺省描述应对面向用户的操作的反馈缺省描述进行必要的封装，删除有关后台系统或者其它敏感信息。3.20 文件操作的要求在需要进行文件操作时，应预先
23、设定目前工作路径（全路径名），使用全路径名表示文件的位置。3.21 其他编码原则1 .当一个进程对敏感对象（包含秘密信息或者包含不可更换信息）使用完后,应立即擦除对象的敏感信息，然后再删除对象。任何不需要使用的资源应及时释放。2 .确保所有用来指示数组下标的数据（或者指针）都指向了一个有效的数组元素。假如某个函数不能保证下标所指向元素的有效性，或者者根本不去检查边界时，不要使用该函数，应该寻找一个安全的函数，或者者自己重新编写一个或者者封装一个不安全的函数，加上必要的推断条件，使它安全。3 .当输入不可信任数据时，要在该数据的内容与格式上同时加以检查。关于整数，应该检查数据大小是否超出了能够表
24、示的范围；关于输入的字符串，要确保长度没有溢出，保证每一个字符都是有效的。4 .对经常使用的类似的SQL语句应使用绑定变量的方法，避免数据库执行类似SQL语句时重复解析、重复访问数据文件的行为。5 .程序编码结束后，应对代码进行优化，提高应用处理SQL的性能。6 .禁止使用通配符的方式进行数据的插入操作。7 .使用数据库作为系统间接口方式时，应建立独立的接口表，并按最小化特权原则进行授权。4应用安全分析4.1 安全需求系统安全本质上属于信任问题，要保证应用安全，就务必将解决各类操作过程中不可信问题。安全的几个基本要素为机密性、完整性、可用性、可审计性、不可抵赖性等方面的安全要求。机密性要求保护
25、数据内容不能泄露，加密是实现机密性的要求的常见手段。完整性要求保护数据内容是完整、没有被篡改的。可用性要求保护资源是可被按照需要访问。可审计性对出现的安全问题提供调查的根据与手段。不可抵赖性建立有效的责任机制，防止用户否认其行为。4.2 安全威胁4.2.1 Web安全漏洞根据结合国网系统安全检测项目常见安全问题及OWASP组织公布的安全漏洞，系统中存在的需要解决的安全风险如下:序号安全威胁产生环节1SQL注入编码2失效的身份认证及会话管理设计、编码3跨站脚本（XSS）编码4点击劫持（CliCkJaCking）编码4不安全的直接对象引用编码5安全配置错误配置实施6敏感信息泄露设计、编码7功能级访
26、问操纵缺失（失败的URL访问设计权限限制）8跨站请求伪造（CSRF）编码9使用含有已知漏洞的组件管理、设计10未验证的重定向与转发编码11传输层保护不足设计、编码12文件上传漏洞编码13不安全的加密存储设计、编码4.2.2拒绝服务攻击分布式拒绝服务攻击（英文：DistributedDenialofService,缩写：DDoS）亦称洪水攻击。顾名思义，即是利用网络上已被攻陷的电脑作为“僵尸”，向某一特定的目标电脑发动密集式的“拒绝服务”式攻击，用以把目标电脑的网络资源及系统资源耗尽，使之无法向真正正常请求的用户提供服务。黑客通过将一个个“丧尸”或者者称之“肉鸡”构成僵尸网络，就能够发动大规模D
27、DoS或者SYN洪水网络攻击，或者者将“丧尸”们组到一起进行带有利益的刷网站流量、EmaiI垃圾邮件群发，瘫痪预定目标受雇攻击竞争对手等商业活动。4.2.3 嗅探攻击利用计算机的网络接口截获目的地为其他计算机的数据报文的一种技术。它工作在网络的底层，把网络传输的全部数据记录下来.嗅探器能够帮助网络管理员查找网络漏洞与检测网络性能。嗅探器能够分析网络的流量，以便找出所关心的网络中潜在的问题。证明你的网络有嗅探器有两条经验：1 .网络通讯丢包率非常高：通过一些网管软件，能够看到信息包传送情况，最简单是ping命令。它会告诉你掉了百分之多少的包。假如你的网络结构正常，而又有20%30%数据包丢失以致
28、数据包无法顺畅的流到目的地。就有可能有人在监听，这是由于嗅探器拦截数据包导致的。2 .网络带宽出现反常：通过某些带宽操纵器，能够实时看到目前网络带宽的分布情况，假如某台机器长时间的占用了较大的带宽，这台机器就有可能在监听。应该也能够察觉出网络通讯速度的变化。4.2.4中间人攻击在密码学与计算机安全领域中，中间人攻击（Man-in-the-middleattack,通常缩写为MlTM）是指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全操纵。在中间人攻击中，攻击者能够拦截通讯双方的通话并插入新的内
29、容。在许多情况下这是很简单的（比如，在一个未加密的Wi-Fi无线接入点的同意范围内的中间人攻击者，能够将自己作为一个中间人插入这个网络）一个中间人攻击能成功的前提条件是攻击者能将自己伪装成每一个参与会话的终端，同时不被其他终端识破。中间人攻击是一个（缺乏）相互认证的攻击。大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。比如，SSL协议能够验证参与通讯的一方或者双方使用的证书是否是由权威的受信任的数字证书认证机构颁发，同时能执行双向身份认证。4.3安全约束序号限制1外网不同意部署数据库23外网访问内网务必通过强隔离装置，仅支持TNS协议（国网系统要求）4外网应用不同意直接访问内网
30、关键业务系统数据库5其它系统原则上都不同意直接连接营销系统数据库5安全编程要求5.1 输入处理5.1.1 建立可信边界需要在程序中定义清晰的可信边界。在一些代码中用于储存可信数据的数据结构，不能被用来在其它代码中存储不可信数据。使数据穿越可信边界的次数降到最低。当程序混淆了可信与不可信数据的界限时会导致安全边界发生问题，最容易导致这种错误的情况是把可信与不可信数据混合在一个数据结构里。如下例：usmame=request.getParameter(usrname);if(session.getAttribute(ATTR_USR)=null)session.setAttribute(ATTR_
31、USR,usrname);由于开发者都明白用户是不能直接访问session对象的，因此很容易信任来自session的所有信息，但是假如在该session中混合存储了可信与不可信的数据，就会违反完全可信边界的原则，带来安全隐患。假如不能很好的建立与保护可信边界，开发者将不可避免的混淆未被验证与已验证的数据，从而导致一些数据在未经验证时就被使用。假如输入的数据在处理前通过一些用户的交互发生了改变，可信边界就会遇到一定的问题，由于它很可能在所有数据进入之前不能做出完全的输入验证。在这种情况下，保护一个可信的边界就尤为重要，不可信数据应该单独存放在专门存放不可信数据的数据结构内，在通过验证之后才被放在
32、可信区域。这样在看一段代码时，就很容易识别数据是在可信边界的哪一侧。5.1.2 验证各类来源的输入不要将软件的安全性寄予在配置、使用与保护人员的敏锐懂得力、深刻洞察力或者良好意愿上，不仅需要验证用户输入，而且还要验证所有来自于软件之外的输入，这些输入应当包含下列内容，但并不仅仅局限于此：1 .不可信来源的文件。2 .第三方接口数据。3 .从数据库中检索出的数据。4 .对来自命令行、环境与配置文件的输入。5 .网络服务。6 .注册表值。7 .系统性能参数。8 .临时文件。5.1.3 保证所有的输入信息是被验证过的确保在输入验证之前，新输入的数据不能被添加到程序中（输入的数据不能进入程序代码中被执
33、行）。也就是说，程序默认情况下要对所有的输入信息进行验证，不能通过验证的数据将会被拒绝。5.1.4 对输入内容进行规范化处理后再进行验证当输入数据包含文件名、路径名、URL等数据时，应先对输入内容进行规范化处理后再进行验证，如文件路径、URL地址等数据，需要规范化为标准的格式后再进行验证。5.1.5 选择合适的数据验证方式应根据情况综合使用多种输入验证的方法，包含：1 .检查数据是否符合期望的类型。2 .检查数据是否符合期望的长度。3 .检查数值数据是否符合期望的数值范围，比如检测整数输入的最大值与最小值。4 .检查数据是否包含特殊字符，如：、”、%、（、）、&、+、W”等。5 .应使用正则表
34、达式进行白名单检查尽量避免使用黑名单法。1.1.6 防范元字符攻击攻击者通常会使用元字符对应用程序发起攻击。攻击者能够通过对同一个元字符采取多种编码方式或者者根据语言特征采取多种实现方式，因此应过滤输入数据中那些具有特定含义的字符，如单引号、双引号、圆括号、分号等。1.1.7 拒绝验证失败的数据应拒绝验证失败的输入数据，不试图对其进行修复（如处理密码域时自动剪裁掉超过最大长度的输入，替换掉在输入框输入的JaVaSCriPt字符等）。输入验证本身就很复杂，假如与自动错误恢复的代码混合在一起的话，将会造成更大的复杂性,自动错误恢复代码很可能改变请求的含义或者者截断验证逻辑。假如我们能够引导用户，使
35、他们提交的请求能够通过输入验证，就会比专注于自动错误恢复代码有效得多。在验证失败时，安全的做法是不试图修复一个未能通过输入验证的请求，直接拒绝掉。1.1.8 在服务端进行验证仅在客户端进行验证是不安全的，特别是在WEB应用系统中，客户端的验证大多使用脚本（如JaVaSCriPt）来完成，客户端的验证很容易被绕过，安全的做法是在客户端验证的同时，在服务器端也进行验证。1.1.9 建立统一的输入验证接口应建立统一的输入验证接口，为整个应用系统提供一致的验证方法，这样能够避免分散验证带来的代码管理混乱，同时能够减少遗漏。1.1.10 操纵写入日志的信息由于日志数据的价值，它也成为了攻击者的目标。假如
36、攻击者能够操纵写进日志文件的信息，他们就能够在输入中混入伪造的日志条目来伪造系统事件，更严重的是，假如负责进行日志分析的代码存在漏洞，特定的有恶意的输入数据很可能触发该漏洞，并引发更加严重的危害。假如日志数据中包含输入数据，应对输入数据进行验证，禁止攻击者能够写任意的数据到日志中。1.1.11 从服务器端提取关键参数需要获取参数时，应当从服务器端提取关键参数，禁止从客户端输入，比如产品价格、用户角色、鉴权标志等，假如关键参数同意从客户端输入提供，攻击者可通过伪造或者篡改输入数据造成程序关键逻辑错误。5.2 输出处理5.2.1 限制返回给客户的信息编码时应该限制返回给客户与业务处理无关的信息，禁
37、止把重点保护数据返回给不信任的用户，避免信息外泄。5.2.2 建立错误信息保护机制开发人员在编码时，禁止将全面错误信息直接反馈到客户端，全面错误信息中包含系统信息、文件与目录的绝对路径信息，应对错误信息进行规整与清理后再返回到客户端，建议只向客户端返回错误码，全面错误信息能够记录在后台服务器。5.3 数据库访问5.3.1 合理分配数据库访问权限应按照“最小化原则”为应用程序分配数据库访问权限。避免为应用程序分配过大或者不必要的数据库权限，禁止将数据库DBA权限分配给应用程序。5.3.2 合理存放数据库连接帐号与密码信息禁止在应用程序代码与配置文件明文存放数据库连接帐号与密码信息，建议对数据库连
38、接账户与密码信息加密后再储存在配置文件中。5.3.3 使用参数化请求方式使用参数化的SQL请求是防止SQL注入的有效方法。导致SQL注入漏洞的原因就是攻击者能够改变SQL请求的内容，攻击者提交的数据变成了SQL执行命令的一部分。在构造SQL请求时，开发者应当明白什么应该被翻译为数据而什么应该被翻译为命令的一部分。假如正确的使用参数化的SQL语句，就能够通过不同意数据指向改变的方法来防御几乎所有的SQL注入攻击。参数化的SQL语句通常是由SQL字符构造的，但是来自客户的数据是需要与一些绑定参数组合在一起的。也就是说，开发者使用这些绑定参数来准确的向数据库指出什么应该被当作数据，什么应该被当作命令
39、。当程序要执行该语句的时候，它就会告知数据库这些绑定参数的运行值，这样就避免了数据被认为是命令语句而被执行的错误。但是，如下是SQL请求中包含字符串拼接造成SQL注入漏洞的例子：这是一个javaweb应用程序，让用户在数据库中搜索一些信息，用户能够指定要搜寻的对象名称，并用下列代码执行这些查询：Stringitem=request.getParamater(item,);Stringq=,SELECT*FROMrecordsWHEREitem=,+item;PreparedStatementstmt=conn.prepareStatement(q);ResultSetresults=stmt.
40、execute();尽管本例程序使用了参数化的接口，但是它犯了一个很常见的错误：把用户的输入作为prepareStatement()的参数传入，假如同意用户操纵PreparedStatement的内容，参数化SQL提供的安全特性就会失去效果，很多SQL注入攻击的关键字也会被包含在之前构造的语句中。合理的使用参数化SQL代码如下:Stringitem=request.getParamater(item);Stringq=,SELECT*FROMrecordsWHEREilem=7n;PreparedStatementstmt=conn.prepareStatement(q);stmt.setSt
41、ring(I,item);ResultSetresults=stmt.execute();5.3.4 对SQL语句中来自于不可信区域的输入参数进行验证在一些复杂的情况会出现要求输入影响SQL语句结构的情况，譬如要求在where子句里增加一个动态约束，这时应对来自不可信区域的输入参数进行验证。5.3.5 对数据库操作的返回数据进行验证不应盲目信任来自数据库的数据，建议对来自数据库的数据进行验证，确保其格式正确且能够安全的使用：1 .检查SQL请求的返回记录数，SQL请求的预期结果为单值数据，但存在多行结果时，说明SQL请求中被可能被攻击者插入了注入语句，如今应中止后续处理并记录日志。2 .将来自
42、数据库的数据做为输入数据时，也应进行验证。3 .3.6分次提取数据关于数据库查询操作，假如查询返回的结果较多时，应设计成分次提取，应避免一次提取过多数据。4 .3.7通过row（行）级别的访问操纵来使用数据库不要依靠应用程序访问操纵能够保护数据库的数据，限制每个请求使用户只能访问他们自己的数据。通过row级别的访问操纵是防止用户信息泄露的“最后的防线”了。限制SQL请求只向当前认证的用户返回结果。当用户要执行SQL语句时，根据用户提交的用户名或者者ID进行推断是否具有执行该SQL语句操作的权限，来限制攻击者越权来执行SQL语句。538确保数据库资源被释放保证数据库访问在不需要使用的时候被释放，
43、比如连接、游标等。由于资源泄露会导致系统出错而且很难捕捉到，因此我们建议建立一个资源管理模块同时完全按照规则进行操作。禁止依靠Java与.NET的垃圾回收器来回收资源，在Java中，应该在finally块中释放资源来保证资源在任何环境下都会被释放。在.NET中，则需要使用关键字using引入IDiSPOSable接口来进行资源释放，而不是直接关闭管理资源的对象。5.4文件操作5.4.1 对上传文件进行限制同意用户上传文件时，应对上传文件做如下限制：1 .上传文件类型限制应遵循最小化原则，通过文件检查仅同意上传务必的文件类型。2 .上传文件大小限制，限制文件的容量大小范围。3 .文件储存路径限制
44、，过滤文件名或者路径名中的特殊字符（./或者.等）避免文件储存在非预期目录中。4 .应关闭文件上传目录的执行权限，在UNIX/LINUX系统环境里，建议把上传目录挂载成独立的逻辑盘或者设置为JAIL环境。5.4.2 把文件名与文件内容作为不可信的输入对待对来自文件系统的所有值都应进行合适的输入验证，确保从文件系统中读取的数据符合期望。5.4.3 安全的使用文件名应避免在传递的参数中直接使用真实的文件名，尽量使用索引值来映射实际的文件路径。如确实需要在参数中出现文件名，则尽量对文件名进行白名单检查。禁止在参数中出现等特殊字串及其变形。5.4.4 使用文件系统访问操纵由于文件系统是一个被多个用户共
45、享的系统，这就要求以最严格的权限来保护储存在其中的资源。这意味着文件只应被指定的用户访问，而且该用户应该被限制为最小权限，比如对文件的读写权限都应被限制到最低。当应用程序使用被其操纵的已存在文件时，应首先验证文件的权限与属组，防止文件存在被篡改的许可权限。5.4.5 注意文件访问竞争条件多进程或者线程对同一文件进行访问时，应采取适当的加锁策略保证文件数据在访问过程中的一致性。5.4.6 安全使用临时文件在程序初始化时以最严格的权限策略建立一个安全临时文件夹，该文件夹只有该程序具备读写权限，其他用户无法访问。将所有临时文件都存放在该文件夹中,当临时文件使用完毕后应及时清除临时文件。5.4.7 确保文件系统费源被释放1 .应保证诸如文件句柄之类的文件系统访问结构在不再需要时会被及时释放。2 .不要依靠JaVa与.NET的垃圾回收器来回收资源。a）在Java中，应该
