Google Chrome 和 Microsoft Edge 網絡瀏覽器中的擴展拼寫檢查功能分別將表單數據(包括個人身份信息 (PII) 和某些情況下的密碼)傳輸給 Google 和 Microsoft。

雖然這可能是這些網絡瀏覽器的已知和預期功能,但它確實引起了人們對傳輸后數據會發生什么以及這種做法可能有多安全的擔憂,特別是在涉及密碼字段時。

Chrome 和 Edge 都啟用了基本的拼寫檢查器。但是,當用戶手動啟用 Chrome 的增強拼寫檢查或 Microsoft 編輯器等功能時,就會出現這種潛在的隱私風險。

拼寫劫持:這是您將 PII 發送給 Big Tech 的拼寫檢查

使用 Chrome 和 Edge 等主要網絡瀏覽器時,如果啟用增強的拼寫檢查功能,您的表單數據將分別傳輸到 Google 和 Microsoft。

根據您訪問的網站,表格數據本身可能包括 PII — 包括但不限于社會安全號碼 (SSN)/社會保險號碼 (SIN)、姓名、地址、電子郵件、出生日期 (DOB)、聯系信息、銀行和支付信息等。

JavaScript 安全公司 otto-js 的聯合創始人兼首席技術官 Josh Summitt 在測試其公司的腳本行為檢測時發現了這個問題。

在啟用 Chrome 增強拼寫檢查或 Edge 的 Microsoft 編輯器(拼寫檢查器)的情況下,在這些瀏覽器的表單字段中輸入的“基本上任何內容”都會傳輸到 Google 和 Microsoft。

“此外,如果你點擊‘顯示密碼’,增強的拼寫檢查甚至會發送你的密碼,本質上是拼寫你的數據,”otto-js 在一篇博文中解釋道。

“當用戶登錄或填寫表格時,世界上一些最大的網站可能會向谷歌和微軟發送敏感的用戶 PII,包括用戶名、電子郵件和密碼。對于公司來說,更重要的問題是這帶來的風險到公司的企業憑證到數據庫和云基礎設施等內部資產。”

阿里巴巴登錄表單字段,啟用“顯示密碼”(otto-js)

Chrome 的增強拼寫檢查器將密碼傳輸給 Google (otto-js)

例如,用戶可能經常在不允許復制粘貼密碼的網站上使用“顯示密碼”選項,或者當他們懷疑自己輸入錯誤時。

為了演示,otto-js 分享了一個用戶在阿里云平臺上用 Chrome 瀏覽器輸入憑證的例子——盡管任何網站都可以用于這個演示。

啟用增強的拼寫檢查,并假設用戶點擊了“顯示密碼”功能,包括用戶名和密碼在內的表單字段將傳輸到 googleapis.com上的 Google 。

該公司還分享了一段視頻演示:

我們還觀察到,在我們使用 Chrome 訪問主要網站的測試中,憑據被傳輸到谷歌:

  • CNN——使用“顯示密碼”時的用戶名和密碼
  • Facebook.com——使用“顯示密碼”時的用戶名和密碼
  • SSA.gov(社會保障登錄)——僅用戶名字段
  • 美國銀行 - 僅限用戶名字段
  • Verizon — 僅限用戶名字段

一個簡單的 HTML 解決方案:'spellcheck=false'

盡管表單字段的傳輸是通過 HTTPS 安全地進行的,但用戶數據一旦到達第三方(在本例中為 Google 的服務器)會發生什么情況可能還不是很清楚。

“增強的拼寫檢查功能需要用戶選擇加入,”谷歌發言人向我們證實。請注意,這與默認情況下在 Chrome 中啟用且不會將數據傳輸到 Google 的基本拼寫檢查器形成對比。

要查看您的 Chrome 瀏覽器中是否啟用了增強拼寫檢查,請將以下鏈接復制粘貼到您的地址欄中。然后,您可以選擇打開或關閉它:

需要選擇加入 Chrome 中的增強拼寫檢查設置

從屏幕截圖中可以明顯看出,該功能的描述明確指出,啟用增強拼寫檢查后,“您在瀏覽器中鍵入的文本將發送給 Google。”

“用戶輸入的文本可能是敏感的個人信息,谷歌不會將其附加到任何用戶身份上,只是在服務器上臨時處理它。為了進一步確保用戶隱私,我們將努力從拼寫檢查中主動排除密碼,”谷歌在與我們分享的聲明中繼續說道。

“我們感謝與安全社區的合作,我們一直在尋找更好地保護用戶隱私和敏感信息的方法。”

至于 Edge,Microsoft Editor Spelling & Grammar Checker 是一個瀏覽器插件,需要顯式安裝才能發生這種行為。

我們在發布之前就提前聯系了微軟。我們被告知此事正在調查中,但我們尚未收到回復。

otto-js 將攻擊向量稱為“Spell-jacking”,并對 Office 365、阿里云、Google Cloud - Secret Manager、Amazon AWS - Secrets Manager 和 LastPass 等云服務的用戶表示擔憂。

針對 otto-js 的報告,AWS 和 LastPass 都緩解了這個問題。在 LastPass 的案例中,補救措施是通過在密碼字段中添加一個簡單的 HTML 屬性spellcheck="false"來實現的:

當從表單文本輸入字段中省略時,'spellcheck' HTML 屬性通常被 Web 瀏覽器默認為 true。'spellcheck' 明確設置為false的輸入字段將不會通過 Web 瀏覽器的拼寫檢查器進行處理。

“公司可以通過在所有輸入字段中添加 'spellcheck=false' 來降低共享客戶 PII 的風險,盡管這可能會給用戶帶來問題,”otto-js 指的是這樣一個事實,用戶現在將不再能夠通過拼寫檢查器運行他們輸入的文本。

“或者,您可以將其添加到包含敏感數據的表單字段中。公司還可以刪除“顯示密碼”的功能。這不會阻止拼寫劫持,但會阻止發送用戶密碼。”

具有諷刺意味的是,我們觀察到 Twitter 的登錄表單帶有“顯示密碼”選項,密碼字段的“拼寫檢查”HTML 屬性顯式設置為 true:

作為一項額外的保障措施,Chrome 和 Edge 用戶可以關閉增強拼寫檢查(按照上述步驟)或從 Edge 中刪除 Microsoft Editor 插件,直到兩家公司都修改了擴展拼寫檢查程序以排除對敏感字段(如密碼)的處理。