CSRF（Cross-site request forgery）跨站申请伪造，也被称为”One Click Attack”（一键攻打）或者”Session Riding”（会话管制），是一种对网站的歹意利用。与传统的XSS攻打（跨站脚本攻打）相比，CSRF攻打更加难以防备，被认为更具危险性。CSRF攻打能够在用户不知情的状况下，以用户的名义伪造申请发送给攻打页面，从而在用户未受权的状况下执行受到权限爱护的操作。
场景解说
例如，一个用户Andy登录银行站点服务器筹备进行转账操作。在Andy的用户信息有效期内，Andy被诱导查看了一个黑客歹意网站。该网站获取了Andy登录后的浏览器与银行网站之间尚未过期的Session信息。因为Andy浏览器的cookie中含有Andy银行账户的认证信息，黑客能够以Andy的非法身份假装拜访Andy的银行账户，并进行非法操作。
CSRF攻打的进攻策略
- 验证HTTP Referer字段：验证申请起源页面的Referer字段，确保申请来自同一站点，但该办法并不牢靠，因为Referer字段可能被伪造或者被浏览器禁用。
- 在申请地址中增加Token并验证：在每个页面中嵌入一个随机生成的Token，并将其增加到申请地址的参数中，后端服务器在接管到申请时验证Token的有效性。
- 在HTTP头中自定义属性并验证：在每个申请中增加自定义的HTTP头属性，例如”X-Requested-With”或”X-CSRF-Token”，后端服务器在接管到申请时验证该属性的值。
以Spring Security平安框架中的CSRF进攻性能来解说：
disable(): 敞开Spring Security默认开启的CSRF进攻性能。csrfTokenRepository(CsrfTokenRepository csrfTokenRepository): 指定要应用的CsrfTokenRepository（Token令牌长久化仓库）。默认是由LazyCsrfTokenRepository包装的HttpSessionCsrfTokenRepository。requireCsrfProtectionMatcher(RequestMatcher requireCsrfProtectionMatcher): 指定针对什么类型的申请利用CSRF防护性能。默认设置是疏忽GET、HEAD、TRACE和OPTIONS申请，而解决并进攻其余所有申请。
- CSRF防护性能敞开的配置，但间接敞开CSRF进攻的形式简略粗犷，不太举荐应用，如果强行敞开后网站可能会面临CSRF攻打的危险，适宜在开发过程中测试应用。
@Override
protected void configure(HttpSecurity http
) throws Exception {
http
.csrf()
.disable()
// ...其余配置
}Spring Boot整合Spring Security进行CSRF进攻的示例
-
针对Form表单数据批改申请的CSRF Token配置：
在表单中增加携带CSRF Token信息的暗藏域：<form method="post"> <input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}" /> <!-- 其余表单字段 --> <input type="submit" value="Submit" /> </form> - 针对Ajax数据批改申请的CSRF Token配置：
在页面的<head>标签中增加<meta>标签设置CSRF Token信息，并在具体的Ajax申请中获取相应的Token值，并将其增加到申请的HTTP header中进行验证。
<head>
<meta name="_csrf" th:content="${_csrf.token}"/>
<meta name="_csrf_header" th:content="${_csrf.headerName}"/>
<!-- 其余头信息 -->
</head>
<body>
<!-- 具体页面内容 -->
<script type="text/javascript">
$(document).ajaxSend(function(e, xhr, options) {
xhr.setRequestHeader($("meta[name='_csrf_header']").attr("content"), $("meta[name='_csrf']").attr("content"));
});
// 其余Ajax申请
</script>
</body>心愿通过以上的解说，能让大家更深刻的理解CSRF（跨站申请伪造）攻打及进攻策略。
本文由mdnice多平台公布
