跨站點請求偽造解決方案

跨站點請求偽造

token

前一篇部落格介紹了啟用了不安全的http方法的解決方案，有興趣請移步

首先，什麼是跨站點請求偽造？

跨站點請求偽造-csrf（cross site request forgery）：是一種網路攻擊方式。

說的白話一點就是，別的站點偽造你的請求，最可怕的是你還沒有察覺並且接收了。聽起來確實比較危險，下面有個經典的例項，了解一下跨站點請求偽造到底是怎麼是實現的，知己知彼。

受害者：bob

黑客：mal

銀行：bank

bob在銀行有一筆存款，可以通過請求把錢轉到bob2下。通常情況下，該請求到達**後，伺服器會驗證請求是否來自乙個合法的session，並且該session的使用者bob已登入。mal在該銀行也有賬戶，於是他偽造了乙個位址，但是如果直接訪問，伺服器肯定會識別出當前登入使用者是mal而不是bob，不能接受請求。於是通過csrf攻擊方式，將此鏈結偽造在廣告下，誘使bob自己點這個鏈結，那麼請求就會攜帶bob瀏覽起的cookie一起傳送到銀行，而bob同時又登入了銀行或者剛剛登入不久session還沒有過期，那伺服器發現cookie中有bob的登入資訊，就接收了響應，攻擊就成功了

1. 驗證referer：

referer攜帶請求**，從示例可以看出，受害者傳送非法請求肯定不是在銀行的介面，所以在伺服器通過驗證referer是不是bank.example開始就可以了，這個方法簡單粗暴。

最簡單的實現就是加個filter：

public

void

dofilter

(servletrequest request, servletresponse response, filterchain chain)

throws ioexception, servletexception

else

}

2. 在請求引數中新增token驗證：

要抵禦跨站點請求偽造就要設定乙個黑客偽造不了的東西。我們可以在請求引數中加乙個隨機token，在伺服器驗證這個token，通過即銷毀重設。下面說一下我的實現：

首先定義token為key-value結構，因為很多情況會從不同的地方訪問同乙個請求，如果是單一的資料結構，第乙個請求生成token後還沒來得及傳送請求，第二個又請求生成token就會把第乙個沖掉，從而導致連續的驗證失敗。所以，我們要通過請求源將token隔離起來。這裡我將請求位址摘要後作為token的key,用guid作為token的value，**如下：

/*** 根據請求位址獲取token-key

/*** 獲取token-value並儲存在session中

/*** 驗證token

完成上邊的工具方法後，需要在form中新增token，如下：

name="frm"

action="/test/tokentest.htm"

method="post">

type="hidden"

name="token_key"

value="<%=token.gettokenkey(request) %>"/>

type="hidden"

name="token_value"

value="<%=token.gettokenvalue(request) %>"/>

...

form>

驗證可以放在filter裡也可以放在service裡，只要保證請求/test/tokentest.htm會先驗證就行了。直接呼叫工具方法token.verify()以下就不贅述了。

3. 在http頭中自定義屬性並驗證：

這個方法和上面那個類似，也是設定token，只是把token設定為http頭中的自定義屬性。

通過xmlhttprequest可以一次性給所有該類請求的http頭加上token 屬性，但是xmlhttprequest請求通常用於ajax方法對區域性頁面的非同步重新整理，比較有侷限性；而且通過xmlhttprequest請求的位址不會被記錄到瀏覽器的位址列，一方面不會通過referer洩露token，另一方面會導致前進，後退，重新整理，收藏等操作失效，所以還是慎用。

雖然上面介紹了幾種方法，但現在還沒有一種完美的解決方案，但是通過referer和token方案結合起來使用，也能很得有效csrf攻擊。

跨站點請求偽造解決方案

跨站點請求偽造解決方案

AppScan 測出跨站點請求偽造漏洞

跨域請求解決方案

跨站點請求偽造解決方案

跨站點請求偽造解決方案

AppScan 測出 跨站點請求偽造 漏洞

跨域請求解決方案

相關推薦

AppScan 測出跨站點請求偽造漏洞