我目前正在開發一個 java 后端 和一個 使用 php、html 和javascript 用于私人項目（但我最終希望將其開源），這意味著無論如何訪問都僅限于我的 LAN，并且安全性目前并不發揮重要作用但將來可能會。由于我最喜歡用 Java 進行編碼，因此大多數數據處理和存儲（MySQL）都是用 Java 處理的，并通過 http 提供給前端（javascript; fetch()）。此外，java 后端處理身份驗證進程意味著我必須通過 javascript 中的 fetch 調用將登錄憑據傳遞到后端。由于我并不真正喜歡高級網絡編程，所以我想了一個基本的 POST ->重定向->登錄的 GET 設置應該足夠了，我之前使用過類似的登錄過程（但在 PHP 中處理身份驗證）。所以：客戶填寫HTML-Form并提交瀏覽器向 /login 發出 POST 請求并傳遞憑據 和目標頁面PHP 然后返回包含 javascript 部分 的 HTML，該部分以純文本形式保存憑據 login("<?php echo $_POST['username'] ?>", "<?php echo $_POST['password'] ?>", "<?php echo $_POST['target'] ?>");Javascript 然后獲取 java后端創建會話憑據 使用這些Javascript 問題window.location.replace(target);并且客戶端被重定向到目標頁面（其中通過會話 cookie 處理身份驗證）我目前正在過度思考，從效率和安全的角度來看這是否是一個好主意。我目前的想法是使用表單通過javascript直接將數據獲取到后端，而不是使用POST請求到附加頁面（跳過上面的步驟2和3）：這意味著首先 PHP 永遠不會看到憑據（這將減少一個故障點）并且憑據可能不會顯示在 HTML 中。此外，這會減少加載時間，因為不再需要 POST。因此我的問題是：在 HTML 中顯示憑據是否是一種不好的安全做法（就像在 URL 中顯示憑據一樣，以防止用戶在復制 URL 時意外將其憑據發送給某人）？與此相關的風險是什么？這些憑證可以被任何使用的 JS 庫或瀏覽器擴展讀取嗎？如果是這樣，那些人可能也可以讀取我在表單中輸入的憑據？從安全角度（和效率角度）來看，我的替代設置是否更好？在這種情況下還有其他提高安全性的建議嗎？感謝你們對我的幫助。
1 回答
函數式編程
TA貢獻1807條經驗 獲得超9個贊
這篇文章的簡短摘要和下面的討論：
首先將憑據發布到 PHP，然后在返回的 HTML 中將它們返回給客戶端，延遲（由于附加頁面負載）增加，PHP 被添加為另一個故障點并且理論上，該系統可能會面臨更多安全問題（即通過 JavaScript 或瀏覽器擴展掃描代碼或黑客攻擊 PHP 服務器）。
因此，有兩種解決方案是合理的：
完全跳過 PHP 并讓登錄由 javascript 和 < 處理僅 a i=4>java 后端（此過程的詳細說明說明如下 第 1 - 5 點；這僅是可能的，因為 PHP 服務器在此特定用例中不需要身份驗證信息< a i=11>)
將憑據 POST 到 PHP，并讓 PHP 與負責身份驗證的 java 后端通信將它們保留給客戶
原帖：
我不太明白為什么你認為 PHP 后端不可信，但在你的方案中，PHP 已經獲得了你的憑據，這要歸功于原始的 POST。如果您想避免使用 PHP，為什么不讓您的表單調用 JavaCcript 函數，而不是首先 POST 到 PHP 后端：
用戶輸入憑據
用戶點擊“登錄”
JavaScript 攔截登錄嘗試，調用login()
JavaScript 從文檔正文 () 獲取
user,passgetElementById(...)JavaScript 聯系處理登錄的 Java 后端
無需 PHP。但我可能想知道為什么這是必要的 - 如果您不能信任自己的后端，那么您的安全實踐到底是什么？如果你的 PHP 不可信，為什么你的 Java 會更好呢？
在您的方案中，您已經在 POST 請求中將憑據傳遞到 PHP 后端。如果您擔心 PHP 不知道憑據，那么您已經失敗了。
至于效率，您的方案有額外的頁面加載，這將使用帶寬，最大化延遲（而不是最小化延遲的目標），并且讓注意到額外重定向的用戶認為您無能。 JavaScript 聽起來更好的解決方案是您想用 Java 編寫數據庫代碼。
就 HTML 中顯示的憑據而言，實際上沒有區別，因為唯一可以訪問它們的人就是用戶（已經輸入了這些憑據的人）。如果他們輸入不正確的憑據，他們只會看到不正確的憑據。 也就是說，它違反了最佳實踐，而且可能不是一個好主意。
在 HTML 中顯示憑據是否是一種不好的安全做法（就像在 URL 中顯示憑據一樣，以防止用戶在復制 URL 時意外將其憑據發送給某人）？與此相關的風險是什么？這些憑證可以被任何使用的 JS 庫或瀏覽器擴展讀取嗎？如果是這樣，那些人可能也可以讀取我在表單中輸入的憑據？
答案是肯定的，這完全是不好的做法，會讓您面臨額外的風險。他們可能不太關心，但你說得完全正確——惡意代碼可以在更多地方讀取憑據，并且任何 JS 庫或安裝的擴展都可以讀取它們。
從安全角度（和效率角度）來看，我的替代設置是否更好？
不，不。從安全角度來看，它增加了另一個故障點；他們可以選擇破解 PHP 后端，而不是需要破解 Java 后端。這不一定是世界末日，但是一個額外的故障點。
在這種情況下還有其他提高安全性的建議嗎？
我在上面解釋了我的建議。要么接受它并使用 PHP，要么使用 JavaScript 完全繞過 PHP。
還有一件事，在處理登錄時，請確保 Java 傳遞一個秘密值（每個會話都是唯一的），并且服務器會在每個頁面加載時驗證該值< a i=2>.當我作為道德黑客工作時，我測試的應用程序通過了身份驗證令牌（OAuth2），但服務器實際上并未驗證它是否正確，只是客戶端說它是有效的。確保服務器檢查客戶端所做的任何事情。
此外，強調每個會話都是唯一的，因為每個會話都保持相同的秘密值肯定是保存最差的你曾經希望沒有泄露的秘密。
- 1 回答
- 0 關注
- 167 瀏覽
添加回答
舉報
0/150
提交
取消