iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 24
2
Security

資安補漏洞,越補越大洞系列 第 24

[Day 24] 來玩WebGoat!之12:Authentication Flaws - JWT tokens 2

接續昨天還沒完成的JWT練習,今天來看看第5步的挑戰,其實這一題跟昨天的練習蠻類似的,他只是要我們把JWT解碼後,再把USERID改為WebGoat,並找出密鑰是什麼,再把最後結果的JWT貼回來就好。

https://ithelp.ithome.com.tw/upload/images/20181108/20107304PPBmYdDJUH.png

我們利用昨天的線上工具(網址:https://jwt.io/ )來進行編輯,首先把原始JWT貼過去,並得到解析出的內容。

https://ithelp.ithome.com.tw/upload/images/20181108/20107304BsjvgCu7wD.png

接著把username參數的值由Tom改為WebGoat,再把我們昨天已經知道WebGoat存於伺服器的密鑰victory填上去,就會產生內容被修改過的JWT。

https://ithelp.ithome.com.tw/upload/images/20181108/20107304s26Ubp6GWk.png

最後把這串JWT貼回題目的解題欄位就完成啦!

https://ithelp.ithome.com.tw/upload/images/20181108/20107304p5RFUO96AY.png

接著要介紹存取token (acces token)跟重整token(refresh token)兩種token,以及兩者的特性。access token不會存在伺服器端,其用法如同昨天介紹,可以在與伺服器間進行溝通時用來驗證連線是合法的,但如果access token一直都是一樣的話,要是被竊取用來偽造身分就不妙了,因此access token會在一段時間後失效,那失效後沒有access token怎麼辦呢?另一個refresh token的設計就是用來解決這個問題。

refresh token會存在伺服器端,功能是要用來驗證這個使用者是真正的合法使用者,並在access token到期後,由伺服器端確認refresh token是合法之後,並再次產生一組新的access token提供給使用者使用。refresh token並不是永遠都不用更新,但是可以比access token更新的頻率低許多,而伺服器端驗證refresh token是不是合法的方法不僅只是看字串是不是一樣,也可以透過觀察使用者每次發送請求的IP、地理位置等是不是有太大差異、送出取得新access token請求的頻率等,來判斷送出請求的是否為正常使用者。

以下為access token及refresh token的範例,access token的格式就是JWT,而refresh token的格式則是一串亂碼。

{
    "token_type":"bearer",
    "access_token":"XXXX.YYYY.ZZZZ",
    "expires_in":10,
    "refresh_token":"4a9a0b1eac1a34201b3c5659944e8b7"
}

但就算有這兩種token想輔相成,JWT還是有被偽造或竊取的疑慮、字串比起傳統cookie大很多、容易造成伺服器的session管理混亂等問題,所以WebGoat中是建議最好不要用在人類與伺服器間的溝通,而是用在伺服器與伺服器間的溝通。

參考連結:
[1] http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
[2] http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/


上一篇
[Day 23] 來玩WebGoat!之11:Authentication Flaws - JWT tokens 1
下一篇
[Day 25] 來玩WebGoat!之13:Authentication Flaws - JWT tokens 3
系列文
資安補漏洞,越補越大洞30

尚未有邦友留言

立即登入留言