Web應(yīng)用程序應(yīng)有多安全？ 好吧，對于我們許多Web開發(fā)人員來說，這個(gè)問題沒有多大意義。 “應(yīng)用程序必須盡可能地安全。 它越安全，就越好。” 但這不是一個(gè)確定的答案。 形成項(xiàng)目的安全策略無濟(jì)于事。 此外，僅遵循該單一指令（“越安全越好”）可能被證明是一種不良服務(wù)。 為什么？ 這就是我將在本文中討論的內(nèi)容。

安全性通常會(huì)使可用性變差

過多的安全檢查無疑會(huì)使應(yīng)用程序更煩人。 通常，對于應(yīng)用程序的兩個(gè)部分來說，它都是正確的：身份驗(yàn)證和忘記密碼功能。

除密碼外，多階段身份驗(yàn)證還包括SMS驗(yàn)證和其他保護(hù)字段，使用戶體驗(yàn)更加安全，但樂趣更少。 如果您的所有服務(wù)都允許與其他用戶交換有趣的圖片，那么用戶當(dāng)然不會(huì)欣賞您嘗試使自己的體驗(yàn)更加安全的嘗試。

最佳安全做法建議在身份驗(yàn)證錯(cuò)誤的情況下顯示盡可能少的信息，以防止入侵者收集用戶列表。 根據(jù)此建議，如果用戶經(jīng)歷了33個(gè)驗(yàn)證階段并在一個(gè)字段中輸入了錯(cuò)誤，則最好的解決方案是顯示一條消息，例如：“對不起，出了點(diǎn)問題。 請?jiān)僭囈槐椤薄?在這種情況下，用戶不太可能會(huì)感受到對開發(fā)人員的感激和對他們?yōu)槭褂脩趔w驗(yàn)盡可能安全所付出的努力的真誠欽佩。

您必須完全意識(shí)到，在這種情況下，用戶體驗(yàn)會(huì)變得更糟，并確定在您的特定情況下這是否可以接受。

安全性使應(yīng)用程序難以開發(fā)和支持

應(yīng)用程序擁有的防御機(jī)制越多，它的復(fù)雜性就越高。 創(chuàng)建應(yīng)用程序某些部分所需的時(shí)間可能會(huì)增加幾倍，以包括較小的安全性改進(jìn)。

僅使入侵者的生活更令人沮喪，而不是解決實(shí)際的安全問題，就需要花費(fèi)很多精力。 例如，項(xiàng)目可以選擇在其REST API中混淆方法名稱和參數(shù)名稱。

通常，開發(fā)人員會(huì)花費(fèi)大量時(shí)間來阻止入侵者通過登錄表單，注冊表單和忘記密碼的表單來獲取用戶名列表。

有一些方法，當(dāng)應(yīng)用程序?qū)⒂脩魳?biāo)記為入侵者，但不泄露它。 所有用戶請求都將被忽略。

如果多階段身份驗(yàn)證過程包含一個(gè)秘密問題（對于每個(gè)用戶而言都是唯一的），那么我們?nèi)匀豢梢詾闂l目中不存在的用戶名顯示一個(gè)問題。 而且，應(yīng)用程序可以在會(huì)話或數(shù)據(jù)庫中存儲(chǔ)此用戶名和顯示的問題，以始終要求相同的信息。

還有許多其他方法可以使入侵者感到困惑。 但是可以肯定的是，它們都需要時(shí)間來實(shí)施。 即使編寫得很好并且有注釋，這種邏輯即使對于其作者來說也可能是錯(cuò)綜復(fù)雜的。 但是最重??要的是，它實(shí)際上并沒有解決任何安全問題，只是阻止了發(fā)現(xiàn)此類問題。

將“精心設(shè)計(jì)且真正安全的功能”與“具有假想的黑客的狂野游戲”區(qū)分開來，并不總是那么容易。 尤其是因?yàn)檫@兩個(gè)極端之間的優(yōu)勢不是絕對的，并且很大程度上取決于您的應(yīng)用程序?qū)撛诤诳陀卸啻笪Α?

安全性使應(yīng)用程序更難測試

我們所有的安全邏輯都必須經(jīng)過測試。 單元測試，集成測試或手動(dòng)測試–我們應(yīng)該為我們擁有的每個(gè)安全機(jī)制選擇一種合適的方法。

我們不能僅僅放棄測試我們的防御邏輯，因?yàn)殄e(cuò)誤往往會(huì)出現(xiàn)在我們的工作中。 即使我們一開始就能正確編寫所有內(nèi)容，也總是有機(jī)會(huì)在維護(hù)，支持和重構(gòu)期間添加錯(cuò)誤。 沒有人通過編寫遺留代碼來啟動(dòng)項(xiàng)目。 該代碼隨著時(shí)間的流逝而成為傳統(tǒng)。

全面測試所有業(yè)務(wù)邏輯是不明智的，但是同時(shí)假設(shè)我們的安全機(jī)制是完美，絕對和無錯(cuò)誤的。

如果將對安全性邏輯進(jìn)行手動(dòng)測試，則存在一個(gè)問題，即必須多久執(zhí)行一次。 如果我們的應(yīng)用程序或多或少復(fù)雜，那么可能會(huì)有數(shù)十個(gè)（如果不是數(shù)百個(gè)）身份驗(yàn)證失敗的地方。 例如，如果在某些請求中某些ID參數(shù)被更改，則服務(wù)器將返回我們不可訪問的信息。 檢查每個(gè)類似的可能情況都需要大量工作。 我們是否應(yīng)該在每個(gè)主要版本之前檢查它？ 我們應(yīng)該為此任務(wù)分配一個(gè)人嗎？ 還是我們應(yīng)該為此組成整個(gè)團(tuán)隊(duì)？

這些問題很重要。 破碎的身份驗(yàn)證可以輕松地引入到項(xiàng)目中。 在對模型進(jìn)行任何微小更改并添加新的REST方法時(shí)，我們必須保持警惕。 這個(gè)問題沒有簡單通用的答案。 但是有些方法可以在整個(gè)項(xiàng)目中始終如一地處理問題。 例如，在CUBA平臺(tái)中，我們使用角色和訪問組 。 它們允許配置哪些實(shí)體可供哪些用戶訪問。 配置這些規(guī)則仍有一些工作，但是規(guī)則本身是統(tǒng)一且一致的。

除了身份驗(yàn)證損壞之外，還應(yīng)該測試許多安全問題。 在實(shí)施新的機(jī)制或邏輯時(shí)，我們必須考慮如何對其進(jìn)行測試。 未經(jīng)測試的事物會(huì)隨著時(shí)間的流逝而破裂。 而且，我們不僅在安全方面遇到問題，而且對一切都會(huì)好起來也抱有一種錯(cuò)誤的信心。

造成最大麻煩的安全性機(jī)制有兩種：僅在產(chǎn)品環(huán)境中起作用的機(jī)制和代表第二層（第三層，第四層）安全性的機(jī)制。

僅在生產(chǎn)中起作用的防御機(jī)制。 假設(shè)有一個(gè)會(huì)話令牌cookie，它必須具有“安全”標(biāo)志。 但是，如果我們在測試環(huán)境中到處使用HTTP，則意味著測試和生產(chǎn)有單獨(dú)的配置。 因此，我們不完全測試將要發(fā)布的產(chǎn)品。 在遷移和各種更改期間，“安全”標(biāo)志可能會(huì)丟失。 而且，我們甚至都不會(huì)注意到。 我們?nèi)绾翁幚磉@個(gè)問題？ 我們是否應(yīng)該引入另一個(gè)可以用作預(yù)生產(chǎn)的環(huán)境？ 如果是這樣，那么應(yīng)該在此環(huán)境中測試我們功能的哪一部分？

多層防御機(jī)制。 有安全問題經(jīng)驗(yàn)的人傾向于創(chuàng)建一個(gè)安全邏輯，只有在關(guān)閉其他安全機(jī)制后才能對其進(jìn)行測試。 這實(shí)際上是有道理的。 即使入侵者設(shè)法在安全屏障的第一層中找到漏洞，他也將被困在第二層。 但是應(yīng)該如何測試呢？ 這種方法的典型示例是為應(yīng)用程序的不同用戶使用不同的數(shù)據(jù)庫用戶。 即使我們的REST API包含損壞的身份驗(yàn)證，黑客也將無法編輯或刪除任何信息，因?yàn)閐b用戶沒有執(zhí)行這些操作的權(quán)限。 但是，顯然，如果維護(hù)和測試不當(dāng)，此類配置往往會(huì)過時(shí)和破壞。

許多安全機(jī)制使我們的應(yīng)用程序不太安全

我們擁有的防御檢查越多，應(yīng)用程序就越復(fù)雜。 應(yīng)用程序越復(fù)雜，出錯(cuò)的可能性就越高。 出錯(cuò)的可能性越高，我們的應(yīng)用程序的安全性就越差。

再次讓我們考慮一個(gè)登錄表單。 使用兩個(gè)字段來實(shí)現(xiàn)登錄表單非常簡單：用戶名和密碼。 我們需要做的就是檢查系統(tǒng)中是否有用戶使用提供的名稱，以及是否正確輸入了密碼。 嗯，也建議檢查我們的應(yīng)用程序沒有顯示在哪個(gè)字段中犯了錯(cuò)誤，以防止入侵者獲取用戶名，盡管某些應(yīng)用程序可以犧牲這種做法來獲得更好的用戶體驗(yàn)。 無論如何，我們還必須實(shí)施某種蠻力防御機(jī)制。 當(dāng)然，那不應(yīng)該包含故障開放漏洞。 最好不要向入侵者透露我們知道他是入侵者，這也是一個(gè)好主意。 我們可以無視他的要求。 讓他認(rèn)為他正在繼續(xù)入侵我們。 要檢查的另一件事是，我們不記錄用戶密碼。 好吧，實(shí)際上還有很多不那么重要的事情要考慮。 總而言之，標(biāo)準(zhǔn)的登錄表單是小菜一碟，不是嗎？

多階段身份驗(yàn)證是完全不同的事情。 可以將某種令牌發(fā)送到電子郵件地址或通過SMS發(fā)送。 或者可以有幾個(gè)步驟，涉及輸入越來越多的信息。 這一切都是相當(dāng)復(fù)雜的。 從理論上講，這種方法應(yīng)減少用戶帳戶被黑客入侵的可能性。 如果功能實(shí)現(xiàn)正確，那么情況就是如此。 仍然有可能被黑客入侵（也不會(huì)發(fā)送短信，電子郵件，也不會(huì)給我們100％的保證），但是通過這種方式，它會(huì)減少。 但是已經(jīng)很復(fù)雜的身份驗(yàn)證邏輯變得更加復(fù)雜。 并且犯錯(cuò)的可能性增加。 而且，與僅是一個(gè)具有2個(gè)字段的簡單表格相比，單個(gè)錯(cuò)誤的存在將證明我們的新模型不那么安全。

而且，侵入性和不便的安全措施可能迫使用戶以較低的安全性來存儲(chǔ)其敏感數(shù)據(jù)。 例如，如果在公司網(wǎng)絡(luò)中需要每月更改一次密碼，則不了解這種煩人措施的用戶可能會(huì)開始將他們的密碼寫在貼紙上并放在屏幕上。 “如果用戶犯下此類愚蠢行為，這完全是用戶的錯(cuò)”，您可以反對。 也許。 但這絕對也是您的問題。 歸根結(jié)底，作為開發(fā)人員的最終目標(biāo)不是滿足用戶需求嗎？

那你在暗示什么？

我建議從一開始就決定我們準(zhǔn)備走多遠(yuǎn)的路來阻止入侵者。 我們是否準(zhǔn)備好優(yōu)化登錄表單，以使登錄請求的響應(yīng)時(shí)間不會(huì)顯示是否存在具有該名稱的用戶？ 我們是否準(zhǔn)備好實(shí)施如此可靠的檢查，以至于甚至坐在受害者手機(jī)旁的受害者的密友也無法訪問應(yīng)用程序？ 為了使入侵者的生活更加痛苦，我們是否準(zhǔn)備好使開發(fā)復(fù)雜化數(shù)倍，增加預(yù)算并犧牲良好的用戶體驗(yàn)？

我們可以無休止地致力于安全性，建立新的保護(hù)層，改善監(jiān)視和用戶行為分析，阻礙信息的獲取。 但是，我們應(yīng)該劃清界限，將我們必須做的事情與我們不應(yīng)做的事情區(qū)分開。 當(dāng)然，在項(xiàng)目發(fā)展過程中，可以重新考慮和移動(dòng)這條線。

在最壞的情況下，項(xiàng)目可能會(huì)花費(fèi)大量資源來構(gòu)建對一種攻擊的強(qiáng)大防御，而在其他地方卻存在巨大的安全漏洞。

在做出選擇時(shí)，如果我們要實(shí)現(xiàn)某種安全性機(jī)制或要建立另一層安全性，則必須考慮許多事項(xiàng)：

• 利用漏洞有多容易？ 破損的身份驗(yàn)證很容易被利用。 而且它不需要任何認(rèn)真的技術(shù)背景。 因此，該問題很重要，應(yīng)相應(yīng)處理。
• 漏洞有多嚴(yán)重？ 如果入侵者能夠獲取有關(guān)其他用戶的敏感信息，或者更糟的是可以對其進(jìn)行編輯，那么這將是一個(gè)非常嚴(yán)重的問題。 如果入侵者可以收集我們系統(tǒng)某些產(chǎn)品的ID，而又不能將這些ID用于任何特別有趣的事情，那么問題就不那么嚴(yán)重了。
• 如果實(shí)現(xiàn)此功能，應(yīng)用程序?qū)⒂卸嗌侔踩?#xff1f; 如果我們正在談?wù)摳郊拥陌踩珜?#xff08;例如，檢查輸出中的XSS問題，或者已經(jīng)實(shí)現(xiàn)了一種很好的輸入清理機(jī)制），或者我們只是試圖使入侵者的生活更艱難（例如，嘗試掩蓋我們將他標(biāo)記為黑客的事實(shí)），那么這些更改的優(yōu)先級(jí)就不高。 也許它們可能根本沒有實(shí)現(xiàn)。
• 需要多少時(shí)間？
• 它要花多少錢？
• 用戶體驗(yàn)會(huì)惡化多少？
• 維護(hù)和測試功能有多困難？ 通常的做法是從不嘗試訪問受限資源時(shí)就返回403代碼，而總是返回404代碼。 這將使收集資源標(biāo)識(shí)符變得更加困難。 盡管該解決方案使獲取有關(guān)系統(tǒng)的信息更加困難，但同時(shí)使測試和生產(chǎn)錯(cuò)誤分析變得復(fù)雜。 而且它甚至可能被證明對用戶體驗(yàn)有害，因?yàn)楸M管存在這種資源，但用戶由于某種原因而變得不可訪問，因此用戶可能會(huì)收到一個(gè)混亂的消息，即沒有這種資源，這對用戶體驗(yàn)是有害的。

好吧，可以肯定的是，在您的特定情況下，可能需要多階段身份驗(yàn)證機(jī)制。 但是，您必須完全了解它以何種方式阻礙開發(fā)并降低用戶對應(yīng)用程序的興趣。

您正在證明對安全采取疏忽大意的方法

好吧，我不是。 當(dāng)然會(huì)有一些安全敏感的應(yīng)用程序，這些應(yīng)用程序?qū)钠渌踩胧┲惺芤妗?即使這些措施增加了費(fèi)用并破壞了用戶體驗(yàn)。

而且，當(dāng)然，無論多么小，許多漏洞都不會(huì)出現(xiàn)在任何應(yīng)用程序中。 CSRF是此類漏洞的典型示例。 捍衛(wèi)它不會(huì)使用戶體驗(yàn)惡化，也不會(huì)花費(fèi)很多。 許多服務(wù)器端框架（例如Spring MVC）和前端框架（例如Angular）允許開箱即用地支持CSRF令牌。 此外，借助Spring MVC，我們可以快速添加任何必需的安全標(biāo)頭：Access-Control- *標(biāo)頭，Content-Security-Policy等。

不允許在我們的應(yīng)用程序中使用斷開的身份驗(yàn)證，XSS，SQL注入和其他一些漏洞。 對它們的防御很容易掌握，并且在各種書籍和文章中都有很好的解釋。 我們還可以添加到此列表中，在URL參數(shù)內(nèi)傳遞敏感信息，并存儲(chǔ)弱散列密碼和其他不良安全做法。

最好以最佳方式在項(xiàng)目中包含清單，該清單描述該項(xiàng)目的安全策略并回答以下問題：

• 我們遵循哪些安全規(guī)范？
• 我們的密碼政策是什么？
• 我們測試什么以及多久測試一次？
• 等等

對于不同的項(xiàng)目，此宣言將有所不同。 如果程序在OS命令中插入了用戶輸入，則安全策略必須包含有關(guān)如何安全執(zhí)行此操作的說明。 如果項(xiàng)目可以將文件（例如頭像）上載到服務(wù)器，則安全策略必須枚舉可能的安全問題以及如何處理它們。

當(dāng)然，創(chuàng)建和支持這樣的宣言并非易事。 但是，期望團(tuán)隊(duì)中的每個(gè)成員（包括質(zhì)量保證和支持）記住并堅(jiān)持他必須執(zhí)行的每個(gè)安全實(shí)踐，這是一種幼稚的做法。 此外，存在一個(gè)問題，對于許多漏洞，有幾種方法可以處理它們。 而且，如果對此事沒有明確的政策，則可能發(fā)生在某些地方，開發(fā)人員使用一種做法（例如，他們驗(yàn)證輸入信息），而在其他地方，他們做的事情完全不同（例如，對輸出進(jìn)行消毒）。 。 即使代碼是好的和純凈的，它仍然是不一致的。 不一致是錯(cuò)誤，支持問題和錯(cuò)誤期望的理想之地。

對于具有恒定技術(shù)負(fù)責(zé)人的小命令，代碼審查可能足以避免上述問題，即使沒有宣言。

摘要：

• 在安全性方面，我們應(yīng)該考慮我們的應(yīng)用程序如何對安全性敏感。 銀行應(yīng)用程序和共享有趣故事的應(yīng)用程序需要不同的方法。
• 在安全性方面，我們應(yīng)該考慮對用戶體驗(yàn)的危害。
• 在安全性方面，我們應(yīng)該考慮它將使代碼復(fù)雜化并增加維護(hù)難度。
• 安全機(jī)制應(yīng)進(jìn)行測試。
• 建議教團(tuán)隊(duì)成員如何處理安全問題和/或?qū)?xiàng)目中的每次提交進(jìn)行徹底的代碼審查。
• 每個(gè)應(yīng)用程序都必須消除某些漏洞：XSS，XSRF，注入（包括SQL注入），破壞的身份驗(yàn)證等。

翻譯自: https://www.javacodegeeks.com/2018/07/web-application-security.html

總結(jié)

以上是生活随笔為你收集整理的Web应用程序安全性：战斗自己或寻找理智的边缘的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。