Spring MVC防御CSRF、XSS和SQL注入攻击

解决CSRF的办法：客户端向服务器提交请求时，服务器一定要校验口令。
客户端指定页面要有服务器端提供的口令

本文说一下SpringMVC如何防御CSRF(Cross-site request forgery跨站请求伪造)和XSS(Cross site script跨站脚本攻击)。

说说CSRF

对CSRF来说，其实Spring3.1、ASP.NET MVC3、Rails、Django等都已经支持自动在涉及POST的地方添加Token（包括FORM表单和AJAX POST等），似乎是一个tag的事情，但如果了解一些实现原理，手工来处理，也是有好处的。因为其实很多人做web开发，但涉及到web安全方面的都是比较资深的开发人员，很多人安全意识非常薄弱，CSRF是什么根本没有听说过。所以对他们来说，CSRF已经是比较高深的东西了。先说说什么是CSRF？你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。CSRF一般都是利用你的已登录已验证的身份来发送恶意请求。比较著名的一个例子就是2009年黑客利用Gmail的一个CSRF漏洞成功获取好莱坞明星Vanessa Hudgens的独家艳照。其攻击过程非常简单，给该明星的gmail账户发了一封email，标题是某大导演邀请你来看看这个电影，里面有个图片：<img src="https://mail.google.com/mail?ui=2&fw=true&fwe=hacker@email.com">，结果她登录Gmail，打开邮件就默默无闻的中招了，所有邮件被转发到黑客的账号。因为当时Gmail设置转发的设置页面有漏洞，其设置方法是打开一个窗口，点击确定后实际URL是https://mail.google.com/mail?ui=2&fw=true&fwe=newMail@email.com:

 

其实即使不是在同一个页面打开，在不同的tab打开也是一样可以通过网站登录验证的，因为受害者首先已经登录了网站，在浏览网站的过程中，若网站设置了Session cookie，那么在浏览器进程的生命周期内，即使浏览器同一个窗口打开了新的tab页面，Session cookie也都是有效的，他们在浏览器同一个窗口的多个tab页面里面是共享的（注：现在Gmail支持多个tab同时持有多个SessionID）。所以攻击步骤是，第一，受害者必须在同一浏览器窗口（即使不是同一tab）内访问并登陆目标站点；第二，这使得Session cookie有效，从而利用受害者的身份进行恶意操作。 

再举个实际的例子，假设我们界面上有删除某一项的链接，例如：<a href="javascript:void(0)" onclick="region_del.do?name=0000001">Delete</a>；

其Java Spring MVC后台有个函数是删除某个item，注意是GET不是POST:

@RequestMapping(value = "region_del.do", method = RequestMethod.GET)
public String regionDel(@RequestParam String name, Locale locale)
{
    //Delete region name=@name....
        
    return "redirect:/region.html";
}

点击界面上那个<a href="javascript:void(0)" onclick="region_del.do?name=0000001">Delete</a>链接，就后台删除某项，看起来非常正常啊。 

好，现在你登录你的网站，然后在另外一个tab打开这个html文件：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>hack</title>
</head>
<body>
  <img src="http://localhost/testsite/region_del.do?name=0000001"/>
 </body>
</html>

发现同样被删除了某项。试想，如果是网银，你的钱已经被转账......（除了referer不一样，session cookie被利用）

 

好了，现在 后台改成POST（写操作尽量用POST），前台界面那个删除的链接改成Form提交：

<form action="region_del.do" method="POST">
 <input type="hidden" name="name" value="0000001">
        <input type="submit" value="Delete" />
</form>

看起来安全多了。OK，现在你登录你的网站，然后在另外一个tab打开这个html文件：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>Hack</title>
    <script>
      function steal(){
        var mySubmit = document.getElementById('steal_form');
        mySubmit.submit();
      }
    </script>
  </head>
  <body onload='steal()'>
<form id = "steal_form" method="POST" action="http://localhost/testsite/region_del.do">
   <input type="hidden" name="func" value="post">
<input type="hidden" name="name" value="0000001">
</form>
  </body>
</html>

 

发现同样被删除了某项。试想，如果是网银，你的钱已经被转账......

当然，你如果前台还是用链接，但改成js，用AJAX POST提交，也是一样的效果：

 

$.ajax({
 type: "POST",
 url:....
});

解决办法就是在Form表单加一个hidden field，里面是服务端生成的足够随机数的一个Token，使得黑客猜不到也无法仿照Token。 

先写一个类，生成足够随机数的Token（注：Java的Random UUID已经足够随机了，参考这个和这个） 

package com.ibm.cn.web.beans;

import java.util.UUID;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

/**
* A manager for the CSRF token for a given session. The {@link #getTokenForSession(HttpSession)} should used to
* obtain the token value for the current session (and this should be the only way to obtain the token value).
* ***/

public final class CSRFTokenManager {

    /**
     * The token parameter name
     */
    static final String CSRF_PARAM_NAME = "CSRFToken";

    /**
     * The location on the session which stores the token
     */
    public static final  String CSRF_TOKEN_FOR_SESSION_ATTR_NAME = CSRFTokenManager.class
            .getName() + ".tokenval";

    public static String getTokenForSession(HttpSession session) {
        String token = null;
        
        // I cannot allow more than one token on a session - in the case of two
        // requests trying to
        // init the token concurrently
        synchronized (session) {
            token = (String) session
                    .getAttribute(CSRF_TOKEN_FOR_SESSION_ATTR_NAME);
            if (null == token) {
                token = UUID.randomUUID().toString();
                session.setAttribute(CSRF_TOKEN_FOR_SESSION_ATTR_NAME, token);
            }
        }
        return token;
    }

    /**
     * Extracts the token value from the session
     * 
     * @param request
     * @return
     */
    public static String getTokenFromRequest(HttpServletRequest request) {
        return request.getParameter(CSRF_PARAM_NAME);
    }

    private CSRFTokenManager() {
    };

}

打开Form页面的时候在服务端生成Token并保存到Session中，例如：model.addAttribute("csrf", CSRFTokenManager.getTokenForSession(this.session));

然后在Form中添加Hidden field: 

<input type="hidden" name="CSRFToken" value="${csrf}" />

然后在后台提交的时候验证token ：

 

@RequestMapping(value = "region_del.do", method = RequestMethod.GET)
public String regionDel(@RequestParam String name, @RequestParam String CSRFToken, Locale locale)
    {
        if(CSRFToken == null || !CSRFToken.equals(session.getAttribute(CSRFTokenManager.CSRF_TOKEN_FOR_SESSION_ATTR_NAME).toString())){
                logger.debug("CSRF attack detected. URL: region_edit.do");
                return "redirect:/login.form";
        } 
                
    //Delete region name=@name....
        
    return "redirect:/region.html";
}

 

你还可以把上面的步骤写到BaseController里面，或者写到拦截器里面，拦截所有POST请求，验证CSRF Token。这里掠过....

如果你用AJAX POST的方法，那么后台一样，前台也要有Hidden field保存Token，然后在提交AJAX POST的时候加上该csrf参数即可。（更多csrf参考这个和这个。）

 

AJAX POST的CSRF防御

 

首先在页面进入的时候从后台生成一个Token（每个session），放到一个Hidden input（用Spring tag或freemarker可以写） 。然后在ajax post提交的时候放到http请求的header里面：

    var headers = {};
    headers['__RequestVerificationToken'] = $("#CSRFToken").val();
    
    $.ajax({
        type: "POST",
        headers: headers,
        cache: false,
        url: base + "ajax/domain/delete.do",
        data: "id=123",
        dataType:"json",
        async: true,
        error: function(data, error) {},
        success: function(data)
        {
            
        }
    });

然后在后台controller里面校验header里面这个token，也可以把这个函数放到baseController里面：

protected boolean isValidCsrfHeaderToken() {
        if (getRequest().getHeader("__RequestVerificationToken") == null
                || session
                        .getAttribute(CSRFTokenManager.CSRF_TOKEN_FOR_SESSION_ATTR_NAME) == null
                || !this.getRequest()
                        .getHeader("__RequestVerificationToken")
                        .equals(session
                                .getAttribute(
                                        CSRFTokenManager.CSRF_TOKEN_FOR_SESSION_ATTR_NAME)
                                .toString())) {
            return false;
        }
        return true;
    }

 

xss

跨站脚本（Cross site script，简称xss）是一种“HTML注入”，由于攻击的脚本多数时候是跨域的，所以称之为“跨域脚本”。

我们常常听到“注入”（Injection），如SQL注入，那么到底“注入”是什么？注入本质上就是把输入的数据变成可执行的程序语句。SQL注入是如此，XSS也如此，只不过XSS一般注入的是恶意的脚本代码，这些脚本代码可以用来获取合法用户的数据，如Cookie信息。

关于xss的介绍可以看这个和这个网页，具体我就讲讲Spring MVC里面的预防：

web.xml加上：

<context-param>
   <param-name>defaultHtmlEscape</param-name>
   <param-value>true</param-value>
</context-param>

Forms加上：

 

<spring:htmlEscape defaultHtmlEscape="true" />

 

更多信息查看OWASP的页面

 

第二种方法是手动escape，例如用户可以输入：<script>alert()</script> 或者输入<h2>abc<h2>，如果有异常，显然有xss漏洞。

首先添加一个jar包：commons-lang-2.5.jar ，然后在后台调用这些函数：StringEscapeUtils.escapeHtml(string); StringEscapeUtils.escapeJavaScript(string); StringEscapeUtils.escapeSql(string);

前台js调用escape函数即可。

 

第三种方法是后台加Filter，对每个post请求的参数过滤一些关键字，替换成安全的，例如：< > ' " \ /  # & 

方法是实现一个自定义的HttpServletRequestWrapper，然后在Filter里面调用它，替换掉getParameter函数即可。

首先添加一个XssHttpServletRequestWrapper:

package com.ibm.web.beans;

import java.util.Enumeration;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;

public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper {  
    public XssHttpServletRequestWrapper(HttpServletRequest servletRequest) {
        super(servletRequest);
    }
    public String[] getParameterValues(String parameter) {
      String[] values = super.getParameterValues(parameter);
      if (values==null)  {
                  return null;
          }
      int count = values.length;
      String[] encodedValues = new String[count];
      for (int i = 0; i < count; i++) {
                 encodedValues[i] = cleanXSS(values[i]);
       }
      return encodedValues;
    }
    public String getParameter(String parameter) {
          String value = super.getParameter(parameter);
          if (value == null) {
                 return null;
                  }
          return cleanXSS(value);
    }
    public String getHeader(String name) {
        String value = super.getHeader(name);
        if (value == null)
            return null;
        return cleanXSS(value);
    }
    private String cleanXSS(String value) {
                //You'll need to remove the spaces from the html entities below
        value = value.replaceAll("<", "& lt;").replaceAll(">", "& gt;");
        value = value.replaceAll("\\(", "& #40;").replaceAll("\\)", "& #41;");
        value = value.replaceAll("'", "& #39;");
        value = value.replaceAll("eval\\((.*)\\)", "");
        value = value.replaceAll("[\\\"\\\'][\\s]*javascript:(.*)[\\\"\\\']", "\"\"");
        value = value.replaceAll("script", "");
        return value;
    }

} 

然后添加一个过滤器XssFilter ：

package com.ibm.web.beans;

import java.io.IOException;  

import javax.servlet.Filter;  
import javax.servlet.FilterChain;  
import javax.servlet.FilterConfig;  
import javax.servlet.ServletException;  
import javax.servlet.ServletRequest;  
import javax.servlet.ServletResponse;  
import javax.servlet.http.HttpServletRequest;  
import javax.servlet.http.HttpServletResponse;

public class XssFilter implements Filter {
    FilterConfig filterConfig = null;

    public void init(FilterConfig filterConfig) throws ServletException {
        this.filterConfig = filterConfig;
    }

    public void destroy() {
        this.filterConfig = null;
    }

    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {
        chain.doFilter(new XssHttpServletRequestWrapper(
                (HttpServletRequest) request), response);
    }
}

最后在web.xml里面配置一下，所有的请求的getParameter会被替换，如果参数里面 含有敏感词会被替换掉：

  <filter>
     <filter-name>XssSqlFilter</filter-name>
     <filter-class>com.ibm.web.beans.XssFilter</filter-class>
  </filter>
  <filter-mapping>
     <filter-name>XssSqlFilter</filter-name>
     <url-pattern>/*</url-pattern>
     <dispatcher>REQUEST</dispatcher>
  </filter-mapping>

 (这个Filter也可以防止SQL注入攻击) 

 

登录页面的攻击例子

假设登录页面有个输入用户名和密码的输入框，可以有很多Xss/csrf/注入钓鱼网站/SQL等的攻击手段，例如：

 

 输入用户名 :    >"'><script>alert(1779)</script>
 输入用户名:     usera>"'><img src="javascript:alert(23664)">
 输入用户名:     "'><IMG SRC="/WF_XSRF.html--end_hig--begin_highlight_tag--hlight_tag--">
 输入用户名:     usera'"><iframe src=http://demo.testfire.net--en--begin_highlight_tag--d_highlight_tag-->

 

 

Web安全漏洞检测工具

推荐使用IBM Rational AppScan（IBM Rational AppScan下载、版权购买和破解、注册码自己解决）

 

可以录制脚本，设置URL，如果网站需要登录，可以设置自动登录：

 

检测结果还可以保持为专业的pdf检测报告 

 

 

业界安全编程标准最佳实践

 

http://www.cnblogs.com/Mainz/archive/2012/11/01/2749874.html

时间： 2024-10-29 23:11:30

Spring MVC防御CSRF、XSS和SQL注入攻击的相关文章

总结了关于PHP xss 和 SQL 注入的问题

漏洞无非这么几类,XSS.sql注入.命令执行.上传漏洞.本地包含.远程包含.权限绕过.信息泄露.cookie伪造.CSRF(跨站请求)等.这些漏洞不仅仅是针对PHP语言的,本文只是简单介绍PHP如何有效防止这些漏洞. 1.xss + sql注入(关于xss攻击详细介绍) 其中占大头的自然是XSS与SQL注入,对于框架类型或者有公共文件的,建议在公共文件中统一做一次XSS和SQL注入的过滤.用PHP写个过滤函数,可由如下所示: $_REQUEST = filter_xss($_REQUEST);

细谈php中SQL注入攻击与XSS攻击_php技巧

例如: SQL注入攻击 XSS攻击 复制代码 代码如下: 任意执行代码 文件包含以及CSRF. } 关于SQL攻击有很多文章还有各种防注入脚本,但是都不能解决SQL注入的根本问题 见代码: 复制代码 代码如下: <?php mysql_connect("localhost","root","123456")or die("数据库连接失败!"); mysql_select_db("test1"); $u

SQL注入攻击:防御和检查SQL注入的手段

虽然前面有许多文章讨论了SQL注入,但今天所讨论的内容也许可帮助你检查自己的服务器,并采取相应防范措施.知彼知己,方可取胜.首先要清楚SQL注入攻击有哪些种类. 观察近来的一些安全事件及其后果,安全专家们已经得到一个结论,这些威胁主要是通过SQL注入造成的.虽然前面有许多文章讨论了SQL注入,但今天所讨论的内容也许可帮助你检查自己的服务器,并采取相应防范措施. SQL注入攻击的种类 知彼知己,方可取胜.首先要清楚SQL注入攻击有哪些种类. 1.没有正确过滤转义字符 在用户的输入没有为转义字符过滤

PHPcms利用xss执行sql注入

昨天看见phpcms v9.1.15爆的xss和无权限的sql注入,于是就想测试下利用xss执行sql注入,虽然爆的这个phpcms漏洞还有很多其他的用法!但是,这个注入我没有找到phpcms v9.1.15测试,其他版本都没有测试成功! 于是乎我只有假想下一个极端环境: 1.前台有且只有一个xss漏洞(不能获取管理员cookie) 2.后台有且只有一个sql注入漏洞(注入漏洞文件只有管理员可以访问) 3.注入获得管理员密码可解密 4.除以上无其他任何漏洞(包括后台getwebshell) 其实

防御SQL注入攻击时需要注意的一个问题_网络安全

目前很多IIS防火墙其实质就是一个ISAPI Filter,针对SQL注入攻击的防御实质就是关键字过滤,这一点在我以前的随笔中提到的在开发的Web Server Guard中也是这样操作的.但目前大部分的IIS防火墙都存在一个漏洞:如果关键字包含未转义百分比符号 (%) ,那么将会绕过这些IIS防火墙的请求过滤和拦截,包含IIS 7.0的Request Filter. 因为这类防火墙都是查找位于URL/Form/Cookie中的关键字,比如Exec.但是如果你传入E%xec,那么将不会被过滤,这

【Web安全与防御】简析Sql注入与防御措施

引言 最近由于在CSDN上看到许多有关SQL注入问题的文章,以前因为是小白,重在学编程技术上,并没有在程序安全防护上大费周章.但是由于学习的路途越走越远,包括前段时间理工大教务处主页被黑(我同学也在网络工作室负责维护),让我深深的感受到,在Web应用上线之后,除了应付"高并发"之类的效率性问题之外,安全性问题也是非常重要的.俗话说的好,"不防君子防小人",有些了解技术的"小人"们,可能处于娱乐或者是其它目的来hack网站,所以,一般的前台信息过滤

SQL注入攻击-来自微软安全博客的建议

本文翻译自微软博客上刊载的相关文章,英文原文版权归原作者所有,特此声明.原文:http://blogs.technet.com/swi/archive/2008/05/29/sql-injection-attack.aspx近期趋势 从去年下半年开始,很多网站被损害,他们在用于生成动态网页的SQL数据库中存储的文本中被注入了恶意的HTML <script>标签.这样的攻击在2008年第一季度开始加速传播,并且持续影响有漏洞的Web程序.这些Web应用程序有这样一些共同点: 使用经典ASP代码的

让SQL注入攻击危害最小化三大措施

使用用户提供的数据进行数据库查询的任何应用程序是SQL注入攻击的一个潜在目标.数据库管理员可能无法完全阻止针对其数据库服务器的SQL注入式攻击:但是,管理员们和应用程序开发人员可以做一些事情,将这些攻击的影响最小化. 数据库管理员可以做什么? 不要让数据库和Web服务器放在同一台计算机上 使用防火墙或不可路由的IP地址来阻止到数据库的互联网访问.一旦配置完毕,来自数据库服务器的数据包将不能被转发到互联网.在Web服务器上需要添加一条路由,这样才能找到数据库服务器. 配置可信任的IP接入和访问(例

sql注入攻击

SQL攻击(SQL injection,台湾称作SQL资料隐码攻击),简称注入攻击,是发生于应用程序之数据库层的安全漏洞.简而言之,是在输入的字符串之中注入SQL指令,在设计不良的程序当中忽略了检查,那么这些注入进去的指令就会被数据库服务器误认为是正常的SQL指令而运行,因此遭到破坏. 有部份人认为SQL注入攻击是只针对Microsoft SQL Server而来,但只要是支持批处理SQL指令的数据库服务器,都有可能受到此种手法的攻击. 原因 在应用程序中若有下列状况,则可能应用程序正暴露在SQ