隱式方法在網站上的Access_Token是一個安全隱含？

我有一個服務器，我正在測試connect with Facebook東西使用API v2.2，當用戶點擊該按鈕，並允許我的應用程序，他得到身份驗證，並重定向回到我的網站http://example.com/?#access_token=<REDACTED>好，所以編輯部分是access_token的授權用戶。隱式方法在網站上的Access_Token是一個安全隱含？

現在，我在另一個角度思考，任何攻擊者都可以在他的網站/代表其他用戶處抓取access_token？請注意，我已將我的域名http://example.com列入Facebook開發人員的名單中，因此redirect_uri到另一個網站將無法正常工作，並且我在我的網站上有一個1-2頁，因此顯然沒有網址 - 重定向那裏...因此，發生？

來源

2016-06-21 Gerorge Timber

是的。攻擊者有可能抓取access_token並代表用戶（資源所有者）請求訪問。假設是基本的安全措施在令牌交換髮生之前已經到位。

如：

的通信被加密（HTTPS） - 以避免竊聽
使用其它令牌保護措施，例如狀態參數（和隨機數如果可用）在發送隱式流請求（詳情關於下可選參數狀態參數here） - 主要是爲了防止CSRF和
最明顯的一個 - 不共享在客戶端代碼（客戶端密鑰，即公共客戶端）

來源

2016-06-21 12:21:01 Karthik

我有點1和點3作爲保護，但是當用戶請求access_token時，我沒有包含Anti-CSRF參數'state'，所以在這種情況下攻擊者如何濫用狀態參數？即使我添加額外的'國家'或不，我收到access_token以相同的方式沒有區別@karthik –

讓我們說access_token請求URL是靜態的（與靜態重定向uri和沒有狀態參數）..任何人觀察您的應用程序的重定向uri可以構建這個令牌請求並放置一個CSRF誘餌（如在黑客攻擊中逐步描述的 - http://homakov.blogspot.co.nz/2012/07/saferweb-most-common-oauth2.html）狀態參數會阻止這個可預測的靜態鏈接。所以「狀態」參數應該是隨機的並且很難猜測。它對於每個access_token請求應該是不同的，並且不能被硬編碼。這可以防止您的應用程序外部發出的access_token請求。 SSL可防止令牌泄漏 – Karthik

隱式方法在網站上的Access_Token是一個安全隱含？

回答

相關問題