华为Web应用安全开发规范.doc

1、DKBA华为技术有限公司内部技术规范DKBA 1606-XXXX.XWeb 应用安全开发规范 V1.52013 年 XX 月 XX 日发布 2013 年 XX 月 XX 日实施华为技术有限公司Huawei Technologies Co., Ltd.版权所有 侵权必究All rights reserved修订声明 Revision declaration本规范拟制与解释部门：网络安全能力中心HttpSession newSession=request.getSession(true);Cookie cookie = new Cookie(“JSESSIONID“,newSession.getI

2、d(); cookie.setMaxAge(-1);cookie.setSecure(false);cookie.setPath(request.getContextPath();response.addCookie(cookie);场景二：对于全程采用 HTTPS 协议，或者全程采用 HTTP 协议的，在用户名和密码认证通过后增加以下行代码：request.getSession().invalidate();request.getSession(true);建议 3.2.2.1：管理页面建议实施强身份认证。说明：如双因素认证、SSL 双向证书认证、生物认证等；还可以通过应用程序限制只允许某些

3、特定的 IP 地址访问管理页面，并且这些特定的 IP 地址可配置。建议 3.2.2.2：同一客户端在多次连续尝试登录失败后，服务端需要进行用户帐号或者是客户端所在机器的 IP 地址的锁定策略，且该锁定策略必须设置解锁时长，超时后自动解锁。说明：登录失败应该提示用户：如果重试多少次不成功系统将会锁定。在锁定期间不允许该用户帐号（或者客户端所在机器的 IP 地址）登录。允许连续失败的次数（指从最后一次成功以来失败次数的累计值）可配置，取值范围为：0-99 次，0 表示不执行锁定策略，建议默认：5 次。锁定时长的取值范围为：0-999 分钟，建议默认：30 分钟，当取值为 0 时，表示无限期锁定，只

4、能通过管理员手动解锁（需要提供管理员对服务器锁定其它用户帐号/IP 进行解锁的功能界面） 。建议优先使用帐号锁定策略。注意：应用程序的超级用户帐号不能被锁定，只能锁定操作的客户端所在的 IP，这是为了防止系统不可用。特别说明：锁客户端 IP 策略存在缺陷，当用户使用 proxy 上网时，那么锁定客户端 IP 会导致使用该 proxy 上网的所有用户在IP 锁定期间都不能使用该 Web 应用；锁定用户帐户的策略也存在缺陷，当攻击者不断尝试某帐户的口令，就给该帐户带来拒绝服务攻击，使该帐户不可用。3.2.3 验证码规则 3.2.3.1：验证码必须是单一图片，且只能采用 JPEG、PNG 或 GIF

5、 格式。说明：验证码不能使用文本格式，不允许多图片组合（如用四个图片拼成的验证码） 。规则 3.2.3.2：验证码内容不能与客户端提交的任何信息相关联。说明：在使用验证码生成模块时不允许接收来自客户端的任何参数，例如：禁止通过 getcode.jsp?code=1234 的 URL 请求，将 1234 作为验证码随机数。规则 3.2.3.3：验证码模块生成的随机数不能在客户端的静态页面中的网页源代码里出现。说明：在客户端网页上点击鼠标右键、选择“查看源文件”时，必须看不到验证码模块生成的随机数。规则 3.2.3.4：验证码字符串要求是随机生成，生成的随机数必须是安全的。说明：对于 java 语

6、言可以使用类 java.security.SecureRandom 来生成安全的随机数。规则 3.2.3.5：验证码要求有背景干扰，背景干扰元素的颜色、位置、数量要求随机变化。规则 3.2.3.6：验证码在一次使用后要求立即失效，新的请求需要重新生成验证码。说明：进行验证码校验后，立即将会话中的验证码信息清空，而不是等到生成新的验证码时再去覆盖旧的验证码，防止验证码多次有效；注意：当客户端提交的验证码为空，验证不通过。说明：以上规则可以通过使用电信软件与核心网网络安滩刻峁验证码 CBB来实现。3.3 会话管理规则 3.3.1：使用会话 cookie 维持会话。说明：目前主流的 Web 容器通过

7、以下几种方式维持会话：隐藏域、URL 重写、持久性 cookie、会话 cookie，但通过隐藏域、URL 重写或持久性 cookie 方式维持的会话容易被窃取，所以要求使用会话 cookie 维持会话。如果条件限制必须通过持久性 cookie 维持会话的话，那么 cookie 信息中的重要数据部分如身份信息、计费信息等都必须进行加密。 （cookie 有两种：会话 cookie 和持久性cookie；会话 cookie，也就是非持久性 cookie，不设置过期时间，其生命期为浏览器会话期间，只要关闭浏览器窗口，cookie 就消失了；会话 cookie 一般不存储在硬盘上而是保存在内存里。持

8、久性 cookie，设置了过期时间，被浏览器保存到硬盘上，关闭后再次打开浏览器，持久性 cookie 仍然有效直到超过设定的过期时间。 ）备注：对于嵌入式系统的 Web，不适合本条规则，按“规则 3.3.9”实施。规则 3.3.2：会话过程中不允许修改的信息，必须作为会话状态的一部分在服务器端存储和维护。说明：会话过程中不允许修改的信息，例如，当用户通过认证后，其用户标识在整个会话过程中不能被篡改。禁止通过隐藏域或 URL 重写等不安全的方式存储和维护。对 JSP 语言，就是应该通过 session 对象进行存储和维护。规则 3.3.3：当 Web 应用跟踪到非法会话，则必须记录日志、清除会话

9、并返回到认证界面。说明： 非法会话的概念就是通过一系列的服务端合法性检测（包括访问未授权资源，缺少必要参数等情况） ，最终发现的不是正常请求产生的会话。规则 3.3.4：禁止使用客户端提交的未经审核的信息来给会话信息赋值。说明：防止会话信息被篡改，如恶意用户通过 URL 篡改手机号码等。规则 3.3.5：当用户退出时，必须清除该用户的会话信息。说明：防止遗留在内存中的会话信息被窃取，减少内存占用。实施指导：对于 JSP 或 java 语言使用如下语句：request.getSession().invalidate();规则 3.3.6：必须设置会话超时机制，在超时过后必须要清除该会话信息。说明

10、：建议默认会话超时时间为 10 分钟（备注：对于嵌入式系统中的 Web，建议默认超时时间为 5 分钟，以减少系统资源占用） 。如果没有特殊需求，禁止使用自动发起请求的机制来阻止 session 超时。规则 3.3.7：在服务器端对业务流程进行必要的流程安全控制，保证流程衔接正确，防止关键鉴别步骤被绕过、重复、乱序。说明：客户端流程控制很容易被旁路（绕过） ，因此流程控制必须在服务器端实现。实施指导：可以通过在 session 对象中创建一个表示流程当前状态的标识位，用 0、1、2、3 、N 分别表示不同的处理步骤，标识位的初始值为 0，当接收到步骤 N 的处理请求时，判断该标识位是否为 N-1

11、，如果不为 N-1，则表示步骤被绕过（或重复或乱序） ，拒绝受理，否则受理，受理完成后更改标识位为N。规则 3.3.8：所有登录后才能访问的页面都必须有明显的“注销（或退出） ”的按钮或菜单，如果该按钮或菜单被点击，则必须使对应的会话立即失效。说明：这样做是为了让用户能够方便地、安全地注销或退出，减小会话劫持的风险。规则 3.3.9：如果产品（如嵌入式系统）无法使用通用的 Web 容器，只能自己实现 Web 服务，那么必须自己实现会话管理，并满足以下要求： 采用会话 cookie 维持会话。 生成会话标识（session ID）要保证足够的随机、离散，以便不能被猜测、枚举，要求 session

12、 ID 要至少要 32 字节，要支持字母和数字字符集。 服务端必须对客户端提交的 session ID 的有效性进行校验。说明：在嵌入式系统中部署 Web 应用，由于软硬件资源所限，往往无法使用通用的 Web 容器及容器的会话管理功能，只能自己实现。另外，为了节省内存，嵌入式 webserver 进程往往是动态启动，为了使 session 更快的超时，建议增加心跳机制，对客户端浏览器是否关闭进行探测，5s 一个心跳，30s 没有心跳则 session 超时，关闭该 session。3.4 权限管理规则 3.4.1：对于每一个需要授权访问的页面或 servlet 的请求都必须核实用户的会话标识是

13、否合法、用户是否被授权执行这个操作。说明：防止用户通过直接输入 URL，越权请求并执行一些页面或 servlet；建议通过过滤器实现。实施指导： 请参考“附件 5 Web 权限管理设计规格说明书.docx” 。规则 3.4.2：授权和用户角色数据必须存放在服务器端，不能存放在客户端，鉴权处理也必须在服务器端完成。说明：禁止将授权和角色数据存放在客户端中（比如 cookie 或隐藏域中） ，以防止被篡改。规则 3.4.3：一个帐号只能拥有必需的角色和必需的权限。一个组只能拥有必需的角色和必需的权限。一个角色只能拥有必需的权限。说明：做到权限最小化和职责分离（职责分离就是分清帐号角色，系统管理帐号

14、只用于系统管理，审计帐号只用于审计，操作员帐号只用于业务维护操作，普通用户帐号只能使用业务。 ）这样即使帐号被攻击者盗取，也能把安全损失控制在最小的限度。规则 3.4.4：对于运行应用程序的操作系统帐号，不应使用“root” 、“administrator”、 “supervisor”等特权帐号或高级别权限帐号，应该尽可能地使用低级别权限的操作系统帐号。规则 3.4.5：对于应用程序连接数据库服务器的数据库帐号，在满足业务需求的前提下，必须使用最低级别权限的数据库帐号。说明：根据业务系统要求，创建相应的数据库帐号，并授予必需的数据库权限。不能使用“sa” 、 “sysman”等管理帐号或高级别

15、权限帐号。3.5 敏感数据保护3.5.1 敏感数据定义敏感数据包括但不限于：口令、密钥、证书、会话标识、License、隐私数据（如短消息的内容） 、授权凭据、个人数据（如姓名、住址、电话等）等，在程序文件、配置文件、日志文件、备份文件及数据库中都有可能包含敏感数据。3.5.2 敏感数据存储规则 3.5.2.1：禁止在代码中存储敏感数据。说明：禁止在代码中存储如数据库连接字符串、口令和密钥之类的敏感数据，这样容易导致泄密。用于加密密钥的密钥可以硬编码在代码中。规则 3.5.2.2：禁止密钥或帐号的口令以明文形式存储在数据库或者文件中。说明：密钥或帐号的口令必须经过加密存储。例外情况，如果 We

16、b 容器的配置文件中只能以明文方式配置连接数据库的用户名和口令，那么就不用强制遵循该规则，将该配置文件的属性改为只有属主可读写。规则 3.5.2.3：禁止在 cookie 中以明文形式存储敏感数据。说明：cookie 信息容易被窃取，尽量不要在 cookie 中存储敏感数据；如果条件限制必须使用 cookie 存储敏感信息时，必须先对敏感信息加密再存储到cookie。规则 3.5.2.4：禁止在隐藏域中存放明文形式的敏感数据。规则 3.5.2.5：禁止用自己开发的加密算法，必须使用公开、安全的标准加密算法。实施指导：场景 1：后台服务端保存数据库的登录口令后台服务器登录数据库需要使用登录数据库

17、的明文口令，此时后台服务器加密保存该口令后，下次登录时需要还原成明文，因此，在这种情况下，不可用不可逆的加密算法，而需要使用对称加密算法或者非对称加密算法，一般也不建议采用非对称加密算法。推荐的对称加密算法：AES128 、AES192 、AES256。场景 2：后台服务端保存用户的登录口令在该场景下，一般情况是：客户端提交用户名及用户口令，后台服务端对用户名及用户口令进行验证，然后返回验证的结果。此时，在后台服务端，用户口令可以不需要还原，因此建议使用不可逆的加密算法，对“用户名+口令”字符串进行加密。推荐的不可逆加密算法： SHA256、SHA384、SHA512，HMAC-SHA256、

18、HMAC-SHA384、HMAC-SHA512。规则 3.5.2.6：禁止在日志中记录明文的敏感数据。说明：禁止在日志中记录明文的敏感数据（如口令、会话标识 jsessionid 等） ， 防止敏感信息泄漏。规则 3.5.2.7：禁止带有敏感数据的 Web 页面缓存。说明：带有敏感数据的 Web 页面都应该禁止缓存，以防止敏感信息泄漏或通过代理服务器上网的用户数据互窜问题。实施指导：在 HTML 页面的 标签内加入如下代码：在 JSP 页面的最前面加入如下代码：注意：以上代码对于采用强制缓存策略的代理服务器不生效（代理服务器默认是不缓存的） ，要防止代理服务器缓存页面，可以在链接后加入一个随机

19、数pageid,此时链接变成： http:/localhost:8080/query.do?a=2String characterPattern = “d+$“; /正则表达式表示是否全为数字if (!mobileno.matches (characterPattern)out.println (“Invalid Input”);规则 4.1.7：如果输入只允许包含某些特定的字符或字符的组合，则使用白名单进行输入校验。说明：对于一些有规则可循的输入，如 email 地址、日期、小数等，使用正则表达式进行白名单校验，这样比使用黑名单进行校验更有效。实施指导：email 地址校验的方法：Strin

20、g emailAddress = request.getParameter(“emailAddress“);String characterPattern = “(a-z0-9A-Z+_-?)+a-z0-9A-Z(a-z0-9A-Z+_-?)+(-a-z0-9A-Z+)?.)+a-zA-Z2,4$“; /email 正则表达式if (!emailAddress.matches(characterPattern)out.println (“Invalid Email Address”);规则 4.1.8：如果输入为字符串参数则必须进行字符型合法性判断。说明：可定义一个合法字符集。实施指导：Str

21、ing text = request.getParameter(“text“);String characterPattern = “A-Za-z*$“; /开发者自行定义字符规则 (方括号内的字符集)if (!text.matches (characterPattern)out.println (“Invalid Input”);规则 4.1.9：校验输入数据的长度。说明：如果输入数据是字符串，必须校验字符串的长度是否符合要求，长度校验会加大攻击者实施攻击的难度。规则 4.1.10：校验输入数据的范围。说明：如果输入数据是数值，必须校验数值的范围是否正确，如年龄应该为0150 之间的正整数。

22、规则 4.1.11：禁止通过字符串串联直接使用用户输入构造可执行 SQL 语句。说明：禁止通过字符串串联直接使用用户输入构造可执行 SQL 语句，如：string sql = “select status from Users where UserName=“ + txtUserName.Text + “;这样很容易被 SQL 注入攻击。规则 4.1.12：对于 java/JSP 语言，使用预编译语句 PreparedStatement 代替直接的语句执行 Statement。说明：使用预编译语句 PreparedStatement，类型化 SQL 参数将检查输入的类型，确保输入值在数据库中当

23、作字符串、数字、日期或 boolean 等值而不是可执行代码进行处理，从而防止 SQL 注入攻击。而且，由于 PreparedStatement 对象已预编译过，所以其执行速度要快于 Statement 对象。因此，多次执行的 SQL 语句经常创建为 PreparedStatement 对象，还可以提高效率。实施指导：参考如下代码：String inssql = “insert into buy(empid, name, age, birthday) values (?,?,?,?)“;PreparedStatement stmt = null;stmt = conn.prepareState

24、ment(inssql); stmt.setString(1, empid);stmt.setString(2, name); stmt.setInt(3, age);stmt.setDate(4, birthday);stmt.execute();备注：使用 like 进行模糊查询时，如果直接用“select * from table where comment like %?%“，程序会报错，必须采用如下方法String express = “select * from table where comment like ?“;pstmt = con.prepareStatement(exp

25、ress);String c=“hello“;pstmt.setString(1, “%“+c+“%“);/参数自动添加单引号，最后的 SQL 语句为：select * from table where comment like %hello%pstmt.execute();规则 4.1.13：禁止动态构建 XPath 语句。说明：和动态构建 SQL 一样，动态构建 XPath 语句也会导致注入漏洞（XPath注入） 。动态构建 XPath 语句的例子：public boolean doLogin(String loginID, String password)XPathExpression

26、expr = pile(“/users/userloginID/text()=“+loginID+“ and password/text()=“+password+“ /firstname/text()“);规则 4.1.14：在 JavaBean 中禁止使用 property=“*“进行参数赋值。说明：property=“*“这表明用户在可见的 JSP 页面中输入的，或是直接通过Query String 提交的参数值，将存储到与参数名相匹配的 bean 属性中。例如，网上购物程序，一般，用户是这样提交请求的：http:/ /addToBasket.jsp?newItem=ITEM010534

27、2，如果用户提交：http:/ /addToBasket.jsp?newItem=ITEM0105342OutStr = OutStr.replaceAll(“);OutStr = OutStr.replaceAll(“,“);OutStr = OutStr.replaceAll(“,“);OutStr = OutStr.replaceAll(“,“);OutStr = OutStr.replaceAll(“(“,“);OutStr = OutStr.replaceAll(“)“,“);out.println(OutStr);%ASP.NET 语言可以通过 HtmlEncode 方法对 HTM

28、L 的输出进行编码。PHP 语言可以通过 htmlentities 或 htmlspecialchars 方法对 HTML 输出进行编码。4.3 上传下载规则 4.3.1：必须在服务器端采用白名单方式对上传或下载的文件类型、大小进行严格的限制。规则 4.3.2：禁止以用户提交的数据作为读/ 写/上传/下载文件的路径或文件名，以防止目录跨越和不安全直接对象引用攻击。说明：建议对写/上传文件的路径或文件名采用随机方式生成，或将写/上传文件放置在有适当访问许可的专门目录。对读/下载文件采用映射表（例如，用户提交的读文件参数为 1，则读取 file1，参数为 2，则读取 file2） 。防止恶意用户构

29、造路径和文件名，实施目录跨越和不安全直接对象引用攻击。规则 4.3.3：禁止将敏感文件（如日志文件、配置文件、数据库文件等）存放在Web 内容目录下。说明：Web 内容目录指的是：通过 Web 可以直接浏览、访问的目录，存放在Web 内容目录下的文件容易被攻击者直接下载。4.4 异常处理规则 4.4.1：应用程序出现异常时，禁止向客户端暴露不必要的信息，只能向客户端返回一般性的错误提示消息。说明：应用程序出现异常时，禁止将数据库版本、数据库结构、操作系统版本、堆栈跟踪、文件名和路径信息、SQL 查询字符串等对攻击者有用的信息返回给客户端。建议重定向到一个统一、默认的错误提示页面，进行信息过滤。

30、规则 4.4.2：应用程序捕获异常，并在日志中记录详细的错误信息。说明：记录详细的错误消息，可供入侵检测及问题定位。4.5 代码注释规则 4.5.1：在注释信息中禁止包含物理路径信息。规则 4.5.2：在注释信息中禁止包含数据库连接信息。规则 4.5.3：在注释信息中禁止包含 SQL 语句信息。规则 4.5.4：对于静态页面，在注释信息中禁止包含源代码信息。规则 4.5.5：对于动态页面不使用普通注释，只使用隐藏注释。说明：动态页面包括 ASP、PHP 、JSP、CGI 等由动态语言生成的页面。通过浏览器查看源码的功能，能够查看动态页面中的普通注释信息，但看不到隐藏注释（隐藏注释不会发送给客户

31、端） 。因此，为了减少信息泄漏，建议只使用隐藏注释。实施指导：4.6 归档要求规则 4.6.1：版本归档时，必须删除开发过程（包括现场定制）中的临时文件、备份文件、无用目录等。说明：恶意用户可以通过 URL 请求诸如.bak 之类的文件，Web 服务器会将这些文件以文本方式呈现给恶意用户，造成代码的泄漏，严重威胁 Web 应用的安全。实施指导：在 web 应用的根目录下执行以下命令：find ./ -name “*.old“ -o -name “*.OLD“ -o -name “*.bak“ -o -name “*.BAK“ -o -name “*.temp“ -o -name “*.tmp“

32、 -o -name “*.save“ -o -name “*.backup“ -o -name “*.orig“ -o -name “*.000“ -o -name “*“ -o -name “*1“ -o -name “*.dwt“ -o -name “*.tpl“ -o -name “*.zip“ -o -name “*.7z“ -o -name “*.rar“ -o -name “*.gz“ -o -name “*.tgz“ -o -name “*.tar“ -o -name “*.bz2“分析查找到的文件是否临时文件、备份文件、无用文件，如果是则删除。规则 4.6.2：归档的页面程序文

33、件的扩展名必须使用小写字母。说明：很多 Web server 对大小写是敏感的，但对后缀的大小写映像并没有做正确的处理。攻击者只要在 URL 中将 JSP 文件后缀从小写变成大写，Web 服务器就不能正确处理这个文件后缀，而将其当作纯文本显示。攻击者可以通过查看源码获得这些程序的源代码。因此，归档的页面程序文件的扩展名必须使用小写字母，如 jsp、html 、htm、asp 等页面程序文件的扩展名分别为jsp、 html、htm、asp。规则 4.6.3：归档的程序文件中禁止保留调试用的代码。说明：这里的“调试用的代码”是指开发过程中进行临时调试所用的、在 Web应用运行过程中不需要使用到的

34、Web 页面代码或 servlet 代码。例如：在代码开发过程中为了测试一个添加帐号的功能，开发人员临时编写了一个 JSP 页面进行测试，那么在归档时，该 JSP 页面必须删除，以免被攻击者利用。4.7 其他规则 4.7.1：对于 JSP 语言，所有 servlet 必须进行静态映射，不允许通过绝对路径访问。说明：在 web.xml 文件中为 servlet 配置 URI 映射，使用 servlet 时，引用它的URI 映射，而不允许通过绝对路径访问。规则 4.7.2：对客户端提交的表单请求进行合法性校验，防止跨站请求伪造攻击。说明：跨站请求伪造（CSRF ）是一种挟制终端用户在当前已登录的

35、Web 应用程序上执行非本意的操作的攻击方法。攻击者可以迫使用户去执行攻击者预先设置的操作，例如，如果用户登录网络银行去查看其存款余额，他没有退出网络银行系统就去了自己喜欢的论坛去灌水，如果攻击者在论坛中精心构造了一个恶意的链接并诱使该用户点击了该链接，那么该用户在网络银行帐户中的资金就有可能被转移到攻击者指定的帐户中。当 CSRF 针对普通用户发动攻击时，将对终端用户的数据和操作指令构成严重的威胁；当受攻击的终端用户具有管理员帐户的时候，CSRF 攻击将危及整个 Web 应用程序。实施指导：方法一：为每个 session 创建唯一的随机字符串，并在受理请求时验证/判断客户端提交的随机字符串是

36、否正确String randomStr = (String)request.getParameter(“randomStr“);if(randomStr = null) randomStr=“;if(randomStr.equals(request.getSession().getAttribute(“randomStr“)/处理请求else/跨站请求攻击，注销会话方法二：受理重要操作请求时，在相应的表单页面增加图片验证码，用户提交操作请求的同时提交验证码，在服务器端先判断用户提交的验证码是否正确，验证码正确再受理操作请求。方法三：向电信软件与核心网网络安全工程部申请 WAF CBB，并部署到

37、应用中，启用 AntiCSRF 功能，具体方法参考 WAF CBB 的用户手册。规则 4.7.3：使用 .innerHtml 时，如果只是要显示文本内容，必须在 innerHTML取得内容后，再用正则表达式去除 HTML 标签，以预防跨站脚本。说明：使用.innerHtml 会将内容以 HTML 显示，容易被利用，导致跨站脚本。实施指导：/gim,)“无 HTML,符合 W3C 标准备注：还可以使用.innerText 代替.innerHtml，.innerText 只显示文本内容不显示 HTML 标签，但 .innerText 不是 W3C 标准的属性，不能适用于所有浏览器（但适用于 IE

38、浏览器） 。规则 4.7.4：禁止使用 eval()函数来处理用户提交的字符串。说明：eval()函数存在安全隐患，该函数可以把输入的字符串当作 JavaScript 表达式执行，容易被恶意用户利用。 建议 4.7.1：关闭登录窗体表单中的自动填充功能，以防止浏览器记录用户名和口令。说明：浏览器都具有自动保存用户输入数据和自动填充数据的能力。为了保障用户名和口令的安全，必须关闭自动填充选项，指示浏览器不要存储登录窗口中用户名、口令等敏感信息。实施指导：在 form 表单头中增加选项（autocomplete=“off“） ，例如：建议 4.7.2：防止网页被框架盗链或者点击劫持。说明：框架盗链

39、和点击劫持（ClickJacking）都利用到框架技术，防范措施就是防止网页被框架。实施指导：方法一：在每个网页上增加如下脚本来禁止 iframe 嵌套：if(top != self) top.location.href = location.href;方法二：向电信软件与核心网网络安全工程部申请 WAF CBB，并部署到应用中，启用AntiClickjackMode 功能，具体方法参考 WAF CBB 的用户手册。4.8 PHP规则 4.8.1：禁止使用 phpinfo()。说明：phpinfo()函数提供了详细的服务器 PHP 环境配置信息，是 PHP 提供的一个比较方便的排错工具。但是往

40、往因为开发人员的一时疏忽，把带有phpinfo()的页面部署到生产环境上，造成严重的信息泄露，给潜在攻击者提供了很大的便利。因此在生产环境中应禁止使用 phpinfo()函数，以避免不必要的安全隐患。实施指导：修改 php.ini 文件中的 disable_functions 配置项，把“phpinfo ”添加到清单中：disable_functions=phpinfo备注：如果要禁用多个函数，函数名之间用逗号隔开。规则 4.8.2：避免使用 eval()、exec()、passthru()、popen()、proc_open() 、system()、shell_exec() 、pcntl_e

41、xec()，如非得使用，必须对输入参数进行严格的输入校验（如：长度、范围、类型校验） ，并使用 escapeshellcmd() 、escapeshellarg()函数对其参数进行转义处理。说明：这些是 PHP 用于调用底层系统命令的函数，如对其参数过滤不严，将容易导致“系统命令执行”漏洞，使黑客轻易地执行系统命令并获得服务器的shell 权限。另外所谓的 webshell 会通过这些函数跟底层系统进行交互，因此关闭这些函数可有效地降低 webshell 的安全威胁。实施指导：1、当不使用这些函数时，需通过 disable_functions 配置项禁止这些函数的使用：修改 php.ini 文

42、件中的 disable_functions 配置项，把要禁用的函数添加到disable_functions 参数值中，多个函数，用逗号分开，例如：disable_functions=phpinfo,get_cfg_var，eval,exec,passthru,popen,proc_open,system,shell_exec,pcntl_exec2、当使用这些函数时，应使用 escapeshellcmd()或 escapeshellarg()对其参数进行过滤。escapeshellcmd()：escapeshellarg()：规则 4.8.3：在使用 include()、include_onc

43、e()、require()、require_once()、show_source()、highlight_file()、readfile()、file_get_contents()、fopen()、file()等文件读取函数时，应对参数进行严格的合规性检查，避免直接使用客户端输入作为参数，必要时应进行白名单限制。说明：对这些函数的参数检查不严会很容易导致远程命令执行漏洞，给系统带来不必要的安全隐患。实施指导：$lang = preg_replace(/a-zA-Z0-9_/, , $_GETlang);switch ($lang):case “en” :include(“en.php”);ca

44、se “cn”:include(“cn.php”);default:include(“cn.php”);endswitch;建议 4.8.4：避免使用 preg_replace()函数。当使用/e 修饰符，preg_replace 会将 replacement 参数当作 PHP 代码执行，如使用不当将容易引入漏洞，建议使用 preg_match()替代。规则 4.8.5：明确使用 $_GET、$_POST、$_COOKIE 而不是$_REQUEST 获取用户请求数据，这有助于降低漏洞被成功利用的概率。5 Web 安全配置规范根据 Web 应用所选用的 Web 容器，按照相应的配置规范进行安全配

45、置，当前可供使用的安全配置规范如下：表 3 Web 容器安全配置规范列表规范名称IIS 安全配置规范Apache 安全配置规范Tomcat 安全配置规范JBoss 安全配置规范Resin 安全配置规范WebLogic 安全配置规范6 配套 CBB 介绍6.1 WAF CBB 提供功能：1) 防范 CSRF（跨站请求伪造）攻击2) 防范 XSS 攻击3) 防范 MML 注入4) 防范目录遍历/路径遍历5) 防范字符串型的 SQL 注入攻击（绝大部分的 SQL 注入为字符串型的）6) 防范空字符注入7) 防范点击劫持8) 防范 HTTP 会话劫持9) 防范功能可配置（也就是可以通过配置项开启或关闭

46、对应的防范功能）10) URI 白名单功能，允许配置免检的 URI。11) 输入校验：可以为各输入参数配置输入校验规则（正则表达式） ，在服务器端实现严格的输入校验。 获取方法：WAF CBB 支持人员：何伟祥（00162822）6.2 验证码 CBB 提供功能：实现了“3.2.3 验证码”的要求。 获取方法：验证码 CBB 支持人员：何伟祥（00162822）7 附件7.1 附件 1 Tomcat 配置 SSL 指导7.2 附件 2 Web Service 安全接入开发指导7.3 附件 3 客户端 IP 鉴权实施指导7.4 附件 4 口令安全要求 7.57.67.7 附件 5 Web 权限管理设计规格说明书