通過https安全將javascript密碼從服務器傳遞到瀏覽器？

Question

以下是我們的網頁流量，

1. 用戶是通過HTTPS登錄頁面訪問。
2. 用戶輸入密碼並提交頁面（POST方法）。
3. 用戶憑證現在不通過身份驗證，而是通過一些輪詢頁面（https）進行服務器響應。
4. 爲了保留輪詢頁面上的密碼，密碼通過JavaScript變量和輪詢頁面的onsubmit從服務器傳遞到瀏覽器，密碼通過POST方法傳遞。現在服務器驗證用戶憑證。

問題： 是通過https安全地將密碼從服務器傳遞到瀏覽器的javascript變量？

我的意見

• 的 瀏覽器和服務器之間的整個事務是通過HTTPS和 密碼是通過POST方法傳遞的 - 這樣的密碼是安全的。
• 的密碼是通過「視圖 頁面源代碼」可見，因爲它被分配到 一個javascript變量 - 如果 瀏覽器插件可以訪問 頁面內容並不安全。但是，如果瀏覽器插件 可以訪問頁面內容，那麼當用戶輸入密碼時，它甚至可以訪問密碼，因此該流程不會引入新的 威脅。

注

• 我知道他們是更好的方式來處理這個 流。但我對 感興趣，無論我們現有的流量是否安全 或不。
• 對安全提示的任何參考將對您有所幫助。

Answer 1

更大的問題是最佳實踐 - 你只是不需要這樣做，這是不好的做法。這表明對整體安全性的理解很差 - 最好不要以明文形式存儲密碼。如果你的程序員同事沒有給出這個概念的適當信任，那麼我會建議他們可能有其他方面的觀察，安全明智的鬆懈。

Security is a mindset，不是最低公分母。這是爲了儘可能減少妥協的機會，儘可能給予儘可能小的楔形空間。

不存儲明文密碼是你應該做的，而不是「當我們想要的時候存儲它們，除非有人能證明它是壞的」。

對此感興趣，「無害失敗」 - 情況下，惡意用戶可以導致 異常但不直接有害 結果 - 是 安全觀念的另一個標誌。並非所有「無害 故障」導致大麻煩，但 這是令人驚訝的一個聰明的 攻擊者可以多長時間堆積的 看似無害的故障堆棧成的麻煩一個 危險塔。無害 故障是不良的衛生。我們儘量將 戳掉。

http://freedom-to-tinker.com/blog/felten/security-mindset-and-harmless-failures

Answer 2

傳輸將是安全的。但發送響應並不合適，因爲瀏覽器會將該值緩存在頁面中。有人可能會惡意查看頁面的來源並查看密碼。

你可以通過傳遞服務器會話密鑰來做到這一點嗎？

Answer 3

當然，交易本身可能是安全的，不受某些攔截形式的影響，但是您可能面臨許多其他不依賴攔截請求/響應活動的攻擊。如果網站的某個頁面容易受到跨頁面腳本和惡意JavaScript的攻擊，那該怎麼辦？