一、SQL注入漏洞

漏洞说明

SQL注入攻击是Web安全领域中一种最为常见的攻击方式，其本质是将用户输入的数据当做SQL语句代码一部分执行。这些攻击通常是发生在将不可信的数据作为命令或查询语句的一部分，拼接到程序代码中，作为可执行程序的一部分指令执行，从而执行了计划外的命令，或访问了未被授权的数据。要解决注入攻击，必须遵循 “数据与代码分离”的基本原则。

解决方案

1．对SQL调用，要求所有的SQL语句及存储过程的执行，都使用预编译语句绑定变量，禁止将参数通过字符串拼装的方式组合到SQL语句中。

2.变量在传入SQL执行之前需要通过数据校验。

3.必须将所有SQL拼装参数，不能有1=1或是value ='" + value + "'"等之类的代码。

二、跨站脚本攻击（跨站点脚本编制）

漏洞说明

跨站脚本攻击，英文全称Cross Site Script，简称XSS。是指通过HTML注入，篡改了网页，插入了恶意脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。

XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括Java， VBScript， ActiveX， Flash 或者甚至是普通的HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。

XSS攻击类型可分为：

• 反射型XSS：只是简单的把用户输入的数据“反射”给浏览器，需要用户点击过一个恶意链接后才能攻击成功，所有的代码及攻击都是在客户端完成，也称为“非持久型XSS”。
• 存储型XSS：把恶意代码脚本存储在服务端，当用户访问系统时，在浏览器中生成并执行恶意代码，也称为“持久型XSS”。
• DMO Based XSS：通过修改页面的DOM节点形成的XSS。

XSS其本质是一种“HTML”注入技术，用户输入的数据被当做了HTML代码的一部分被执行，从而使代码原来的意图发生变化，XSS攻击都是发生在View层，因此仅仅对用户提交的数据进行检查还不能完全解决问题。

由于可能引起XSS的漏洞很多，要防范XSS攻击，必须在开发阶段就从服务端、客户端、输入、输出等多个方面入手解决。

解决方案

1.对所有页面，统一设置UTF-8字符集编码：

<meta http-equiv="content-type" content="text/html;charset=UTF-8" />

2.对特殊字符的过滤：

通过实现filter过滤器的方式处理一些敏感的、非法字符和关键字，并且需要在服务端的代码中实现对用户输入的校验，输入校验必须实现对以下特殊字符的校验或是编码转义：

3.会话Cookie中缺少httponly属性，会话cookie中缺少HttpOnly属性会导致攻击者可以通过程序(JS脚本、Applet等)获取到用户的Cookie信息，造成用户Cookie信息泄露，增加攻击者的跨站脚本攻击威胁。

解决办法：

1）需要先确定现场应用服务器weblogic版本是否为9.2.3以上版本，才会对以下增加的内容生效。

2）对SessionID，在web/WEB-INF目录下增加weblogic.xml文件，如果已经存在此文件，将SessionID的Cookie增加HttpOnly属性，如下配置：

<session-descriptor>
    <cookie-http-only>false</cookie-http-only> ---为增加内容
</session-descriptor>

需要重启应用服务器

4.对自定义Cookie，在J2EE中，为Cookie添加HttpOnly的代码如下：response.setHeader(“Set-Cookie”,”name=value;HTTPOnly”);

 5. 将代码输出到客户端时，按照变量输出位置的不同，分别采用不同的编码方式对输出变量值进行编码。

• 在HTML标签中输入变量时，先将变量HtmlEncode
• 在HTML属性中输出变量时，先将变量HtmlEncode
• 在<script>标签中输出变量时，先将变量JavascriptEncode
• 在HTML事件中输出变量时，先将变量JavascriptEncode

三、加密会话（SSL）Cookie 中缺少 Secure 属性

漏洞说明

服务器开启了HTTPS时，Cookie的Secure属性未设置true。

解决方案

1.修改app/web/WEB-INF/weblogic.xml[Y1] 文件，其增加：

<session-descriptor>

<cookie-secure >true</cookie-secure >

</session-descriptor>

需要重启应用服务器

2.后端对Cookie进行设置：cookie.Secure = true：

HttpServletResponse response = (HttpServletResponse)response; var cookie = new HttpCookie(key, value);

cookie.HttpOnly = true;

cookie.Path = "/";

cookie.Secure = true;

response.AppendCookie(cookie);

四、已解密的登陆请求

漏洞说明

严重性：高

类型：应用层漏洞

安全风险：敏感数据没有通过https协议请求，导致可能会窃取用户名、用户密码等未经加密就发送了用户登陆的信息。

解决方案

1.通过SSL传输密码，需要实现HTTPS协议传输数据，可以通过平台提供的配置功能，将对应的URL配置为通过HTTS访问，配置如下：

修改appwebWEB-INFconfig目录下的pt-filter-manager.xml 文件在paramtername=“enterHttpsURLs”节点的value属性中增加需要通过https访问的页面路径。

2.对密码进行加密传输，密码必须以不可逆的加密算法进行加密，将加密后的密码存储在数据库中，禁止直接存储明文密码。加密算法应采用MD5、SHA等不可逆的加密算法。

五、会话定置（会话标识未更新）

漏洞说明

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

解决方案

1. SessionID长度不能低于64位，使用128位长度的SessionID。
2. 当用户客户端发生变化，如IP、UserAgent等信息发生变化时，强制摧毁当前Session，要求用户重新登录。
3. 在用户认证成功后应先将之前的用户会话销毁，然后重新为用户生成新的会话，保证认证成功前后，用户会话 ID 不一样，防止用户操作会话标识，请勿使用用户浏览器登陆时所提供的会话标识。如“修改密码”、“用户登陆“功能。
4. 设置Session最长存活时间，当Session存活时间超过某个值时，强制注销要求重新登录。
5. 每次请求登陆的action或servlet时清空Cookie 生成新的Session，java代码如下： 

try { 

    request.getSession(true).invalidate();//清空session       

    if (request.getCookies() != null) { 

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

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

    } 

} catch (Exception e) { 

      e.printStackTrace(); 

} 

session = request.getSession(true);

六、链接注入（便于跨站请求伪造）--跨站请求伪造

漏洞说明

跨站点请求伪造CSRF的英文全名为：Cross Site Request Forgery，也属于Web应用中一种常见的攻击方式。

通过CSRF漏洞，攻击者诱使用户在第三方站点的页面执行操作，将请求发送到目标站点，通过用户的身份在目标站点中执行了计划外的操作。

CSRF漏洞攻击成功的一个关键是猜测出URL的参数和参数值，构造出伪造的请求，因此只要让攻击者无法猜测出URL的参数和参数值，即可避免用户遭受CSRF攻击。

解决方案

1. Token验证：

1）在用户刚登陆的时候，可以产生一个新的CSRV Token，并且把Token存到用户的session中。

2）在一个需要保护的表单中，增加一个隐藏的字段来存放这个Token，对于需要保护的URL，增加一个参数来存放此Token。

3）相关的URL的业务操作中加入token验证，URL权限判断依据:

         ①cookie中的用户账号字段；

      ②自定义的随机id，写入cookie，或渲染到页面上，或保存于URL中；

      ③来自于URL中的id；

4）在提交请求时，携带此Token到服务端，与用户保存在session中的Token进行验证，如果一致，则继续处理请求，否则返回一个较友好错误信息给用户。

5）在用户退出或者session过期的时候，用户信息（包括CSRF Token）也需要从session中移除并且销毁session。

生成CSRF Token的示例代码：

private String csrfToken = resetCSRFToken();

         public String resetCSRFToken(){

       String csrfToken = ESAPI.randomizer().getRandomString(8,DefaultEncoder.CHAR_ALPHANUMBERICS);

return csrfToken;

}

提供需要CSRF保护的URL链接调用，示例代码：

final static String CSRF_TOKEN_NAME = “ctoken”;

public String addCSRFToken(String url){

       User user = ESAPI.authenticator().getCurrentUser();

  if(user.isAnonymous()){

              return url;

}

String token = CSRF_TOKEN_NAME + “=” + user.getCSRFToken();

return url.indexOf(‘?’) !=-1 ? url +”&” + token : url + “?” +token;

}

public String getCSRFToken(){

       User user = ESAPI.authenticator().getCurrentUser();

       if(user == null){ return null;}

  return user.getCSRFToken();

}

提交到服务器的Token与session中的Token验证示例代码：

public void verifyCSRFToken(HttpServletRequest request)throws IntrusionException{

       User user = ESAPI.authenticator().getCurrentUser();

  if(request.getAttribute(user.getCSRFToken() !=null){

              return ;

       }

       String token = request.getParameter(CSRF_TOKEN_NAME);

  if(!user.getCSRFToken().equals(token)){

        throw new IntrusionException(“error!”);

}

}

用户退出或者session过期，CSRF Token移除，下次登录需要产生新的Token，代码示例：

public void logout(){

ESAPI.httpUtilities().killCoolie(ESAPI.currentRequest(),ESAPI.currentReponse,HTTPUtilities.REMEMBER_TOKEN_COOKIE_NAME);

  HttpSession session = ESAPI.currentRequest().getSession(false);

  if(session !=null){

              removeSession(session);

    session.invalidate();

}

ESAPI.httpUtilities.killCookie(ESAPI.currentRequest(),ESAPI.currentResponse(),”JESSIONID”);

loggedIn = false;

ESAPI.authenticator().setCurrentUser(User.ANONYMOUS);

}

1. 二次验证：

对一些非常重要的操作，可以采用操作请求执行之前，对当前用户做二次验证的方式防止CSRF攻击。

七、通过框架钓鱼

漏洞说明

利用目标网站的反射型XSS跨站脚本漏洞和保存性XSS漏洞将一段恶意的脚本代码提交到web服务器上，或者把一个同样含有恶意脚本代码的web站点的URL链接发给目标用户，而这些恶意脚本将用户引诱一个精心设计的钓鱼网站上或者直接构造一个收集用户信息的表单，当个人用户访问了含有恶意脚本代码的页面或者打开收到的URL链接时，恶意脚本就会被执行，从而遭受钓鱼攻击。

解决方案

采用1.2的解决方案。

八、支持弱 SSL 密码套件

漏洞说明

攻击者无需本地网络访问及身份验证，即可利用此漏洞解密客户端和服务器之间的通讯，或在客户端上执行中间人攻击，从而获取敏感信息，执行未授权操作。

解决方案

通过配置SSL的方式，请求HTTPS协议时，必须使用域名的方式才起作用。