誰能解釋下Session固定和Session劫持之后攻擊者能做些什么東西？
如果系統中沒有采用session來做權限校驗，劫持了session是不是也沒什么作用？
還是說通過session劫持可以冒名訪問不能訪問的網站？
順便能說下session固定攻擊的防御方案嗎？ 如果我針對每次請求都做session重建這樣豈不是影響了在這之前的鏈接？
uj5u.com熱心網友回復：
系統接入了單點，如果變更sessionid會導致請求被重定向到登陸，此時請求又會被瀏覽器的同源策略禁止， 而且這樣每次都走單點對單點服務的壓力也很大，有沒有人有好的解決辦法。uj5u.com熱心網友回復：
session是檢驗手段之一，如果你系統沒有用session檢驗，那前端也不會發session到服務器，那也談不上劫持了。劫持session成功了我的理解就是可以冒充某個user訪問，防御的話一般https的傳輸內容本身就是加密的，有防御作用，其他方法的話，我知道的有非對稱加密比如的JWT的方法，不過這需要在客戶端先配置一個私鑰，這種一般運用于企業級應用里的，一般沒法用在個人用戶上。
uj5u.com熱心網友回復：
同源策略是針對js的吧，如果只是在瀏覽器地址欄里跳轉的話，跟同源策略沒關系的。我公司用的單點登錄是基于SAML的。
uj5u.com熱心網友回復：
1、session固定是攻擊者提前給你創建好了一個sessionid，然后引導你去登錄，應對這種攻擊的辦法是登錄成功的時候，重置sessionid即可。這樣在用戶登錄成功之后，攻擊者設定的sessionid就沒有意義了。2、session劫持，其實這個你需要解決的應該是xss，設定Cookie的HttpOnly為true，在后端做同源檢測等。如果攻擊者能夠獲取到你的sessionid，那不管你sessionid怎么變，即使你每次變換也沒用。所以你要做的是如何讓攻擊者獲取不到sessionid，而不是每次都改變它。為了防止通過網路攔截獲取，你也可以使用https證書加密。
每次請求都做session重建，我就呵呵了，那這還要session干什么？
沒用session檢測，當然所有基于session的攻擊沒有意義。但是不用session的話，又有什么辦法呢？無非幾種，url帶引數、隱藏域或者js中保存token、請求頭回傳token等手段，其實最終的實作原理都一樣，換湯不換藥而已。至少在這幾種實作方式中，通過cookie保存sessionid，服務器端實作session的方式還是相對更安全的。至少cookie本身給了我們一些安全性的設定，例如httponly，同源策略等。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/11265.html
標籤：Java EE
下一篇：java，不顯示視窗，鍵盤監聽