AppScan扫描建议 问题集

时间  2019-11-15
标签 appscan 扫描 建议 问题 繁體版
原文   原文链接

1.1        AppScan扫描建议

若干问题的补救方法在于对用户输入进行清理。 
经过验证用户输入未包含危险字符，即可能防止恶意的用户致使应用程序执行计划外的任务，例如：启动任意 SQL 查询、嵌入将在客户端执行的 Javascript 代码、运行各类操做系统命令，等等。 
建议过滤出全部如下字符：html

[1] |（竖线符号）java

[2] & （& 符号）程序员

[3];（分号）web

[4] $（美圆符号）算法

[5] %（百分比符号）spring

[6] @（at 符号）shell

[7] '（单引号）数据库

[8] "（引号）编程

[9] \'（反斜杠转义单引号）浏览器

[10] \"（反斜杠转义引号）

[11] <>（尖括号）

[12] ()（括号）

[13] +（加号）

[14] CR（回车符，ASCII0x0d）

[15] LF（换行，ASCII0x0a）

[16] ,（逗号）

[17] \（反斜杠）

如下部分描述各类问题、问题的修订建议以及可能触发这些问题的危险字符： 
SQL 注入和 SQL 盲注： 
A. 确保用户输入的值和类型（如 Integer、Date 等）有效，且符合应用程序预期。 
B. 利用存储过程，将数据访问抽象化，让用户不直接访问表或视图。当使用存储过程时，请利用 ADO 命令对象来实施它们，以强化变量类型。 
C. 清理输入以排除上下文更改符号，例如：

[1] '（单引号）

[2] "（引号）

[3] \'（反斜线转义单引号）

[4] \"（反斜杠转义引号）

[5] )（结束括号）

[6] ;（分号）

跨站点脚本编制： 
A. 清理用户输入，并过滤出 JavaScript 代码。咱们建议您过滤下列字符：

[1] <>（尖括号）

[2] "（引号）

[3] '（单引号）

[4] %（百分比符号）

[5] ;（分号）

[6] ()（括号）

[7] &（& 符号）

[8] +（加号）

B. 若是要修订 <%00script> 变体，请参阅 MS 文章 821349 
C. 对于 UTF-7 攻击： [-] 可能的话，建议您施行特定字符集编码（使用 'Content-Type' 头或 <meta> 标记）。 
HTTP 响应分割：清理用户输入（至少是稍后嵌入在 HTTP 响应中的输入）。 
请确保输入未包含恶意的字符，例如：

[1] CR（回车符，ASCII0x0d）

[2] LF（换行，ASCII0x0a）远程命令执行：清理输入以排除对执行操做系统命令有意义的符号，例如：

[1] |（竖线符号）

[2] & （& 符号）

[3];（分号）

执行 shell 命令： 
A. 毫不将未检查的用户输入传递给 eval()、open()、sysopen()、system() 之类的 Perl 命令。 
B. 确保输入未包含恶意的字符，例如：

[1] $（美圆符号）

[2] %（百分比符号）

[3] @（at 符号）

XPath 注入：清理输入以排除上下文更改符号，例如：

[1] '（单引号）

[2] "（引号） 等

LDAP 注入： 
A. 使用正面验证。字母数字过滤（A..Z,a..z,0..9）适合大部分 LDAP 查询。 
B. 应该过滤出或进行转义的特殊 LDAP 字符：

[1] 在字符串开头的空格或“#”字符

[2] 在字符串结尾的空格字符

[3] ,（逗号）

[4] +（加号）

[5] "（引号）

[6] \（反斜杠）

[7] <>（尖括号）

[8] ;（分号）

[9] ()（括号）

MX 注入： 
应该过滤出特殊 MX 字符：

[1] CR（回车符，ASCII0x0d）

[2] LF（换行，ASCII0x0a）记录伪造：

应该过滤出特殊记录字符：

[1] CR（回车符，ASCII0x0d）

[2] LF（换行，ASCII0x0a）

[3] BS（退格，ASCII0x08）

ORM 注入： 
A. 确保用户输入的值和类型（如 Integer、Date 等）有效，且符合应用程序预期。 
B. 利用存储过程，将数据访问抽象化，让用户不直接访问表或视图。 
C. 使用参数化查询 API 
D. 清理输入以排除上下文更改符号，例如： (*)：

[1] '（单引号）

[2] "（引号）

[3] \'（反斜线转义单引号）

[4] \"（反斜杠转义引号）

[5] )（结束括号）

[6] ;（分号）

1.2  应用程序解决方案

一、咱们为了调试方便，在页面上会抛出数据库异常信息，若是入侵工具获取了这些信息，就能够获取系统的一些配置信息，如web系统框架、采用的数据库等，从而找出系统漏洞。因此不要在页面上抛出异常的详细信息，这些信息对客户并无用，只是方便技术人员调试罢了，处理方法是在异常处理页面把打印异常代码删除便可；

二、新建一个过滤器，经过过滤器过滤SQL注入特殊字符，配置成功后，重启服务，用Appsan工具扫描，漏洞获得解决，经过过滤器能够解决SQL注入、跨站点脚本编制及经过框架钓鱼等问题，具体实现方式以下：

一、在web.xml文件中配置过滤器

    <filter-mapping>

       <filter-name>requestEncodingFilter</filter-name>

       <url-pattern>/*</url-pattern>

    </filter-mapping>

   <filter>

       <filter-name>InjectFilter</filter-name>

       <filter-class>com.sitech.ismp.util.context.InjectFilter</filter-class>

    </filter>

二、过滤器过滤代码

 public class InjectFilter extendsIsmpServletFilter {

 

    private String failPage ="/loginout.jsp";//发生注入时，跳转页面

 

    publicvoid doFilter(ServletRequest request,ServletResponse response,

        FilterChain filterchain)throwsIOException, ServletException {

        //判断是否有注入攻击字符

        HttpServletRequest req = (HttpServletRequest)request;

        Stringinj = injectInput(req);

       if(!inj.equals("")) {

            request.getRequestDispatcher(failPage).forward(request,response);

            return;

        } else {

           // 传递控制到下一个过滤器

        filterchain.doFilter(request,response);

        }

    }

   

   /**

    * 判断request中是否含有注入攻击字符

    * @param request

    * @return

    */

    publicString injectInput(ServletRequest request) {

       

        Enumeration e =request.getParameterNames();

        String attributeName;

        String attributeValues[];

        String inj = "";

       

        while (e.hasMoreElements()) {

        attributeName= (String)e.nextElement();

        //不对密码信息进行过滤，通常密码中能够包含特殊字符

        if(attributeName.equals("userPassword")||attributeName.equals("confirmPassword")||attributeName.equals("PASSWORD")

            ||attributeName.equals("password")||attributeName.equals("PASSWORD2")||attributeName.equals("valiPassword")){

            continue;

        }

       

        attributeValues= request.getParameterValues(attributeName);

        for(int i = 0; i < attributeValues.length; i++) {

           

    if(attributeValues[i]==null||attributeValues[i].equals(""))

                continue;

            inj= injectChar(attributeValues[i]);

            if(!inj.equals("")) {

                returninj;

            }

        }

        }  

    return inj;

    }

   

   /**

    * 判断字符串中是否含有注入攻击字符

    * @param str

    * @return

    */

    publicString injectChar(String str) {

   

      String inj_str = "\" ) \' * %";

      String inj_stra[] = inj_str.split(" ");

   

      for (int i = 0 ; i < inj_stra.length ; i++ )

      {

          if (str.indexOf(inj_stra[i])>=0)

          {

               return inj_stra[i];

          }

      }

      return "";

    }

 

   

}

 

2          会话标识未更新

2.1        会话标识未更新概述

“会话固定”是一种攻击技术，会强制用户的会话标识变成显式值。 固定会话标识值的技术有许多种，会随着目标Web 站点的功能而不一样。从利用“跨站点脚本编制”到向Web 站点密集发出先前生成的 HTTP 请求，都在这些技术范围内。用户的会话标识固定以后，攻击者会等待用户登陆，而后利用预约义的会话标识值来假定用户的联机身份。 
   通常而言，对于标识值的会话管理系统有两种类型。第一种类型是“宽容”系统，可以让 Web 浏览器指定任何标识。第二种类型是“严格”系统，只接受服务器端生成的值。当使用宽容系统时，不须要联系 Web 站点，即可以维护任何会话标识。在严格系统中，攻击者须要维护“陷阱会话”而且必须按期联系 Web 站点，才能防止闲置超时。对于会话固定，假若没有活动保护，使用会话来识别已认证的用户的任何 Web 站点均可能受到攻击。使用会话标识的 Web 站点一般都是基于cookie 的站点，但也会使用 URL 和隐藏的表单字段。不幸的是，基于 cookie 的会话最容易受到攻击。 目前已识别的大多数攻击方法都是针对 cookie 的固定。 相对于在用户登陆 Web 站点以后，再窃取用户的会话标识，会话固定提供的机会多得多。 
在用户登陆以前，攻击的活动部分便已启动。 
会话固定攻击过程一般由三个步骤组成： 
1) 安装会话 
攻击者针对目标 Web 站点设下“陷阱会话”，并获取这个会话的标识，攻击者也能够选择攻击中所用的任意会话标识。在某些状况下，必须反复联系 Web 站点，才能维护肯定好的陷阱会话值。 
2) 固定会话 
攻击者将陷阱会话值引进用户的浏览器中，固定用户的会话标识。 
3) 进入会话 
用户登陆目标 Web 站点以后，当使用固定会话标识值时，攻击者即可加以接管。”

 

2.2        安全风险及缘由分析

高风险漏洞，可能会窃取或操纵客户会话和 cookie，它们可能用于模仿合法用户，从而使黑客可以以该用户身份查看或变动用户记录以及执行事务

 

缘由：Web 应用程序编程或配置不安全

 

 

 

2.3        AppScan扫描建议

始终生成新的会话，供用户成功认证时登陆。 防止用户操纵会话标识。 
请勿接受用户浏览器登陆时所提供的会话标识

2.4        应用程序解决方案

 会话标识未更新，Appscan给出的描述是建议用户每次登陆时需使用新的会话标识。应用程序实现上就是在登陆模块，添加如下代码，即用户登陆后，从新生成会话。

HttpSession session = request.getSession(false);

if(session!=null){//让cookie过时

         session.invalidate();

         Cookie cookie = request.getCookies()[0];//获取cookie

         cookie.setMaxAge(0);//让cookie过时

}

request.getSession(true);//生成新会话

通过测试，这段代码只在weblogic和tomcat下才有效，在公司中间件webspeed及jboss6.0下问题都依然存在，但从扫描的结果信息分析看，漏洞已经解决，分析判断应该只是session处理机制不一样，AppScan工具仍认为存在漏洞风险。在与电信沟通中咱们存在一个经验教训你们必定要吸收，不能过渡迷信流行的自动化测试工具，尤为是对于Appscan这种判断防护行为的复杂软件，仅靠有限的规则设置就当作是web安全的惟一标准这显然不太合理，这种状况必定要与测试方沟通解释。

 另外一方面，对于公司的产品webspeed，也想提点建议，商务项目采用公司的产品为公司节约了很多成本，可是咱们产品后续升级维护也必须重视起来，当确认出是webspeed自己问题后，联系vasg相关人员进行协调解决，根本没有很是了解该产品技术人员支持，只是一个刚入职的同事在配合测试。调试了一周时间仍不能解决，最后只能做为一个遗留问题搁置。公司一直在向产品化转变，可是自身的产品维护、升级、管理仍然须要改进。

3          已解密登陆请求

3.1        已解密登陆请求概述

在应用程序测试过程当中，检测到将未加密的登陆请求发送到服务器。因为登陆过程所用的部分输入字段（例如：用户名、密码、电子邮件地址、社会保险号码，等等）是我的敏感信息，建议经过加密链接（如 SSL）将其发送到服务器。任何以明文传给服务器的信息均可能被窃，稍后可用来电子欺骗身份或假装用户。 此外，若干隐私权法规指出，用户凭证之类的敏感信息一概以加密方式传给网站。

3.2        安全风险及缘由分析

安全风险中，可能会窃取诸如用户名和密码等未经加密即发送了的用户登陆信息

缘由：诸如用户名、密码和信用卡号之类的敏感输入字段未经加密即进行了传

递

3.3        AppScan扫描建议

1. 确保全部登陆请求都以加密方式发送到服务器。 
2. 请确保敏感信息，例如：

- 用户名

- 密码

- 社会保险号码

- 信用卡号码

- 驾照号码

- 电子邮件地址

- 电话号码

- 邮政编码


一概以加密方式传给服务器。

3.4        应用程序解决方案

 已解密的登陆请求，要求就是数据要加密传输。最简单有效的解决方式采用SSL加密协议传输，可是因为EMA服务管理平台业务的特殊性，采用SSL加密方式对现有的业务影响太大，因此最终没有采用此种方式解决该问题，但我的在进行测试过程当中也尝试在tomcat和jboss下SSL方式配置，写下来供参考。

Jboss内核也是tomcat，因此二者配置基本都是同样，都是在生成证书文件后，在service.xml 进行配置：

1.  进入到cmd 进入到jdk bin目录下执行keytool-genkey -alias tomcat -keyalg RSA -keystore webspeed.keystore 生成证书

2.  在service.xml配置SSL

    <Connector port="8443"maxHttpHeaderSize="8192"

               maxThreads="150"minSpareThreads="25" maxSpareThreads="75"

               enableLookups="false"disableUploadTimeout="true"

               acceptCount="100"scheme="https" secure="true"

               clientAuth="false"sslProtocol="TLS"

              keystoreFile="C:\tomcat-5.5.26\conf\webspeed.keystore"  keystorePass="1111aaaa"/>

这样配置后虽然能够经过https访问，但仍然还能够经过8080使用普通的http访问，因此还必须禁止普通模式登陆。因此还得在web.xml添加配置。

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

<security-constraint>

  

<!-- Authorization setting for SSL -->

  

<web-resource-collection >

  

<web-resource-name >SSL</web-resource-name>

  

<url-pattern>*.jsp</url-pattern>

  

<url-pattern>*.action</url-pattern>

  

</web-resource-collection>

  

<user-data-constraint>

  

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

  

</user-data-constraint>

  

</security-constraint>

  

<login-config>

  

<!-- Authorization setting for SSL -->

  

<auth-method>CLIENT-CERT</auth-method>

  

<realm-name>Client Cert Users-only Area</realm-name>

  

</login-config>

 应注意，因为项目的一些组件没法经过https，所以url-pattern字段只对.jsp和.action进行了限制，若是不作特定限制，则系统默认是所有使用https传输。并且上述设置一旦在某个工程中出现，那么当前tomcat将全局采用这一配置。

 

 

 

4          跨站点请求伪造

4.1        跨站点请求伪造概述

“跨站点伪造请求(CSRF)”攻击可以让黑客以受害者的名义在易受攻击的站点上运行操做。当易受攻击的站点未适当验证请求来源时，即可能出现这个攻击。这个漏洞的严重性取决于受影响的应用程序的功能，例如，对搜索页面的 CSRF 攻击，严重性低于对转账页面或概要更新页面的 CSRF 攻击。 
这项攻击的执行方式，是强迫受害者的浏览器向易受攻击的站点发出 HTTP 请求。若是用户目前已登陆受害者站点，请求会自动使用用户的凭证（如会话 Cookie、用户的 IP 地址，以及其余浏览器认证方法）。攻击者利用这个方法来伪造受害者的身份，再代替他来提交操做。换句话来讲，易受攻击的站点未采起适当措施来验证用户实际是否想执行特定操做。 
强迫受害者发送非预期的请求，方法有许多种： 
- 经过电子邮件向受害者发送易受攻击应用程序的恶意连接。 - 在黑客的 Web 页面上，放置一个易受攻击的 Web 站点的热连接（如图像或帧）。 - 在公共论坛中，张贴易受攻击站点的连接。 
- 利用站点（或另外一个站点）的“跨站点脚本编制”或“连接注入”漏洞，将浏览器自动重定向到易受攻击的站点。 
若是攻击者利用易受攻击的站点自己的“连接注入”漏洞，能够增长用户经过站点认证的可能性，进而增长攻击成功的可能性。 
例如，攻击者能够利用上述任何选项来诱惑受害者查看含有下列条目的页面： 
<img src="http://bank/transfer?destination=John&money=1000"style='visibility:hidden'> 

这会使受害者的浏览器自动请求 URL 及浏览器的当前凭证。若是这个银行业站点易受到 CSRF 攻击，它会根据应用程序逻辑，从受害者的账户中，将 1000 美圆转帐到 John 的银行账户。“跨站点伪造请求”攻击也称为 CSRF（发音为 C-Serf）、XSRF、“跨站点伪造引用”、“单键攻击”以及“会话骑乘”。 
您能够利用下列方式来验证您的应用程序是否易受到 CSRF 攻击： 
[1] 检查易受攻击的连接/请求是否未包括攻击者难以猜中的参数
[2] 检查易受攻击的连接/请求是否会执行只应自愿执行的操做 
含有用户在不知不觉中提交的请求所能直接访问的敏感操做的应用程序，被视为很容易遭受 CSRF 攻击。CSRF 也可能出如今登陆页面和注销页面上。因为攻击者能够伪造来自受害者的连续注销请求，所以 CSRF 可能致使服务拒绝。在登陆页面上，CSRF 能够容许攻击者使用包含攻击者用户名和密码的伪造请求来将客户机登陆到攻击者的帐户中。登陆 CSRF 攻击会带有严重的后果，这取决于其余站点行为。例如，若是站点保留了用户操做的历史记录（例如搜索历史记录），那么攻击者将可以在易受攻击的站点上查看受害者以前执行的操做。

4.2        安全风险及缘由分析

安全风险中，可能会窃取或操纵客户会话和cookie，它们可能用于模仿合法用户，从而使黑客可以以该用户身份查看或变动用户记录以及执行事务

缘由：应用程序使用的认证方法不充分

4.3        AppScan扫描建议

若是要避免 CSRF 攻击，每一个请求都应该包含惟一标识，它是攻击者所没法猜想的参数。建议的选项之一是添加取自会话 cookie 的会话标识，使它成为一个参数。服务器必须检查这个参数是否符合会话cookie，若不符合，便废弃请求。 攻击者没法猜想这个参数的缘由是应用于 cookie 的“同源策略”，所以，攻击者没法伪造一个虚假的请求，让服务器误觉得真。攻击者难以猜想且没法访问的任何秘密（也就是没法从其余域访问），均可用来替换会话标识。这能够防止攻击者设计看似有效的请求。

 

登陆的跨站点请求解决代码：

  1 package com.tyky.cas.web.filter;
  2 
  3 import java.security.MessageDigest;
  4 import java.security.NoSuchAlgorithmException;
  5 import java.util.HashMap;
  6 import java.util.Map;
  7 import java.util.UUID;
  8 
  9 import javax.servlet.http.HttpServletRequest;
 10 import javax.servlet.http.HttpSession;
 11 
 12 import org.slf4j.Logger;
 13 import org.slf4j.LoggerFactory;
 14 import org.springframework.stereotype.Controller;
 15 import org.springframework.util.StringUtils;
 16 import org.springframework.web.bind.annotation.RequestMapping;
 17 
 18 @Controller
 19 @RequestMapping("/csrf/token")
 20 public class CSRFTokenGeneration {
 21     private static final Logger logger = LoggerFactory.getLogger(RegisterIndexSessionFilter.class);
 22     // 获取token值
 23     public static String getTokenKey(HttpServletRequest request) {
 24 
 25         String key = null;
 26 
 27         try {
 28 
 29             MessageDigest mDigest = MessageDigest.getInstance("MD5");// 摘要算法能够本身选择
 30             logger.warn(" URL = " + request.getRequestURL().toString());
 31 
 32             byte[] result = mDigest.digest(request.getRequestURL().toString().getBytes());
 33 
 34             key = bytesToHexString(result);
 35 
 36             // key = StringUtil.bytes2hex(result);
 37 
 38         } catch (NoSuchAlgorithmException e) {
 39 
 40             logger.error("get token key failed", e);
 41 
 42         }
 43 
 44         return key;
 45 
 46     }
 47 
 48     public static String bytesToHexString(byte[] src) {
 49         StringBuilder stringBuilder = new StringBuilder("");
 50         if (src == null || src.length <= 0) {
 51             return null;
 52         }
 53         for (int i = 0; i < src.length; i++) {
 54             int v = src[i] & 0xFF;
 55             String hv = Integer.toHexString(v);
 56             if (hv.length() < 2) {
 57                 stringBuilder.append(0);
 58             }
 59             stringBuilder.append(hv);
 60         }
 61         return stringBuilder.toString();
 62     }
 63 
 64     public static String getTokenValue(HttpServletRequest request) {
 65 
 66         String key = getTokenKey(request);
 67 
 68         Map<String, String> tokenMap = null;
 69 
 70         Object obj = request.getSession().getAttribute("tokenMap");
 71 
 72         if (obj == null) {
 73 
 74             tokenMap = new HashMap<String, String>();
 75 
 76             request.getSession().setAttribute("tokenMap", tokenMap);
 77 
 78         } else {
 79 
 80             tokenMap = (Map<String, String>) obj;
 81 
 82         }
 83 
 84         if (tokenMap.containsKey(key)) {
 85 
 86             return tokenMap.get(key);
 87 
 88         }
 89 
 90         String value = UUID.randomUUID().toString();// GUID实现可自行百度，其实弄个伪随机数也是能够的...
 91 
 92         tokenMap.put(key, value);
 93 
 94         return value;
 95 
 96     }
 97 
 98     public static boolean verify(String key, String value, HttpServletRequest request) {
 99 
100         boolean result = false;
101 
102         if (StringUtils.isEmpty(key) || StringUtils.isEmpty(value)) {// key或value只要有一个不存在就验证不经过
103 
104             return result;
105 
106         }
107 
108         if (request.getSession() != null) {
109 
110             HttpSession session = request.getSession();
111             Map<String, String> tokenMap = (Map<String, String>) session.getAttribute("tokenMap");
112             // Map<String,String> tokenMap = getTokenMap(request);
113 
114             if (null != tokenMap && value.equals(tokenMap.get(key))) {
115 
116                 result = true;
117 
118                 tokenMap.remove(key);// 成功一次就失效
119 
120             }
121 
122         }
123 
124         return result;
125 
126     }
127 
128 }

html页面添加隐藏信息：

1     <input type="hidden" name="token_key" value="<%=com.tyky.cas.web.filter.CSRFTokenGeneration.getTokenKey(request) %>"/> 
2     <input type="hidden" name="token_value" value="<%=com.tyky.cas.web.filter.CSRFTokenGeneration.getTokenValue(request) %>"/>

添加过滤器：

 1   <filter>
 2         <filter-name>NewRegiseterIndxeFilter</filter-name>
 3         <filter-class>com.tyky.cas.web.filter.RegisterIndexSessionFilter</filter-class>
 4     </filter>
 5 
 6 
 7 <filter-mapping>
 8     <filter-name>NewRegiseterIndxeFilter</filter-name>
 9     <url-pattern>/login</url-pattern>
10   </filter-mapping>

 

 

 

4.4        应用程序解决方案

 已解密的登陆请求，要求就是数据要加密传输。最简单有效的解决方式采用SSL加密协议传输，可是因为EMA服务管理平台业务的特殊性，采用SSL加密方式对现有的业务影响太大，因此最终没有采用此种方式解决该问题，但我的在进行测试过程当中也尝试在tomcat和jboss下SSL方式配置，写下来供参考。

 

5          不充分帐户封锁

5.1        不充分帐户封锁概述

蛮力攻击是指恶意用户发送大量可能的密码和/或用户名以访问应用程序的尝试。 因为该技术包含大量登陆尝试，未限制容许的错误登陆请求次数的应用程序很容易遭到这类攻击。 所以，强烈建议您对账户限制容许的错误登陆尝试次数，超过该次数，便锁定该账户。样本利用： 
下列请求说明密码猜想请求：

http://site/login.asp?username=EXISTING_USERNAME&password=GUESSED_PASSWORD若是站点在若干次错误尝试以后并不锁定测试的账户，攻击者最终可能会发现账户密码，并使用它来假冒账户的合法用户。

5.2        安全风险及缘由分析

安全风险高，可能会升级用户特权并经过Web 应用程序获取管理许可权

缘由：Web 应用程序编程或配置不安全

 

5.3        AppScan扫描建议

请肯定容许的登陆尝试次数（一般是 3-5 次），确保超出容许的尝试次数以后，便锁定账户。 为了不真正的用户因账户被锁定而致电支持人员的麻烦，能够仅临时性暂挂账户活动，并在特定时间段以后启用账户。账户锁定大约 10 分钟，一般便足以阻止蛮力攻击。

 

5.4        应用程序解决方案

 根据扫描建议，web应用程序设定容许登陆尝试次数，登陆连续失败超过设定次数，就锁定用户，失败次数灵活配置。

 在用户登陆时进行验证：

       if(!encrypter.encrypt(userPassword).equalsIgnoreCase(

              user.getLOGIN_PASSWD()== null ? "" : user.getLOGIN_PASSWD()))

{

           //更新此用户登陆失败次数

           this.updateLoginFailTimes(userCode);

           //若是用户连续登陆失败次数超过配置值则将其锁定

           intloginLockTimes=this.getLoginLockTimes();

           if(this.getLoginFailTimes(userCode)>=loginLockTimes){

              this.lockUser(userCode);

           }

           thrownew MySecurityException("密码不正确! 用户:" + userCode);

       }

6          启用不安全HTTP方法

6.1        启用不安全HTTP方法概述

彷佛 Web 服务器配置成容许下列其中一个（或多个）HTTP 方法（动词）：
- DELETE 
- SEARCH 
- COPY 
- MOVE 
- PROPFIND 
- PROPPATCH 
- MKCOL 
- LOCK 
- UNLOCK 

这些方法可能表示在服务器上启用了 WebDAV，可能容许未受权的用户对其进行利用。

6.2        安全风险及缘由分析

安全风险中，可能会在 Web 服务器上上载、修改或删除 Web 页面、脚本和文件

 

缘由：Web 服务器或应用程序服务器是以不安全的方式配置的

 

6.3        AppScan扫描建议

若是服务器不须要支持 WebDAV，请务必禁用它，或禁止没必要要的 HTTP 方法（动词）。

 

6.4        应用程序解决方案

修改web工程中web.xml,增长安全配置信息，禁用没必要要HTTP方法

   <security-constraint> 

 

  <web-resource-collection> 

 

   <web-resource-name>HtmlAdaptor</web-resource-name> 

 

        <description>test</description> 

        <url-pattern>*.jsp</url-pattern>

        <url-pattern>*.do</url-pattern> 

        <http-method>GET</http-method> 

        <http-method>POST</http-method>

        <http-method>PUT</http-method> 

       <http-method>DELETE</http-method> 

       <http-method>HEAD</http-method> 

       <http-method>OPTIONS</http-method> 

       <http-method>TRACE</http-method>   

 

  </web-resource-collection><!-- 

 

  <auth-constraint> 

 

        <role-name>JBossAdmin</role-name> 

 

  </auth-constraint> 

 

  --></security-constraint>。

 

7          HTTP注释敏感信息

7.1        HTTP注释敏感信息概述

不少Web 应用程序程序员使用 HTML 注释，以在须要时帮助调试应用程序。尽管添加常规注释有助于调试应用程序，但一些程序员每每会遗留重要数据（例如：与 Web 应用程序相关的文件名、旧的连接或原非供用户浏览的连接、旧的代码片断等）。

7.2        安全风险及缘由分析

安全风险低，能会收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件位置

缘由：程序员在 Web 页面上留下调试信息

 

7.3        AppScan扫描建议

[1] 请勿在 HTML 注释中遗留任何重要信息（如文件名或文件路径）。 
[2] 从生产站点注释中除去之前（或将来）站点连接的跟踪信息。 
[3] 避免在 HTML 注释中放置敏感信息。 
[4] 确保 HTML 注释不包括源代码片断。 
[5] 确保程序员没有遗留重要信息。

。

 

7.4        应用程序解决方案

 虽然这个漏洞为低级别漏洞，但电信方也是要求必须修复，要修改此漏洞须要检查工程中的每个jsp页面，工做量仍是挺大。因此在后续开发过程当中注释尽可能写英文注释，尽可能不要遗留敏感注释信息在jsp代码中，养成良好的编码习惯才是解决问题根本。

 

转载自：http://blog.csdn.net/huoyunshen88/article/details/39181107

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程