基於 HTTP 連接下 token 安全問題？

01-15

最近在研究後台相關的知識，我看了公司的一個用戶管理系統，用戶登錄驗證通過後，服務端會將這個用戶的userId通過加密演算法生成一個字元串token返回給客戶端（pc前端、iosAPP），前端將token保存在cookie裡面， ios則保存在系統鑰匙串裡面，以後的每次請求都在http的header或者body中帶上token，服務端從請求中拿到token解密進行認證，這個token過期時間是一周；
但是問題來了，懂js的都可以在前端cookie中拿到token，進而模擬用戶請求，token形同虛設； ios那邊雖然沒有辦法在本地拿到token，畢竟鑰匙串還是很安全的，但是用wireshark一抓包分析就獲取到了token，然後就可以模擬用戶操作；
我想過將token過期時間設置到60s或者更短，客戶端通過心跳來不斷更新本地(cookie或者鑰匙串)中token，這樣使攻擊者拿到的token是過期的或者製作製作更多的麻煩，但是這樣的話又會額外增加伺服器的壓力而且也不能根本解決問題，想問一下目前線上運營的項目一般是怎麼設計來確保安全的？

一般來說如果客戶端暴露在攻擊之下，任何安全措施都是無效的，因為在攻擊者通曉了雙方通信協議的情況下，伺服器端沒有任何辦法區分一個請求來自於攻擊者還是真實的客戶端。而攻擊者總可以通過反編譯等方式得知客戶端的工作原理。

所以重點在於：

防止客戶端被攻破
客戶端未被攻破的情況下保證安全（如中間人）

第一點主要靠用戶自己，如果手機中了木馬木馬又root了那誰也救不了他。防範XSS當然也是重要的。

第二點，任何你自己想的安全措施都是錯誤的、或者不完備的，要防範中間人攻擊的唯一正確方法就是使用HTTPS。以前也流行過SecretKey Hash簽名等等，新版本的API大部分都已經放棄掉這些方法了，比如說OAuth的新版本就是只支持HTTPS。HTTP上的方法或多或少是有漏洞的，比如說HMAC校驗是不能防範重放攻擊的，也沒有辦法防止中間人從API里竊取敏感信息，更何況如果登錄的時候就被監聽了那不是完蛋了。

舉個簡單的例子，你可以把對方的公網ip地址hash一下寫在token裡面，每次用的時候伺服器檢查一下connection是否匹配，這樣拿到token還能用的難度就會大增，雖然不是不能破解。如果你是長連接，每次斷開就要重新登陸的話，你甚至可以把socket的指針地址hash進token裡面，使用的時候檢查一下（逃

樓主公司用的形式簡單來說就是JWT。對於前端而言，JWT Token 的安全性依賴於跨域和HTTPS，2018年了該升級 HTTPS 了。

以前 Token 直接放入 httpOnly Cookie 的，但是這些年為了更簡單的打通三端以及為了 SPA 的 XSRF 防護，就使用 JWT 了，前端這邊有放到 localstorage 的，有放 cookie 中的但是沒有了 httpOnly 。

一般而言，認證過程直接用 JWT 就可以，但是涉及到核心的一般還要使用雙因素驗證。

謝邀。

他只能拿到自己的，坑也只能坑自己，這有什麼關係呢？後端要做的防禦是即使被繞過前端界面的操作直接發請求，也要保證該做的驗證要做了。比如說這個賬戶是否有許可權做某些事情等。

另外要做的，就是做好 XSS 防禦，不要讓別人在你的網站上有注入腳本的方法，否則其他用戶的 token 被注入腳本的人拿到了，這才是有極大危險的。

還有就是加 https，儘可能提高中間人攻擊的成本。

在被拿到鑰匙的情況下說什麼都是沒用的，所以安全層面只能是防止別人拿到。

基本就是https防止中間人攻擊，請求加時間戳防止重放攻擊。

當然還有一種叫做泄密識別，即利用一定手段匹配用戶環境，如mac地址，IP地址，gps信息，主機名等。一旦這些信息發生變化，就清空token強制重新登錄，甚至要求用戶進行手機驗證，修改密碼等等。不過這只是提高攻擊成本，沒有安全保證。

client side總要儲存一些東西的，所以說「懂js的都可以在前端cookie中拿到token，進而模擬用戶請求，token形同虛設」，這是必然的。。。避免xss之類的攻擊是另一回事對吧。。。

然後你把這個session id明文發送就不對了，這麼重要的東西肯定是通過類似於RSA，或者HASH的方法在client side做簽名才對吧

至少這玩意是要加密的，明文傳輸token和明文傳輸口令有啥本質區別么。

HTTP下談不了安全。HTTP只是傳輸協議。加上SSL才可以。(HTTP + SSL = HTTPS)

用https,確實可以解決傳輸竊取的問題，https的傳輸速度都不及http，在大並發，高流量傳輸的項目我們一般的介面還是選用http。用戶的請求什麼的都可以竊取，這時候加個請求參數的hash驗證就好了，用戶即使竊取了，也改不了參數，在加個失效時間的驗證，介面3s失效。這時候唯一可能被攻破的就是客戶端，獲取到了我們的簽名方式，我們可以把簽名方式打在c開發的靜態庫裡面，這時候破解的難道就是大很多。

cookie可以設置http-only, 這樣通過js就獲取不到了

抓包的問題可以上https

1、沒有絕對的安全。客戶端都被攻破了，什麼方案都白搭。

2、使用https，不多說。

3、後端用戶許可權的校驗，即使攻擊者獲取到了token，能做的操作也只是許可權範圍內的。

4、後端token的失效處理（如果你有保存的話，每次請求都驗證前端token和後端token），用戶退出後，刪除後端token。

5、token失效的問題，不用定時獲取，後端驗證token的時候，做一下檢查，如果5min內即將過期，那麼重新生成token，返回給客戶端。

token有效期不用設置的太短。畢竟在https環境下泄露的可能性已經大大降低了。

先理一下，

懂js的都可以在前端cookie中拿到token，進而模擬用戶請求

攻擊者正常情況無法訪問你用戶的cookie；如果用戶機器被控制了token（這東西其實一般叫credential）保護基本也白做。不過你把js混淆下在藏在圖片裡面加解密你的credential，也可以煩一下人家。

但是用wireshark一抓包分析就獲取到了token

加HTTPS

token過期時間設置到60s

一樣，明文傳的話用戶能更新，攻擊者也可以。

所以缺的是HTTPS。

加上HTTPS，credential還是被偷屬於極端情況。解決辦法一個是定時過期（已經做了，不過60m太快了哈）；還可以讓用戶主動撤銷credential（給他列出已登陸所有登錄的設備，地點，瀏覽器，信息，後面加個按鈕，「不是我的」）。

用戶自己拿到自己的token是沒有問題的，因為這個token就是授權給他訪問自己的數據。這裡的主要問題是如何防止其他人過去這個token。其他人拿到這個token就可以訪問其他人的私有數據了。

其中一個要做的事情是要把http換成https這樣在傳輸管道上就無法截獲token。

還有如下偏門方法

把請求參數排序做md5校驗

但這個偏門方法對安全性幾乎沒有提升，但對客戶端來說實現難度增大了很多。

題主說的方法對也會大幅度增加客戶端編程難度。同時安全性提升也不大。

輪子哥的方法不錯，但一個後果是網路切換的時候ip會變，導致token失效

https，客戶端和伺服器互相校驗證書。