应用系统安全开发技术规范V1.3.docx

《应用系统安全开发技术规范V1.3.docx》由会员分享，可在线阅读，更多相关《应用系统安全开发技术规范V1.3.docx（36页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、XX科技股份有限公司3.14 使用应用中间件中间件作为一种应用层架构 软件设计应尽可能使用中间件，中间件选型时应 选择成熟的、业界主流的中间件产品。3.15 设计错误、异常处理机制软件设计开发时应建立防止系统死锁的机制，异常情况的处理和恢复机制，具 体包括错误和异常检测、数据回滚、安全错误通知、错误和异常记录、断点保护 等。3.16 提供备份机制为保证运行数据的完整性和可用性软件开发应设计有效的备份策略根据业 务和系统维护需要提供定期或不定期、自动或手动方式的备份机制。3.17 检查传递变量的合法性应检查所有传递给系统函数调用(System Calls)或本地调用(Native Calls)的

2、变 量的合法性。3.18 检查所有函数返回代码应检查所有函数调用返回代码(错误代码)，对每个期望的返回值设置相应的 处理程序。3.20 文件操作的要求应对面向用户的操作的反馈缺省描述进行必要的封装，删除有关后台系统或 其它敏感信息。4应用安全分析4.1 安全需求系统安全本质上属于信任问题，要保证应用安全，就必须将解决各种操作过 程中不可信问题。安全的几个基本要素为机密性、完整性、可用性、可审计 性、不可抵赖性等方面的安全要求。在需要进行文件操作时，应预先设定目前 工作路径(全路径名)，使用全路径名表示文件的位置。也包括以下几点：1 .机密性要求保护数据内容不能泄露，加密是实现机密性的要求的常见

3、手 段。2 .完整性要求保护数据内容是完整、没有被篡改的。3 .可用性要求保护资源是可被按照需要访问。4 .可审计性对出现的安全问题提供调查的依据和手段。不可抵赖性建立有 效的责任机制，防止用户否认其行为。4.2 安全威胁Web安全漏洞根据结合国网系统安全检测项目常见安全问题及OWASP组织发布的安全漏 洞，系统中存在的需要解决的安全风险如下：序号安全威胁产生环节1SQL注入编码2失效的身份认证及会话管理设计、编码3跨站脚本(XSS)编码4点击劫持(Clickjacking)编码4不安全的直接对象引用编码5安全配置错误配置实施6敏感信息泄露设计、编码7功能级访问控制缺失(失败的URL访问权限限

4、制)设计8跨站请求伪造(CSRF)编码拒绝服务攻击9使用含有已知漏洞的组件管理、设计10未验证的重定向和转发编码11传输层保护不足设计、编码12文件上传漏洞编码13不安全的加密存储设计、编码分布式拒绝服务攻击(英文：Distributed Denial of Service,缩写:DDoS) 亦称洪水攻击。顾名思义，即是利用网络上已被攻陷的电脑作为“僵尸”，向某一 特定的目标电脑发动密集式的“拒绝服务”式攻击，用以把目标电脑的网络资源 及系统资源耗尽，使之无法向真正正常请求的用户提供服务。黑客通过将一个个 “丧尸或者称为“肉鸡”组成僵尸网络，就可以发动大规模加。S或SYN洪水网络攻 击或者将“

5、丧尸”们组到一起进行带有利益的刷网站流量Email垃圾邮件群发 瘫痪预定目标受雇攻击竞争对手等商业活动。4.2.3 嗅探攻击利用计算机的网络接口截获目的地为其他计算机的数据报文的一种技术。它工作在网络的底层，把网络传输的全部数据记录下来.嗅探器可以帮助网络管理员 查找网络漏洞和检测网络性能。嗅探器可以分析网络的流量，以便找出所关心的 网络中潜在的问题。证明你的网络有嗅探器有两条经验：1 .网络通讯丢包率非常高：通过一些网管软件，可以看到信息包传送情况，最 简单是ping命令。它会告诉你掉了百分之多少的包。如果你的网络结构 正常，而又有20% 30%数据包丢失以致数据包无法顺畅的流到目的地。就有

6、可能有人在监听，这是由于嗅探器拦截数据包导致的。2 .网络带宽出现反常：通过某些带宽控制器，可以实时看到目前网络带宽的分布情况，如果某台机器长时间的占用了较大的带宽，这台机器就有可能 在监听。应该也可以察觉出网络通讯速度的变化。中间人攻击在密码学和计算机安全领域中，中间人攻击（Man-in-the-middle attack,通常缩写为MITM ）是指攻击者与通讯的两端分别建立独立的联系，并交换其所收到 的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话但事实 上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方 的 通话并插入新的内容。在许多情况下这是很简单的（

7、例如，在一个未加密的Wi.Fi 无线接入点的接受范围内的中间人攻击者，可以将自己作为一个中间人插入这个 网络）。一个中间人攻击能成功的前提条件是攻击者能将自己伪装成每一个参与会话 的终端，并且不被其他终端识破。中间人攻击是一个（缺乏）相互认证的攻击。大 多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。例如，SSL 协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信任的数字证 书认证机构颁发，并且能执行双向身份认证。5安全编程要求输入处理5.1.1 建立可信边界需要在程序中定义清晰的可信边界。在一些代码中用于保存可信数据的数据 结构，不能被用来在其它代码中存储不可信数据。

8、使数据穿越可信边界的次数降到 最低。当程序混淆了可信和不可信数据的界限时会导致安全边界发生问题最容导致这种 错误的情况是把可信和不可信数据混合在一个数据结构里。如下例：该例中程序接受一个http请求并将usmame n参数放在HTTP session里，但是并未检查用户是否被授权。usrname =request .getParameter(f 1 usrname11); if(session.getAttribute(ATTR_USR)= null) session.setAttribute(ATTR_USR,usrname);)由于开发者都知道用户是不能直接访问session对象的，所以很

9、容易信任来自session的所有信息，但是如果在该session中混合存储了可信和不可信的数据，就会违反完全可信边界的原则带来安全隐患。如果不能很好的建立和维护可信边 界，开发者将不可避免的混淆未被验证和己验证的数据，从而导致一些数据在未 经验证时就被使用。如果输入的数据在处理前通过一些用户的交互发生了改变，可 信边界就会遇到一定的问题，因为它很可能在所有数据进入之前不能做出完全的 输入验证。在这种情况下，维护一个可信的边界就尤为重要，不可信数据应该单 独存放在专门存放不可信数据的数据结构内,在经过验证之后才被放在可信区域 这样在看一段代码时，就很容易识别数据是在可信边界的哪一侧。5.1.2

10、验证各种来源的输入不要将软件的安全性寄托在配置、使用和维护人员的敏锐理解力、深刻洞察力 或良好意愿上，不仅需要验证用户输入，而且还要验证所有来自于软件之外的输 入。5.1.3 保证所有的输入信息是被验证过的确保在输入验证之前，新输入的数据不能被添加到程序中(输入的数据不能 进入程序代码中被执行)。也就是说，程序默认情况下要对所有的输入信息进行 验 证，不能通过验证的数据将会被拒绝。5.1.4 对输入内容进行规范化处理后再进行验证当输入数据包含文件名、路径名、URL等数据时，应先对输入内容进行规范化 处理后再进行验证，如文件路径、URL地址等数据，需要规范化为标准的格式后 再进行验证。5.1.5

11、 防范元字符攻击攻击者通常会使用元字符对应用程序发起攻击。攻击者可以通过对同一个元 字符采取多种编码方式或者根据语言特征采取多种实现方式，因此应过滤输入数 据中那些具有特定含义的字符，如单引号、双引号、圆括号、分号等。5.1.6 拒绝验证失败的数据应拒绝验证失败的输入数据，不试图对其进行修复（如处理密码域时自动剪裁 掉超过最大长度的输入，替换掉在输入框输入的JavaScript字符等）。输入验证本 身就很复杂，如果和自动错误恢复的代码混合在一起的话，将会造成更大的复 杂 性，自动错误恢复代码很可能改变请求的含义或者截断验证逻辑。如果我们能够 引导用户，使他们提交的请求能够通过输入验证，就会比专

12、注于自动错误恢复 代 码有效得多。在验证失败时，安全的做法是不试图修复一个未能通过输入验证 的 请求，直接拒绝掉。5.1.7 在服务端进行验证仅在客户端进行验证是不安全的，尤其是在WEB应用系统中，客户端的验证 大多采用脚本（如JavaScript）来完成，客户端的验证很容易被绕过，安全的做法 是在客户端验证的同时，在服务器端也进行验证。5.1.8 建立统一的输入验证接口应建立统一的输入验证接口，为整个应用系统提供一致的验证方法这样可以 避免分散验证带来的代码管理混乱，并且可以减少遗漏。5.1.9 控制写入日志的信息由于日志数据的价值 它也成为了攻击者的目标。如果攻击者可以控制写进日 志文件的

13、信息，他们就可以在输入中混入伪造的日志条目来伪造系统事件，更严 重的是，如果负责进行日志分析的代码存在漏洞，特定的有恶意的输入数据很 可 能触发该漏洞，并引发更加严重的危害。如果日志数据中包含输入数据，应对 输 入数据进行验证，禁止攻击者能够写任意的数据到日志中。5.1.10 从服务器端提取关键参数需要获取参数时，应当从服务器端提取关键参数，禁止从客户端输入，例如产 品价格、用户角色、鉴权标志等，如果关键参数允许从客户端输入提供，攻击 者 可通过伪造或篡改输入数据造成程序关键逻辑错误。5.2 输出处理5.2.1 限制返回给客户的信息编码时应该限制返回给客户与业务处理无关的信息，禁止把重点保护数

14、据返 回给不信任的用户，避免信息外泄。522建立错误信息保护机制开发人员在编码时，禁止将详细错误信息直接反馈到客户端，详细错误信息中 包含系统信息、文件和目录的绝对路径信息，应对错误信息进行规整和清理后再 返回到客户端，建议只向客户端返回错误码，详细错误信息可以记录在后台服 务 器。5.3 数据库访问531合理分配数据库访问权限应按照“最小化原则”为应用程序分配数据库访问权限。避免为应用程序分配 过大或不必要的数据库权限，禁止将数据库DBA权限分配给应用程序。5.3.1 合理存放数据库连接帐号和密码信息禁止在应用程序代码和配置文件明文存放数据库连接帐号和密码信息，建议 对数据库连接账户和密码信

15、息加密后再保存在配置文件中。533使用参数化请求方式使用参数化的SQL请求是防止SQL注入的有效方法。导致SQL注入漏洞 的 原因就是攻击者可以改变SQL请求的内容，攻击者提交的数据变成了 SQL执 行 命令的一部分。在构造SQL请求时，开发者应当知道哪些应该被翻译为数据而哪 些应该被翻译为命令的一部分。如果正确的使用参数化的SQL语句，就可以通过 不允许数据指向改变的方法来防御几乎所有的SQL注入攻击。参数化的SQL语句 通常是由SQL字符构造的，但是来自客户的数据是需要与一些绑定参数组合在一 起的。也就是说，开发者使用这些绑定参数来准确的向数据库指出哪些应该被当 作数据，哪些应该被当作命令

16、。当程序要执行该语句的时候，它就会告知数据库 这些绑定参数的运行值，这样就避免了数据被认为是命令语句而被执行的错误。 但是，如下是SQL请求中包含字符串拼接造成SQL注入漏洞的例子：这是一个javaweb应用程序，让用户在数据库中搜索一些信息，用户可以指定要搜寻的对象 名称，并用以下代码执行这些查询：Stringitem =request.getParamater(nitemt);String q=SELECT *FROM records WHEREitem=M+item;PreparedStatementstmt= conn.prepareStatement(q);ResultSetresu

17、lts=stmt.execute();虽然本例程序使用了参数化的接口，但是它犯了一个很常见的错误 把用户的 输入作为prepareStatement()的参数传入，如果允许用户控制PreparedStatement的内 容，参数化SQL提供的安全特性就会失去效果，很多SQL注入攻击的关键字也会 被包含在之前构造的语句中。合理的使用参数化SQL代码如下：Stringitem =request.getParamater(nitemn);String q=SELECT *FROM records WHEREitem=?n; PreparedStatementstmt= conn.prepareSta

18、tement(q); stmt.setString( 1 Jtem);ResultSetresults=stmt.execute();5.3.4 对SQL语句中来自于不可信区域的输入参数进行验证在一些复杂的情况会出现要求输入影响SQL语句结构的情况，譬如要求在 where子句里增加一个动态约束，这时应对来自不可信区域的输入参数进行验证。5.3.5 对数据库操作的返回数据进行验证不应盲IW信任来自数据库的数据，建议对来自数据库的数据进行验证，确保其格式正确且能够安全的使用:1 .检查SQL请求的返回记录数，SQL请求的预期结果为单值数据，但存 在多 行结果时，表明SQL请求中被可能被攻击者插入了

19、注入语句，此时 应中 止后续处理并记录日志。2 .将来自数据库的数据做为输入数据时，也应进行验证。536分次提取数据对于数据库查询操作，如果查询返回的结果较多时，应设计成分次提取，应避 免一次提取过多数据。537通过row （行）级别的访问控制来使用数据库不耍依赖应用程序访问控制能够保护数据库的数据，限制每个请求使用户只 能访问他们自己的数据。通过row级别的访问控制是防止用户信息泄露的“最后 的防线” 了。限制SQL请求只向当前认证的用户返回结果。当用户要执行SQL语 句时,根据用户提交的用户名或者ID进行判断是否具有执行该SQL语句操作的权 限，来限制攻击者越权来执行SQL语句。538确保

20、数据库资源被释放保证数据库访问在不需要使用的时候被释放，例如连接、游标等。由于资源泄 露会导致系统出错而且很难捕捉到，所以我们建议建立一个资源管理模块并且完全 按照规则进行操作。禁止依赖Java和.NET的垃圾回收器来回收资源，在Java中，应 该在finally块中释放资源来保证资源在任何环境下都会被释放。在.NET中，则需要 使用关键字using引入【Disposable接口来进行资源释放，而 不是直接关闭管理资源 的对象。5.4文件操作541对上传文件进行限制允许用户上传文件时，应对上传文件做如下限制：1 .上传文件类型限制应遵循最小化原则，通过文件检查仅允许上传必须的文 件类型。2 .

21、上传文件大小限制，限制文件的容量大小范围。3 .文件保存路径限制，过滤文件名或路径名中的特殊字符（./或.等）避 免文件保存在非预期目录中。4 .应关闭文件上传目录的执行权限，在UNIX/LINUX系统环境里，建议把 上 传目录挂载成独立的逻辑盘或设置为JAIL环境。542把文件名以及文件内容作为不可信的输入对待对来自文件系统的所有值都应进行合适的输入验证，确保从文件系统中读取的 数据符合期望。5 .4.3安全的使用文件名应避免在传递的参数中直接使用真实的文件名，尽量使用索引值来映射实际的 文件路径。如确实需要在参数中出现文件名，则尽量对文件名进行白名单检查。禁 止在参数中出现等特殊字串及其变

22、形。6 .4.4使用文件系统访问控制由于文件系统是一个被多个用户共享的系统，这就要求以最严格的权限来保护1背景与目标在Internet大众化及Web技术飞速演变的今天Web安全所面临的挑战日益严 峻。黑客攻击技术越来越成熟和大众化，针对Web的攻击和破坏不断增长，Web安 全风险达到了前所未有的高度。许多程序员不知道如何开发安全的应用程序，开发出来的Web应用存在较多 的安全漏洞，这些安全漏洞一旦被黑客利用将导致严重甚至是灾难性的后果。这并 非危言耸听，类似的网上事故举不胜举，公司的Web产品也曾多次遭黑客攻击， 甚至有黑客利用公司Web产品的漏洞敲诈运营商，造成极其恶劣的影响。本规范为解决W

23、eb应用系统安全问题，对主要的应用安全问题进行分析，并 有针对性的从设计及开发规范、开发管理、安全组件框架、安全测试方面提供整体 的安全解决方案。使本组织能以标准的、规范的方式设计和编码。通过建立编码规范，以使每个 开发人员养成良好的编码风格和习惯；并以此形成开发小组编码约定，提高程 序 的可靠性、可读性、可修改性、可维护性和一致性等，增进团队间的交流，并保证 软件产品的质量。2安全编程概念2.1安全编程安全编程是指开发人员首先需要具备一定的安全知识，然后识别数据在流转 （输入、处理和输出）过程中可能面对的威胁，对这些威胁进行分析得出其利用 的漏洞，通过合理地编写代码消除这些漏洞，降低软件面临

24、的风险。本规范对开发 人员的编码提出统一的安全要求，主要涉及输入处理、输出处理、数据库访问、文 件操作、异常管理等方面，如下图：保存在其中的资源。这意味着文件只应被指定的用户访问，而且该用户应该被制为最 小权限，例如对文件的读写权限都应被限制到最低。当应用程序使用被其控制的已 存在文件时，应首先验证文件的权限和属组，防止文件存在被篡改的许可权限。545注意文件访问竞争条件多进程或线程对同一文件进行访问时，应采取适当的加锁策略保证文件数据 在访问过程中的一致性。安全使用临时文件在程序初始化时以最严格的权限策略建立一个安全临时文件夹，该文件夹只有 该程序具备读写权限，其他用户无法访问。将所有临时文

25、件都存放在该文件夹中， 当临时文件使用完毕后应及时清除临时文件。547确保文件系统资源被释放.应保证诸如文件句柄之类的文件系统访问结构在不再需要时会被及时释放。1 .不要依赖Java和.NET的垃圾回收器来回收资源。a）在Java中，应该在finally块中释放资源来保证资源在任何情况下都会被 释放。b）在.NET中，则需要使用关键字using引入【Disposable接口来进行 资源 释放，而不是直接关闭管理资源的对象。6安全特征关注应用的对象重用1 .对于底层系统的对象可重用性来说，应用软件需要提供对敏感数据使用后立即覆盖的能力，这些敏感数据包括口令、安全密钥、会话密钥或者其它的 高度敏感

26、的数据。2 .应提高代码的重复利用率，创建公共函数库（对象库）供整个软件程序调不要在客户端存放敏感数据由于客户端是不可信任的，软件不要在客户端存放敏感数据。特别注意在使用 Cookie时不要把客户重要信息储存在客户端。6.1 避免内存溢出软件设计开发中，为防止内存溢出，应注意以下事项：1 .在对缓存区填充数据时应进行边界检查，判断是否超出分配的空间。2 .对于数据库查询操作，如果查询返回的结果较多时，应设计成分次提取。3 .应保证系统资源及时释放和服务连接的及时关闭，应显式关闭、释放使用过 的资源（如连接对象、文件句柄等），不要依赖垃圾收集器。4 .软件程序应检查每次内存分配是否失败，并进行处

27、理。5 .应及时释放内存资源，防止内存泄漏，但要避免重复内存释放。6 .其他可能引起内存溢出的情况。6.4 可配置数据保护限制非应用软件用户访问可配置数据。可采用系统访问控制为配置数据文件设 置严格的访问权限，仅应用程序可以访问。6.5 禁止在源代码中写入口令应将加密后的口令存储在配置文件，数据库或者其它外部数据源中。禁止将口 令存储在代码中。把口令存储在代码中会导致任何人都可以获得到存储在代码中的 口令，同时口令写在发布的软件中，如果需要修改口令，则软件必需要通过安装程 序补丁等方式替换程序文件，会造成口令难于修改。6.6 随机数如果应用程序需要随机数，需要找出一种合适的随机数生成方法，要求

28、其生成 代价较小并且应满足安全需求。1 .在Java中，建议使用SecureRandom类生成随机数，不要使用Random类。通常不需要设置种子数给SecureRandom, Java会自动获取一个信息炳比 较 平均的值。2 .在C和C什中，避免使用标准的随机数函数，如 rand(),srand(),srand48(),drand48(),lrand48(),random()fll srandom() 0.在随机数生成器中不要使用容易被猜到的种子。两种最常见的选种错误是 使用空种子和使用日期作为种子。(对于Java来说，SecureRandom的默认构 造方法可以正确的选种)。3 .如果操作系

29、统或者应用程序使用的加密库有一个真实的随机源，那么应使 用该随机源。在很多Unix平台上，A/dev/urandom读取16字节可以给 出相 当高质量的随机序列，建议从/dev/urandom获取随机源。6.7 使用可信的密码算法如果应用程序需要加密、数字签名、密钥交换或者安全散列，应使用一个成熟 的算法，自己设计的密码算法缺乏广泛的验证。6.8 异常管理.捕捉并处理异常：a)应使用结构化异常处理机制，捕捉并处理异常现象。b)避免将应用程序置于不协调的状态该状态可能会导致信息泄漏或拒绝 服务攻击。1 .记录详细的错误信息：a)应在错误日志中记录详细的错误消息。b)应向服务或应用程序的客户发送最

30、少量的信息，确保没有密码或其他敏感数据。如一般性错误消息和自定义错误日志ID,随后可以将这些信 息映射到事件日志中的详细消息。2 .不要向客户端泄漏信息：a)发生故障时，严禁向客户端泄漏信息，禁止暴露的内容包括函数名以 及调试内部版本时出问题的详细信息Ob）向客户端返回一般性错误消息。可以将应用程序设置为不向远程用户显 示详细错误信息，也可以选择将错误重定向到应用程序页。C）应捕捉所有未处理异常并将它们发送到一般错误页的页级别或应用程序级别上，创建全局错误处理程序。7应用安全设计规范7.1 应用安全规划将应用系统划分为多个相对独立的逻辑单元，按照逻辑单元的安全要求，规划逻辑单元的部署区域以及访

31、问方式，确保逻辑单元的边界访问安全。7.2 数据安全等级划分对应用系统的数据进行分析，区分出普通数据、敏感数据和保密数据等类型。普通数据：凡是不涉及敏感信息的数据都属于普通数据，系统中大部分的数据都是属于普通数据，普通数据允许采用明文传输和明文存储。敏感数据：敏感数据涉及到重要信息，为防止在传输过程中被拦截窃取或遭到篡改，要求敏感数据在客户端和服务端之间必须采用SSL7TLs协议进行 传输，保证数据的传输安全。敏感数据除了传输需要加密外，一般还要求对 敏感数据新增和变更操作进行审计。如：信用卡信息、支付交易等属于敏感 数据。保密数据：凡是不允许使用明文存储的数据都属于保密数据，保密数据除了必须

32、满足敏感数据对数据传输进行加密和审计的要求外，还必须按照保密 性的要求，在数据存储之前对数据进行加密，数据库或文件中仅存储加密后 的数据。如：用户口令、支付密码、信用卡密码等属于保密数据。7.3 数据库规划7.3.1 用户权限合理规划数据库用户，避免因为权限分配不当引起的数据安全问题。732数据源设计为事务执行时间较长的操作分配单独的数据源，避免因为事务长时间暂用数连接 而对其它功能造成影响。7.3.3 外部系统访问外部系统需要直接访问应用的数据时，应单独分配一个用户，并按照最小权限原则 仅分配外部系统所需的最小访问权限。7.4 角色划分对外网类应用，必须预先定义外网用户角色类型、各类角色的应

33、用场景，并按照缺 省最小权限原则划分角色权限。7.5 URL规划对外网类应用，按照用户角色对应权限类型对系统URL进行规划，各种不同权 限功能对应的URL按照各种不同的统一的URL规则进行定义，具有不同访问 权限 要求的URL路径规则不应混合在一起。如：用户个人空间对应功能都在/user/路径下管理员对应的功能都在/admin/路径下7.6 程序文件目录规划761数据及程序分离遵守数据文件和程序文件分离的原则，在应用部署根及子目录下不应存放任何 数据文件。762静态程序资源静态程序资源应统一存放在指定的目录下，在静态程序资源目录下不要存放任 何动态资源、可执行文件、数据及任何无关资源。程序文件

34、分类程序文件分为可直接被客户端请求访问的文件以及无法从客户端直接访问的文 件，应对程序文件进行划分，将不同的程序文件存放在不同的目录下。如果不希望某个程序文件能被客户端输入文件路径后被直接，应该将这些文件 放在WEB-INF目录下。否则WEB-INF目录之外的文件都可以通过客户端输入URL直接访问或下载。7.7 CookieCookie的使用必须做统一的分析和管理，并按照Cookie存储的数据重要程序 及使用场景做划分。禁止被客户端Javascript及applet等操作必须通过Https在客户端和服务端之间传输仅对当前会话有效，浏览器关闭后即失效允许存储在客户端本地7.8 文件安全7.8.1

35、 文件存储系统运行过程中生成的正式文件必须存储在专门的文件服务器上，并要设置安 全访问策略。7.8.2 文件操作外网文件操作必须通过HTTP协议提供的WebDAV完成，不要使用FTP等文件 传输协议。并且不允许直接对外开放文件服务器的访问权限，文件访问因通过应用 服务器中转完成。7.8.3 文件类型必须明确指定应用系统中允许上传的文件类型。7.9 第三方组件安全7.9.1 组件兼容性所以引入的第三方组件都必须确保组件与平台之间的兼容性，避免引入组件后 引起平台及现有组件崩溃、无法运行、出现BUG等问题。7.9.2 组件安全及成熟度对第三方组件的成熟度及安全做评估，确保第三方组件不存在已知的未解

36、决的 安全漏洞，并且有成熟的社区在对组件升级和维护，当组件出现新的安全漏洞时， 能被及时解决。7.9.3 组件配置必须按照安全的方式对组件进行集成和配置，避免出现因为配置和使用不当引 起的安全漏洞。7.10 Web Service1 .必须对Web Service接口的调用必须进行认证，认证就是确定谁在调用Web Service,并且证实调用者身份。方案：可以通过在消息头中增加用户名和口令，作为认证凭据；对于安全性要 求不高、只向同一信任域内其他主机开放的Web Service接口，可以通过简单的IP认 证来实现接口的认证（只有服务器端指定IP地址的客户端才允许调用，IP地址可配 置）。2 .

37、如果调用者的权限各不相同，那么必须对Web Service接口的调用进行鉴权, 鉴权就是判断调用者是否有权限调用该Web Service接口。方案：可以通过Axis的handler对调用进行鉴权。3 .通过Web Service接口传递敏感数据时，必须保障其机密性。方案：1）采用HTTPS安全协议。2）使用axis2开发Web Service,使用安全组件，并且该组 件需要依赖wss4j等组件。4 .通过Web Service接口传递重要的交易数据时，必须保障其完整性和不可抵 赖性重要的交易数据，如转账时涉及的“转入账号”、“转出账号”、“金额”等。5 .如果Web Service只对特定的I

38、P开放，那么必须对调用Web Service接口的 客户端IP进行鉴权，只有在IP地址白名单中的客户端才允许调用，IP地址白名单可 配置。6 .对Web Service接口调用进行日志记录，日志内容包括但不限于如下内容：调用时间、操作类型、调用接口名称、详细的接口参数、客户端IP、客户端机器名、 调用者的用户标识、受影响的个体（数据、资源）、成功或失败标识。7 .必须对Web Service提交的参数进行输入校验。7.11应用安全关注点储图1典型的Web安全技术框由于HTTP的开放性，Web应用程序必须能够通过某种形式的身份验证来识别用 户，并确保身份验证过程是安全的，同样必须很好地保护用于跟

39、踪已验证用户的会话处理机制。为了防止一些恶意输入，还要对输入的数据和参数进行校验。另外还要考虑Web系统的安全配置，敏感数据的保护和用户的权限管理，以及所 有操作的安全审计。当然还要考虑代码安全，以及其他方面的威胁。7.13应用安全限制应对方案7.13.1 外网隔离7.13.1.1 前置机涉及到外网访问的应用，必须将与外网交互的应用部署在外网前置机，外部 用户或系统只能访问前置机服务。7.13.1.2 内网应用当外网应用需要与内网业务系统交互时，必须在内网部署相关应用，并通过 内网应用与业务系统交互。7.13.1.3 数据库外网不允许部署数据库，所有的数据库都部署在内网，外网应用通过强隔离装

40、置使用JDBC访问部署在内网的数据库。外网应用不允许从外网直接连接内网关键 业务系统数据库，如：禁止对外网站直接通过JDBC连接营销系统生产库。7.13.2 外网文件操作外网不部署FTP等服务，当外网应用需要文件系统支持时，通过WebDAV来替 代FTP。并且当用户操作需要访问文件时，文件访问操作应通过应用系统进行文件 操作的中转，不要让客户端通过文件访问协议直接连接文件系统。WebDAV (Web-based Distributed Authoring and Versioning) 一种基于 HTTP 1.1 协议 的通信协议。它扩展了 HTTP 1.1,在GET、POST、HEAD等几个

41、HTTP标准方法以外 添加了一些新的方法，使应用程序可直接对Webserver上的文件读写，并支持写文 件锁定(Locking)及解锁(Unlock),还可以支持文件的版本控制。7.13.3 正向和反向隔离装置(国网系统)正向和反向隔离装置用于调度控制区(i/n区)与管理信息区(ni区)数据交互的时 候要用的设备。正向隔离装置用于安全区VII到安全区III的单向数据传递。反向隔离装置用于安全区m到安全区i/n的单向数据传递。7.13.3.1 正向隔离装置针对VII区到III区通信内容规定，南瑞SysKeeper-2000网络安全隔离设备提 供 了丰富的通信工具软件和API函数接口，方便用户进行

42、二次系统隔离改造。8应用安全开发规范8.1 Java及Web安全编程规范不信任未知JAVA编程时同样需要遵守任何输入都是不可信的原则。所有的输入都是不安全 的，在使用前都应进行检查、验证或者过滤。这里的输入不仅仅指正常情况下的用 户输入，还包括从文件获取的内容、从协议的数据包中获取的内容，从环境 变量、 注册表等获取的输入。8.1.1 数据层开发8.1.2 预编译语句数据层最大的安全风险是SQL注入，SQL注入指的是利用现有应用程序，将（恶 意）的SQL命令注入到后台数据库引擎执行的攻击方法。没有对用户输入的数据进 行验证是Sql注入攻击得逞的主要原因。用户可以提交一段数据库查询代码，根据程

43、序返回的结果，获得某些他想得知的数据。为防御SQL注入攻击，必须采用预编译 的方式执行SQL语句或存储过程。正确：String querySql= aselect username from user where id=?”错误：String id二abc”输入处理部分能指导开发者避免用户的不良输入；输出处理能指导开发者对输出内容进行过滤；数据库访问、文件操作部分则能指导开发者进行数据库查询，写入 文件等操作时进行防护；而异常管理、敏感数据保护、对象重用等技术则指导开发者改 进软件的自身缺陷。WEB开发规范部分则指导用户在WEB系统（B/S架构应用）的研发方面时如何增加对应用软件的保护。2.2

44、 结构化编程结构化编程，一种编程典范。它采用子程序、程式码区块、for循环以及while循环等结 构，来取代传统的got。希望借此来改善计算机程序的明晰性、品质以及开发时间，并且避 免写出面条式代码。2.3 脆弱性脆弱性指计算机系统安全方面的缺陷，使得系统或其应用数据的保密性、完整性、可用性、访问控制、监测机制等面临威胁。String querySql= uselect username from user where id= +id+ ”上段可能产生SQL注入的代码如下：String user = request. getParameter(nusername);String pass =

45、request- getParameter(Apasswordn);String query = SELECT id FROM users WHERE usernamc=n+user+ AND pas s wor d=/x +pas s;Statement stmt = con. createstatement(query);ResultSet rs = con. executeQuery(query): if (rs- next ()登录成功 int id = rs. getlnt(l);else登录失败正确的做法如下：String user 二 request. getParameter(

46、Ausernamen):String pass = request. getParameter(n pass wordM;String query = SELECT id FROM users WHERE usemame=? AND password=?”;PreparedStatement stmt = con. preparestatement(query);stmt. setString(l, user);stmt. setString(2, pass);ResultSet rs 二 stmt. executeQueryO;if (rs next ()登录成功int id = rs. g

47、etlnt(l);else登录失败如果没有使用PreparedStatement类就一定要对输入做特殊字符过滤，过滤的字 符至少包括：（单引号）；（分号） （两个减号）。数据验证在执行SQL或存储过程之前，必须确保传入的参数变量都已经过验证符合规则 或权限约束。会话管理会话创建在用户认证成功后，应先将之前的用户会话销毁，然后重新为用户生成新的会 话，保证认证成功前后，用户会话ID不一样，并且保证不会将数据存放到未认证通 过的会话中。会话创建过程应严格遵守以下的步骤：1、接收提交的用户名和密码 2、验证通过session.invalidate ()方法注销当前会话4A调用request.getSession (true )重新生成一个新的会话5、将用户名等会话信息放入新生成的session对象中存放会话数据存储不要将除了标识当前用户身份之外的其它数据存放到用户的Session中。8.133会话注销要提供用户注销功能，并且应保证以下的代码在注销过程中被调用：session.invalidate()8.1.4 Cookie1.1.1.1 临时 Cookie临时Cookie指的是没有指定Expire