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