-1

大多數密碼管理員都有一個網絡擴展。該擴展從桌面應用程序(如Dashlane中)或瀏覽器中關聯的保險庫(例如LastPass中)獲取登錄詳細信息。這些擴展然後填寫登錄表單和相應的詳細信息。但是,通過其他方式總是有可能通過登錄表單破解憑據。通過擴展登錄操作

因此,我想知道擴展程序執行直接登錄到應用程序而不填寫表單的可能性。也就是說,我建立了一個擴展和一個密碼管理器。我的擴展應該從密碼管理器獲取登錄信息,並自行執行登錄操作,而無需填寫網頁的登錄表單。在這種情況下,憑證被盜的可能性並沒有完全消除,但是減少了。

如果我能對此有所瞭解,這將非常有幫助。

+0

你實質上是在尋找一個直接的POST請求。但是,在需要驗證碼的情況下,這可能不起作用。 –

+0

@Manos Forsaken感謝您的評論。但不是大多數網站採用驗證碼。有沒有其他方式可以實現。 – mbvee

+1

您可能希望檢查相關的[SO帖子](http://stackoverflow.com/questions/7217137/chrome-extension-login-best-practices),其中建議您應始終使用[OAuth 2.0](https ://en.wikipedia.org/wiki/OAuth#OAuth_2.0)進行身份驗證,並且永遠不會傳遞用戶名/密碼,因爲攻擊者可以簡單地竊取這些信息。有關更多信息,請參閱[教程:OAuth](https://developer.chrome.com/extensions/tut_oauth)。 – Teyam

回答

0

我認爲你的問題有一些缺陷。想想以下幾點。

表單自動填充很容易通過擴展來處理,因爲您只需檢測與您跟蹤的特定於域的頁面關聯的表單元素。如果表格不在等式中,那麼擴展而不是自動填充表單應自動將數據發佈到服務登錄表單的服務控制器。爲此,您需要跟蹤與您管理的登錄表單關聯的所有POST URL(當然在檢測到它們之後)。

我們假設你以某種方式跟蹤表單POST端點。然後,您需要實際將數據發佈到服務以驗證用戶身份。由於擴展(與登錄表單相反)不符合相同的源策略,因此您需要添加一些CORS才能執行請求。但是這在擴展中當然很容易。

這給我們帶來了下一個問題。登錄表單請求是有狀態的,因此成功的登錄響應會在用於會話管理的客戶機上設置一個cookie。由於擴展程序在沙盒環境中運行,因此無法修改來自第三方域的Cookie。

長話短說。你的想法聽起來很酷,因爲它消除了這一過程中的一步,但我的經驗法則是,如果某種範式已經存在了太久,那麼背後肯定有不止一個好理由。