SpringBoot 如何防御 CSRF 攻击?

[[403473]]

CSRF 就是跨域请求伪造,英文全称是 Cross Site Request Forgery。

这是一种非常常见的 Web 攻击方式,其实是很好防御的,但是由于经常被很多开发者忽略,进而导致很多网站实际上都存在 CSRF 攻击的安全隐患。

今天松哥就来和大家聊一聊什么是 CSRF 攻击以及 CSRF 攻击该如何防御。

1.CSRF原理

想要防御 CSRF 攻击,那我们得先搞清楚什么是 CSRF 攻击,松哥通过下面一张图,来和大家梳理 CSRF 攻击流程:

其实这个流程很简单:

  • 假设用户打开了招商银行网上银行网站,并且登录。
  • 登录成功后,网上银行会返回 Cookie 给前端,浏览器将 Cookie 保存下来。
  • 用户在没有登出网上银行的情况下,在浏览器里边打开了一个新的选项卡,然后又去访问了一个危险网站。
  • 这个危险网站上有一个超链接,超链接的地址指向了招商银行网上银行。
  • 用户点击了这个超链接,由于这个超链接会自动携带上浏览器中保存的 Cookie,所以用户不知不觉中就访问了网上银行,进而可能给自己造成了损失。

CSRF 的流程大致就是这样,接下来松哥用一个简单的例子和小伙伴们展示一下 CSRF 到底是怎么回事。

2.CSRF实践

接下来,我创建一个名为 csrf-1 的 Spring Boot 项目,这个项目相当于我们上面所说的网上银行网站,创建项目时引入 Web 和 Spring Security 依赖,如下:

创建成功后,方便起见,我们直接将 Spring Security 用户名/密码 配置在 application.properties 文件中:

  1. spring.security.user.name=javaboy 
  2. spring.security.user.password=123 

然后我们提供两个测试接口:

  1. @RestController 
  2. public class HelloController { 
  3.     @PostMapping("/transfer"
  4.     public void transferMoney(String nameInteger money) { 
  5.         System.out.println("name = " + name); 
  6.         System.out.println("money = " + money); 
  7.     } 
  8.     @GetMapping("/hello"
  9.     public String hello() { 
  10.         return "hello"
  11.     } 

假设 /transfer 是一个转账接口(这里是假设,主要是给大家演示 CSRF 攻击,真实的转账接口比这复杂)。

最后我们还需要配置一下 Spring Security,因为 Spring Security 中默认是可以自动防御 CSRF 攻击的,所以我们要把这个关闭掉:

  1. @Configuration 
  2. public class SecurityConfig extends WebSecurityConfigurerAdapter { 
  3.     @Override 
  4.     protected void configure(HttpSecurity http) throws Exception { 
  5.         http.authorizeRequests().anyRequest().authenticated() 
  6.                 .and() 
  7.                 .formLogin() 
  8.                 .and() 
  9.                 .csrf() 
  10.                 .disable(); 
  11.     } 

配置完成后,我们启动 csrf-1 项目。

接下来,我们再创建一个 csrf-2 项目,这个项目相当于是一个危险网站,为了方便,这里创建时我们只需要引入 web 依赖即可。

项目创建成功后,首先修改项目端口:

  1. server.port=8081 

然后我们在 resources/static 目录下创建一个 hello.html ,内容如下:

  1. <body> 
  2. <form action="http://localhost:8080/transfer" method="post"
  3.     <input type="hidden" value="javaboy" name="name"
  4.     <input type="hidden" value="10000" name="money"
  5.     <input type="submit" value="点击查看美女图片"
  6. </form> 
  7. </body> 

 

 

 

这里有一个超链接,超链接的文本是点击查看美女图片,当你点击了超链接之后,会自动请求 http://localhost:8080/transfer 接口,同时隐藏域还携带了两个参数。

配置完成后,就可以启动 csrf-2 项目了。

接下来,用户首先访问 csrf-1 项目中的接口,在访问的时候需要登录,用户就执行了登录操作,访问完整后,用户并没有执行登出操作,然后用户访问 csrf-2 中的页面,看到了超链接,好奇这美女到底长啥样,一点击,结果钱就被人转走了。

3.CSRF防御

先来说说防御思路。

CSRF 防御,一个核心思路就是在前端请求中,添加一个随机数。

因为在 CSRF 攻击中,黑客网站其实是不知道用户的 Cookie 具体是什么的,他是让用户自己发送请求到网上银行这个网站的,因为这个过程会自动携带上 Cookie 中的信息。

所以我们的防御思路是这样:用户在访问网上银行时,除了携带 Cookie 中的信息之外,还需要携带一个随机数,如果用户没有携带这个随机数,则网上银行网站会拒绝该请求。黑客网站诱导用户点击超链接时,会自动携带上 Cookie 中的信息,但是却不会自动携带随机数,这样就成功的避免掉 CSRF 攻击了。

Spring Security 中对此提供了很好的支持,我们一起来看下。

3.1 默认方案

Spring Security 中默认实际上就提供了 csrf 防御,但是需要开发者做的事情比较多。

首先我们来创建一个新的 Spring Boot 工程,创建时引入 Spring Security、Thymeleaf 和 web 依赖。

项目创建成功后,我们还是在 application.properties 中配置用户名/密码:

  1. spring.security.user.name=javaboy 
  2. spring.security.user.password=123 

接下来,我们提供一个测试接口:

  1. @Controller 
  2. public class HelloController { 
  3.     @PostMapping("/hello"
  4.     @ResponseBody 
  5.     public String hello() { 
  6.         return "hello"
  7.     } 

注意,这个测试接口是一个 POST 请求,因为默认情况下,GET、HEAD、TRACE 以及 OPTIONS 是不需要验证 CSRF 攻击的。

然后,我们在 resources/templates 目录下,新建一个 thymeleaf 模版,如下:

  1. <body> 
  2. <form action="/hello" method="post"
  3.     <input type="hidden" th:value="${_csrf.token}" th:name="${_csrf.parameterName}"
  4.     <input type="submit" value="hello"
  5. </form> 
  6. </body> 

 

 

 

注意,在发送 POST 请求的时候,还额外携带了一个隐藏域,隐藏域的 key 是 ${_csrf.parameterName},value 则是 ${_csrf.token}。

这两个值服务端会自动带过来,我们只需要在前端渲染出来即可。

接下来给前端 hello.html 页面添加一个控制器,如下:

  1. @GetMapping("/hello"
  2. public String hello2() { 
  3.     return "hello"

添加完成后,启动项目,我们访问 hello 页面,在访问时候,需要先登录,登录成功之后,我们可以看到登录请求中也多了一个参数,如下:

可以看到,这里也多了 _csrf 参数。

这里我们用了 Spring Security 的默认登录页面,如果大家使用自定义登录页面,可以参考上面 hello.html 的写法,通过一个隐藏域传递 _csrf 参数。

访问到 hello 页面之后,再去点击按钮,就可以访问到 hello 接口了。

小伙伴们可以自行尝试在 hello.html 页面中,去掉 _csrf 参数,看看访问 hello 接口的效果。

这是 Spring Security 中默认的方案,通过 Model 将相关的数据带到前端来。

如果你的项目是前后端不分项目,这种方案就可以了,如果你的项目是前后端分离项目,这种方案很明显不够用。

3.2 前后端分离方案

如果是前后端分离项目,Spring Security 也提供了解决方案。

这次不是将 _csrf 放在 Model 中返回前端了,而是放在 Cookie 中返回前端,配置方式如下:

  1. @Configuration 
  2. public class SecurityConfig extends WebSecurityConfigurerAdapter { 
  3.     @Override 
  4.     protected void configure(HttpSecurity http) throws Exception { 
  5.         http.authorizeRequests().anyRequest().authenticated() 
  6.                 .and() 
  7.                 .formLogin() 
  8.                 .and() 
  9.                 .csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()); 
  10.     } 

有小伙伴可能会说放在 Cookie 中不是又被黑客网站盗用了吗?其实不会的,大家注意如下两个问题:

  1. 黑客网站根本不知道你的 Cookie 里边存的啥,他也不需要知道,因为 CSRF 攻击是浏览器自动携带上 Cookie 中的数据的。
  2. 我们将服务端生成的随机数放在 Cookie 中,前端需要从 Cookie 中自己提取出来 _csrf 参数,然后拼接成参数传递给后端,单纯的将 Cookie 中的数据传到服务端是没用的。

理解透了上面两点,你就会发现 _csrf 放在 Cookie 中是没有问题的,但是大家注意,配置的时候我们通过 withHttpOnlyFalse 方法获取了 CookieCsrfTokenRepository 的实例,该方法会设置 Cookie 中的 HttpOnly 属性为 false,也就是允许前端通过 js 操作 Cookie(否则你就没有办法获取到 _csrf)。

配置完成后,重启项目,此时我们就发现返回的 Cookie 中多了一项:

接下来,我们通过自定义登录页面,来看看前端要如何操作。

首先我们在 resources/static 目录下新建一个 html 页面叫做 login.html:

  1. <!DOCTYPE html> 
  2. <html lang="en"
  3. <head> 
  4.     <meta charset="UTF-8"
  5.     <title>Title</title> 
  6.     <script src="js/jquery.min.js"></script> 
  7.     <script src="js/jquery.cookie.js"></script> 
  8. </head> 
  9. <body> 
  10. <div> 
  11.     <input type="text" id="username"
  12.     <input type="password" id="password"
  13.     <input type="button" value="登录" id="loginBtn"
  14. </div> 
  15. <script> 
  16.     $("#loginBtn").click(function () { 
  17.         let _csrf = $.cookie('XSRF-TOKEN'); 
  18.         $.post('/login.html',{username:$("#username").val(),password:$("#password").val(),_csrf:_csrf},function (data) { 
  19.             alert(data); 
  20.         }) 
  21.     }) 
  22. </script> 
  23. </body> 
  24. </html> 

 

 

 

 

 

这段 html 我给大家解释下:

  1. 首先引入 jquery 和 jquery.cookie ,方便我们一会操作 Cookie。
  2. 定义三个 input,前两个是用户名和密码,第三个是登录按钮。
  3. 点击登录按钮之后,我们先从 Cookie 中提取出 XSRF-TOKEN,这也就是我们要上传的 csrf 参数。
  4. 通过一个 POST 请求执行登录操作,注意携带上 _csrf 参数。

服务端我们也稍作修改,如下:

  1. @Configuration 
  2. public class SecurityConfig extends WebSecurityConfigurerAdapter { 
  3.     @Override 
  4.     public void configure(WebSecurity web) throws Exception { 
  5.         web.ignoring().antMatchers("/js/**"); 
  6.     } 
  7.  
  8.     @Override 
  9.     protected void configure(HttpSecurity http) throws Exception { 
  10.         http.authorizeRequests().anyRequest().authenticated() 
  11.                 .and() 
  12.                 .formLogin() 
  13.                 .loginPage("/login.html"
  14.                 .successHandler((req,resp,authentication)->{ 
  15.                     resp.getWriter().write("success"); 
  16.                 }) 
  17.                 .permitAll() 
  18.                 .and() 
  19.                 .csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()); 
  20.     } 

一方面这里给 js 文件放行。

另一方面配置一下登录页面,以及登录成功的回调,这里简单期间,登录成功的回调我就给一个字符串就可以了。大家感兴趣的话,可以查看本系列前面文章,有登录成功后回调的详细解释。

OK,所有事情做完之后,我们访问 login.html 页面,输入用户名密码进行登录,结果如下:

可以看到,我们的 _csrf 配置已经生效了。

小伙伴们可以自行尝试从登录参数中去掉 _csrf,然后再看看效果。

4.小结

好了,今天主要和小伙伴们介绍了 csrf 攻击以及如何防御的问题。大家看到,csrf 攻击主要是借助了浏览器默认发送 Cookie 的这一机制,所以如果你的前端是 App、小程序之类的应用,不涉及浏览器应用的话,其实可以忽略这个问题,如果你的前端包含浏览器应用的话,这个问题就要认真考虑了。

好了 ,本文就说到这里,本文相关案例我已经上传到 GitHub ,大家可以自行下载:https://github.com/lenve/spring-security-samples

本文转载自微信公众号「江南一点雨」,可以通过以下二维码关注。转载本文请联系江南一点雨公众号。

 

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/146726.html<

(0)
管理的头像管理
上一篇2025-03-11 05:37
下一篇 2025-03-11 05:39

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注