前言
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
