前言
xss攻击(跨站脚本攻击)：攻击者在页面里插入恶意脚本代码，用户浏览该页面时，脚本代码就会执行，达到攻击者的目的。原理就是：攻击者对含有漏洞的服务器注入恶意代码，引诱用户浏览受到攻击的服务器，并打开相关页面，执行恶意代码。
xss攻击方式：一、反射性攻击，脚本代码作为url参数提交给服务器，服务器解析执行后，将脚本代码返回给浏览器，最后浏览器解析执行攻击代码；二、存储性攻击，和发射性攻击的区别是，脚本代码存储在服务器，下次在请求时，不用再提交脚本代码。其中一个示例图如下所示：
csrf攻击：跨站请求伪造攻击，csrf是一种欺骗受害者提交恶意请求的攻击，并劫持受害者的身份和特权，并以受害者的身份访问未授权的信息和功能。序列图如下所示：
同步器token
解决xss攻击和csrf攻击的一个推荐方法就是同步器token，就是在post的请求中，增加一个token，每次请求到来，服务器都会验证请求中的token和服务器期望的值是否一致，如果不一致，服务器将请求视为非法的，整个过程的示例图如下所示：
在spring security中如果使用的是 @enablewebmvcsecurity而不是@enablewebsecurity，同步器token是默认打开的，通过http().csrf().disable()可以关闭同步器token功能。spring security发现token无效后，会返回一个403的访问拒绝，不过可以通过配置accessdeniedhandler类处理invalidcsrftokenexception异常来定制行为。
spring security虽然默认是打开同步器token保护的，但是也提供了一个显示打开的行为即http().csrf(),同时需要在html的form表单中添加以“<input type="hidden"name="${_csrf.parametername}" value="${_csrf.token}"/>”
如果请求的是json或ajax请求，如何使用同步器token防护那？
json请求的话，我们可以在header的元数据中添加token防护，代码如下所示：
|
1
2
3
4
5
6
|
<head><meta name="_csrf" content="${_csrf.token}"/><!-- default header name is x-csrf-token --><meta name="_csrf_header" content="${_csrf.headername}"/>...</head> |
ajax请求的话，可是使用如下代码：
|
1
2
3
4
5
6
7
|
$(function () {var token = $("meta[name='_csrf']").attr("content");var header = $("meta[name='_csrf_header']").attr("content");$(document).ajaxsend(function(e, xhr, options) {xhr.setrequestheader(header, token);});}); |
synchronizer token的常见问题
1.超时
因为token是存储在httpsession中的，所以token存在超时的问题，一旦超时，则配置的accessdeniedhandler将接受一个异常，或者spring security直接拒绝访问；
2.登录
为了防止伪造的登录请求，在登录的form中也需要添加token，而token又是存储在httpsession中，也就是说一旦发现token属性，就会创建一个httpsession，这和无状态架构模式可能会产生一些冲突；
3.注销
添加csrf将更新logoutfilter过滤器，使其只使用http post。这确保了注销需要一个csrf令牌，并且恶意用户不能强制注销您的用户。也就是说，注销不再是一个get请求，而是一个post请求；
spring security支持的安全response header
spring security 支持的response header 包括：cache-control,content-type options,http strict transport security,x-frame-options,x-xss-protection 如果你使用的是websecurityconfigureradapter 配置方式，则这些头都是默认支持的，你可以通过调用 http.header().disable()关闭这些缺省的头。当然你也可以单独配置，但是如果你单独配置的话，只有你配置的头会起作用，其他的头都不再默认支持了。下面分别来讨论一下这些响应header的含义；
cache-control
如果不加任何控制，浏览器通常会缓存你的认证相关信息，这在一定程度上会造成你的信息泄露，因此在默认情况下，spring security会在响应头里加入缓存控制如下所示：
|
1
2
3
|
cache-control: no-cache, no-store, max-age=0, must-revalidatepragma: no-cacheexpires: 0 |
当然你也可以通过 http.header().cachecontrol()方法单独打开缓存控制，你也可以通过httpservletresponse.setheader(string,string)方法对特殊的响应做处理，从而确保css js 图片能够合适地被缓存，在spring mvc中，可以通过配置进行设置，下面的代码对所有的资源都增加了缓存：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
@enablewebmvcpublic class webmvcconfiguration extends webmvcconfigureradapter { @override public void addresourcehandlers( resourcehandlerregistry registry) { registry .addresourcehandler("/resources/**") .addresourcelocations("/resources/") .setcacheperiod(3_155_6926); }// ...} |
content-type options
历史上很多很多浏览器都能可以通过对请求类型的content进行嗅探，猜测请求类型，从而提高用户体验，但是这会带来xss攻击。例如有些站点允许用户向其提交有效的postscript脚本，并查看他。恶意用户可能提交一个有效的js文件，并使用它执行xss攻击。spring security默认是禁止进行嗅探的。
http strict transport security
当你访问一个站点是，例如www.baidu.com，省略了https协议，潜在的你会受到中间人攻击，为了减少这种情况，就是告知浏览器，当你输入某个地址时，应该使用https协议。如何让浏览器该host是一个hsts站点那？其中一种方法就是，增加strict-transport-security 到响应头中，如下例所示：
|
1
|
strict-transport-security: max-age=31536000 ; includesubdomains |
上述例子告知浏览器，该站点在一年内访问都使用https协议，includesubdomains说明该站点的子域名也使用https协议访问。
x-frame-optiont
x-frame-options http 响应头是用来给浏览器指示允许一个页面可否在 <frame>, <iframe> 或者 <object> 中展现的标记。网站可以使用此功能，来确保自己网站的内容没有被嵌到别人的网站中去，也从而避免了点击劫持 (clickjacking) 的攻击。
x-frame-options 有三个值: deny 表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。
sameorigin 表示该页面可以在相同域名页面的 frame 中展示。allow-from uri表示该页面可以在指定来源的 frame 中展示。
spring security默认是使用deny，即拒绝在frame中展示，从而避免点击劫持的攻击，当然你也可以进行单独设置或对x-frame-option设置特殊的值。
customer header
spring security有一些机制，可以方便地向应用程序添加更常见的安全头。但是，它还提供了允许添加自定义头的钩子。有时，您希望将自定义安全头插入到您的应用程序中，而该特性并没有被支持。例如，您可能希望尽早支持内容安全策略，以确保资源只能从相同的源加载。由于对内容安全策略的支持还没有最终确定，浏览器使用两个常见的扩展头之一来实现这个特性。这意味着我们将需要注入两次策略。下面的代码片段中可以看到一个头的示例：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
x-content-security-policy: default-src 'self'x-webkit-csp: default-src 'self'@overrideprotected void configure(httpsecurity http) throws exception { http.headers() .addheaderwriter( new staticheaderswriter( "x-content-security-policy", "default-src 'self'")) .addheaderwriter( new staticheaderswriter( "x-webkit-csp", "default-src 'self'"));} |
当名称空间或java配置不支持您想要的头部时，您可以创建一个自定义的headerswriter实例，甚至可以提供headerswriter的自定义实现。让我们看一个使用xframeoptionsheaderwriter的自定义实例的示例。也许您希望允许为相同的起源构建内容框架。将策略属性设置为sameorigin很容易支持这一点：
|
1
2
3
4
5
6
7
|
@overrideprotected void configure(httpsecurity http) throws exception { http.headers() .addheaderwriter( new xframeoptionsheaderwriter( xframeoptionsmode.sameorigin));} |
有时，您可能只想为某些请求编写一个header。例如，您可能只想保护您的登录页面。您可以使用delegatingrequestmatcherheaderwriter类来这样做。
|
1
2
3
4
5
6
7
8
9
|
@overrideprotected void configure(httpsecurity http) throws exception { delegatingrequestmatcherheaderwriter headerwriter = new delegatingrequestmatcherheaderwriter( new antpathrequestmatcher("/login"), new xframeoptionsheaderwriter()); http.headers() .addheaderwriter(headerwriter);} |
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持服务器之家。
原文链接：https://segmentfault.com/a/1190000015767740
