更新日誌：OWASP Top 10 項目

已發表: 2022-03-11

在過去十年中，Web 應用程序的複雜性呈爆炸式增長。 它們已經從用於聯繫表格和民意調查的簡單容器發展成為成熟的應用程序。 我們可以將它們與大型桌面應用程序進行比較，無論是在大小上還是在性能上。 隨著複雜性的急劇上升和功能豐富的應用程序數量的增加，投入大量時間和精力使所有應用程序組件盡可能安全已成為必要。 互聯網用戶的大量增加使得解決保護數據和應用程序用戶的問題變得更加重要。 有大量的威脅試圖潛入並給所有相關人員帶來嚴重的頭痛。

2001年，一個新的組織進入了舞台。 它的目標是解決影響網站和應用程序的安全問題。 它被恰當地命名為開放 Web 應用程序安全項目 (OWASP)。 如今，它發布資源，組織會議，並提出有關 Web 和應用程序安全的標準。 Web 應用程序安全的事實標準是 OWASP 十大項目。 它列出了十個最普遍的安全威脅。 決定什麼進入的影響因素是大量的數據和社區反饋。 2017 年底，該項目進行了更新。 對許多現代 Web 應用程序至關重要的幾個新問題獲得了它們的位置，而有些則從列表中逃脫了。

本文對原始列表進行了補充，並說明了列表的最新更改。 它描述了威脅，試圖提供清晰的例子以便於理解，並提出應對安全威脅的方法。

從 OWASP 前 10 名列表中刪除的問題

在 2017 年更新之前，2013 年的列表是最新的。 考慮到現在構建和使用 Web 應用程序的方式發生了變化，只有進行徹底的修改才有意義。 微服務正在分一杯羹，新的酷炫的框架正在取代普通的代碼戰鬥裝備。 這些事實意味著之前列出的一些威脅已被刪除，而一些新威脅則取而代之。

我們將確保在本文中刷新我們對長期被遺忘的問題的記憶，並介紹新的壞狼。 了解歷史是避免重蹈覆轍的唯一可靠方法。

跨站請求偽造

跨站點請求偽造（CSRF）是該項目最近迭代中的“失敗者”之一。 它消失了，因為許多現代 Web 框架都包含 CSRF 防禦機制。 因此，將您的應用程序暴露在威脅之下的可能性會迅速降低。

不管 CSRF 退出列表，刷新我們的記憶還是不錯的。 讓我們確保它不會比以往更強大。

從本質上講，CSRF 是一種感覺就像煙霧彈的漏洞利用。 攻擊者誘騙毫無戒心的用戶在 Web 應用程序中執行不需要的請求或操作。 簡而言之，攻擊者強迫其受害者向第三方應用程序發送請求，而受害者不知道該請求已被發送。 該請求可能是一個用於檢索資源的 HTTP GET 請求，或者更糟糕的是，一個 HTTP POST 請求會更改受害者控制下的資源。 在攻擊過程中，受害者認為一切都很好，通常甚至沒有註意到後台發生了什麼。 空氣淨化後，損壞或丟失了什麼，沒有人知道發生了什麼。

目標應用程序中成功的先前用戶身份驗證使陷阱有效。 用戶在攻擊之前的某個時間點登錄了應用程序。 應用程序向受害者發送了一個 cookie 來記住他們。 一旦 Web 瀏覽器發送惡意請求，cookie 就會與任何潛在的有效負載一起自動發送，並且應用程序不會反對將請求提供給它已經知道的用戶。

最著名的例子之一是欺騙用戶將錢從他們的賬戶轉移到攻擊者控制的賬戶。 用戶登錄電子銀行系統以檢查其帳戶餘額。 之後，他們訪問一個在線論壇，查看新手機的評論。 一名攻擊者用炸藥釣魚，發布了一條評論，其中包括一張帶有看似損壞的圖像超鏈接的圖像。 攻擊者沒有使用真正的超鏈接，而是使用電子銀行系統內部使用的超鏈接將資金從賬戶 A 轉移到賬戶 B： https://payments.dummybank.com?receiver=attacker&amount=100 ://payments.dummybank.com?receiver=attacker&amount=100。 銀行系統將經過身份驗證的用戶設為發送方，將“接收方”參數中的值設為資金的接收方。 當然，攻擊者將他們的離岸賬戶指定為接收方。

由於瀏覽器在呈現頁面時會自動加載圖像，因此請求發生在後台。 如果銀行的支付系統使用 HTTP GET 請求實現匯款，那麼沒有什麼可以阻止災難的發生。 請注意，該示例很簡單，並且很可能傳輸不是通過 HTTP GET 處理的。 然而，攻擊者可以稍微困難一點，設法改變論壇的 HTML 消息發布表單中的屬性“action”。 然後瀏覽器將請求發送到銀行的支付系統，而不是論壇的後端。

偷錢只是眾多例子之一。 更改用戶的電子郵件地址或進行意外購買也屬於此類。 正如經常發生的那樣，社會工程和一些技術知識是防止軟件工程錯誤的有效手段。

在設計系統時，請牢記以下幾點：

  • 不要使用 HTTP GET 請求來封裝修改資源的操作。 您應該只使用這些請求來檢索信息。 請記住，經驗法則是使 GET 請求具有冪等性。
  • Do ，當使用 HTTP POST 請求在內部傳輸數據時，傾向於以 JSON、XML 或其他格式發送數據，而不是將參數編碼為查詢字符串。 使用重要的數據格式可以降低有人創建虛假 HTML 表單的危險，該表單會將數據發送到您的服務。
  • 請確保在您的 HTML 表單中創建並包含一個唯一且不可預測的標記。 這些令牌對於每個請求也應該是唯一的。 檢查此類令牌的存在和正確性將降低發生威脅的風險。 要找出令牌並在他們的虛假請求中使用它，攻擊者需要訪問您的系統並直接從那裡獲取令牌。 由於令牌是一次性的，因此它們不能在惡意代碼中重複使用它們。

當與跨站點腳本 (XSS) 結合使用時，此漏洞會產生更嚴重的影響。 如果攻擊者可以將惡意代碼注入到喜歡的網站或應用程序中，那麼攻擊的範圍就會變得更加嚴重和危險。 更關鍵的是，如果可能發生 XSS 攻擊，攻擊者可以繞過一些針對 CSRF 的保護機制。

請記住，CSRF 並沒有消失，只是不像以前那麼普遍了。

CSRF 運行圖 - 從 OWASP 前 10 名中刪除

未經驗證的重定向和轉發

許多應用程序在完成一個操作後，會將用戶重定向或轉發到同一應用程序的另一部分，甚至是其他應用程序。 例如，成功登錄應用程序會觸發重定向到主頁或用戶最初訪問的頁面。 很多時候，目的地是表單操作或鏈接地址的一部分。 如果處理重定向或轉發的組件不能確保目標地址確實是應用程序生成的地址，就會出現潛在威脅。 這是一個稱為“未經驗證的重定向和轉發”的安全漏洞。

未經驗證的重定向和轉發被認為是危險的兩個主要原因是網絡釣魚和憑據劫持。 攻擊者可以設法更改重定向/轉發目標位置，並將用戶發送到與原始應用程序幾乎無法區分的惡意應用程序。 毫無戒心的用戶會向惡意第三方洩露他們的憑據和機密信息。 在他們意識到發生了什麼之前，已經為時已晚。

例如，Web 應用程序通常會通過支持重定向到上次訪問的頁面來實現登錄。 為了能夠輕鬆地做到這一點，HTML 表單的 action 屬性可能類似於http://myapp.example.com/signin?url=http://myapp.example.com/puppies 。 您是小狗的超級崇拜者，因此安裝瀏覽器擴展程序將網站圖標替換為您最喜歡的小狗的縮略圖是有意義的。 不幸的是，這是一個狗咬狗的世界。 瀏覽器擴展的作者決定兌現你無條件的愛，並引入一個額外的“功能”。 每次您訪問您最喜歡的小狗粉絲網站時，它都會將表單操作屬性中的“url”參數替換為指向他們自己網站的鏈接。 由於該網站看起來完全一樣，當您提供信用卡詳細信息來購買小狗撲克牌時，您實際上是在資助惡意攻擊者，而不是您的愛好。

解決該漏洞涉及通過確保它是預期位置來檢查目標位置。 如果框架或庫執行完整的重定向或轉發邏輯，則檢查實現並在必要時更新代碼是有益的。 否則，您需要進行手動檢查以防止攻擊。

您可以進行多種類型的檢查。 為了獲得最佳保護，請結合使用幾種方法，而不是只使用其中一種。

  • 驗證傳出 URL，確保它指向您控制的域。
  • 不要使用顯式地址，而是在前端對其進行編碼，然後在後端對其進行解碼和驗證。
  • 準備可信 URL 的白名單。 僅允許轉發和重定向到列入白名單的位置。 更喜歡這種方法來維護黑名單。 黑名單通常只有在發生不好的事情時才會填充新項目。 白名單更具限制性。
  • 採用 LinkedIn 和其他一些應用程序使用的方法：向您的用戶展示一個頁面，要求他們確認重定向/轉發，明確他們將離開您的應用程序。

合併問題

清單上的大多數問題都可以被標記為實施中的缺陷，要么是由於缺乏知識，要么是對潛在威脅的深入調查不夠深入。 這兩個原因都可以歸結為缺乏經驗，未來考慮它們的解決方案很容易——只要確保學得更多、更透徹。 一個特別棘手的問題依賴於做出太多假設的危險（但非常人性化）特徵以及開發和維護複雜計算機系統的困難。 屬於此類別的漏洞是“訪問控制損壞”。

損壞的訪問控制

漏洞是由於應用程序某些部分的授權和訪問控制不足或完全缺乏而導致的。 在 OWASP 十大項目的先前迭代中，存在兩個問題：不安全的直接對象引用和缺少函數級訪問控制。 由於它們的相似性，它們現在合併為一個。

直接對象引用

URL 中經常使用直接對象引用來標識正在操作的資源。 例如，當用戶登錄時，他們可以通過單擊包含其個人資料標識符的鏈接來訪問他們的個人資料。 如果相同的標識符存儲在數據庫中並用於檢索個人資料信息，並且應用程序假設人們只能通過登錄頁面訪問個人資料頁面，則更改 URL 中的個人資料標識符會公開另一個用戶的個人資料信息。

設置刪除配置文件表單http://myapp.example.com/users/15/delete的 URL 的應用程序清楚地表明該應用程序中至少有 14 個其他用戶。 在這種情況下，弄清楚如何獲得其他用戶的刪除表單並不是火箭科學。

此問題的解決方案是對每個資源執行授權檢查，而不假設只能採用某些路徑來訪問應用程序的某些部分。 此外，刪除直接引用並使用間接引用是向前邁出的又一步，因為它使惡意用戶很難弄清楚引用是如何創建的。

在開發過程中，作為預防措施，寫下一個簡單的狀態機圖。 讓狀態代表應用程序中的不同頁面，並轉換用戶可以採取的操作。 這使得列出所有需要特別注意的轉換和頁面變得更加容易。

狀態機圖的說明

缺少功能級訪問控制

缺少函數級訪問控制與不安全的直接對象引用非常相似。 在這種情況下，用戶修改 URL 或其他一些參數以嘗試訪問應用程序的受保護部分。 如果沒有適當的訪問控制檢查訪問級別，則用戶可以獲得對應用程序資源的特權訪問或至少對其存在的一些了解。

借用直接對象引用的示例，如果應用程序假設訪問刪除表單的用戶是超級用戶只是因為超級用戶可以看到刪除表單的鏈接，而無需進行任何進一步的授權，那麼就會出現巨大的安全漏洞。 指望某些 UI 元素的可用性不是正確的訪問控制。

通過始終確保在應用程序的所有層中執行檢查來解決該問題。 前端界面可能不是惡意用戶訪問您的域層的唯一途徑。 此外，不要依賴用戶傳遞的有關其訪問級別的信息。 執行適當的會話控制並始終仔細檢查接收到的數據。 僅僅因為請求正文說用戶是管理員，並不意味著他們是管理員。

損壞的訪問控制現在結合了與訪問控制不足相關的所有問題，無論是在應用程序級別還是系統級別，例如文件系統的錯誤配置。

訪問控制損壞示意圖

OWASP Top 10 列表中的新問題

新前端框架的出現和新軟件開發實踐的採用將安全問題轉移到全新的主題。 新技術還設法解決了我們之前手動處理的一些常見問題。 因此，修改清單並根據現代趨勢對其進行調整變得有益。

XML 外部實體

XML 標準提供了一個鮮為人知的概念，稱為外部實體，它是文檔數據類型定義 (DTD) 的一部分。 它允許文檔作者指定指向外部實體的鏈接，然後可以在主文檔中引用並包含這些鏈接。 一個非常簡單的例子是：

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

在解析過程中，引用&bar; 被定義實體的內容替換，從而產生<foo>baz</foo> 。

如果應用程序接受外部輸入並將其直接包含在 XML 文檔定義中，而無需任何檢查，那麼大範圍的數據洩漏和攻擊將成為可能。

神奇的是，實體不必是簡單的字符串——它可以是對文件系統上文件的引用。 XML 解析器很樂意獲取指定文件的內容並將其包含在生成的響應中，這可能會洩露敏感的系統信息。 如 OWASP 所示，通過將實體定義為

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

此漏洞的一個特別麻煩的“功能”是可以輕鬆執行拒絕服務攻擊。 一種簡單的方法是列出/dev/random等無限文件的內容。 另一種是創建一系列實體，每個實體多次引用前一個實體。 這會將最終引用變成一個可能非常寬且深的樹的根，其解析可能會耗盡系統內存。 這種攻擊甚至被稱為十億笑。 如 Wikipedia 所示，定義了一系列虛擬實體，為攻擊者提供了在最終文檔中包含十億個 lol 的機會。

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

可以通過使用不太複雜的數據格式來防止 XML 外部實體攻擊。 JSON 是一個很好的替代品，前提是由於可能會受到攻擊而採取了一些預防措施。 必須更新 XML 庫，同時禁用外部實體處理和 DTD。 與往常一樣，在使用來自不受信任來源的數據或將其包含在文檔中之前，請對其進行驗證和清理。

不安全的反序列化

在編寫代碼時，開發人員有權使用他們編寫的代碼來控制他們正在開發的系統。 控制只寫很少甚至不寫代碼的第三方系統的行為會有多棒？ 由於人並不完美，圖書館也有缺陷，這絕對是可能的。

應用程序狀態和配置通常被序列化和存儲。 如果序列化數據與當前用戶緊密耦合，有時瀏覽器會充當存儲引擎。 一個試圖聰明並節省處理時間的應用程序可以使用 cookie 來標記用戶已登錄。由於 cookie 只能在登錄成功後創建，因此將用戶名存儲在 cookie 中是有意義的。 然後根據 cookie 的存在和內容對用戶進行身份驗證和授權。 如果人們沒有惡意，就不會出錯。 老實說，他們也不應該好奇。

如果好奇的用戶在他們的機器上發現了一個 cookie，他們可能會看到如下內容：

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

一個完全有效的 Python 字典，序列化為 JSON，沒什麼特別的。 好奇的用戶可能會更改到期日期以防止應用程序強制註銷。 更加好奇的用戶可能會嘗試將用戶名修改為"jane.doe" 。 如果這個用戶名存在，它將為現在可以訪問私人數據的毫無戒心的用戶打開一個全新的世界。

將數據序列化為 JSON 並保持一切透明的簡單示例遠非發生在您身上的最糟糕的事情。 如果攻擊者成功修改了一些序列化數據，他們可能會以強制系統執行任意代碼的方式對其進行修改。

假設您正在構建一個 REST API，它允許人們用 Python 編寫自己的機器學習模型並將它們上傳到您的服務。 該服務將評估上傳的模型並使用您的數據集對其進行訓練。 這使人們可以使用您的計算資源和大量可用的數據集來快速輕鬆地構建模型。

該服務不會以純文本格式存儲代碼。 用戶醃製他們的代碼，使用他們的私鑰對其進行加密，然後將其發送到 API 進行訓練。 當服務需要運行模型時，它會解密代碼、解壓縮並運行它。 棘手的部分是 pickle 協議是不安全的。 可以以允許在反序列化期間執行任意惡意代碼的方式構造代碼。

Python 的 pickle 協議允許類定義方法__reduce__ ，該方法返回有關如何反序列化自定義對象的信息。 支持的返回值之一是兩個參數的元組：一個可調用的和一個要傳遞給可調用的參數的元組。 考慮到您的 ML 模型訓練系統旨在提供代碼結構的最大靈活性，可以編寫以下代碼：

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

一旦對象需要被反序列化（unpickled），一個函數list就會被調用，只有一個參數。 函數list是 Python 中的列表構造函數，函數itertools.count生成一個無限的值迭代器，從傳遞的參數開始。 將無限迭代器轉換為有限列表可能會對系統的性能和穩定性造成災難性後果。

解決此類漏洞的唯一真正方法是選擇不反序列化來自外部來源的數據。 如果無法做到這一點，建議使用校驗和或數字簽名來防止對可能被惡意用戶修改的數據進行反序列化。 此外，嘗試設置與主系統分離的沙盒環境，以限制可能出現的問題的影響。

當使用外部庫對數據進行反序列化時，例如來自 XML 或 JSON，請嘗試選擇那些允許您在執行實際反序列化過程之前進行對像類型檢查的庫。 這可能會捕獲意外的對像類型，其唯一目的是損害您的系統。

與您的應用程序執行的所有其他操作一樣，強制執行廣泛的日誌記錄和監控。 反序列化經常發生或比正常失敗更多是壞事正在發生的信號。 儘早發現問題。

記錄和監控不足

您花了多少時間來確保記錄應用程序中發生的所有警告和錯誤？ 您是只存儲代碼中發生的錯誤，還是記錄驗證錯誤？ 當您的域的業務規則未得到滿足時會發生什麼？ 未能在您的應用程序中保留所有錯誤和可疑活動會導致安全性和數據洩露。

想像以下場景。 與大多數應用程序一樣，您的應用程序包含一個登錄頁面。 該表單有兩個字段，一個用於輸入電子郵件，另一個用於輸入密碼。 如果用戶嘗試登錄並且他們提供了錯誤的密碼，他們可以重試。 不幸的是，錯誤嘗試的次數不受限制，因此在嘗試 N 次失敗後，登錄頁面不會被鎖定。 攻擊者可以利用這個機會，在給定一封正確的電子郵件的情況下，繼續從彩虹表輸入密碼，直到一個組合最終成功。 如果您的應用程序足夠安全，並且您在將密碼輸入數據庫之前對密碼進行了哈希處理，那麼這種特殊的攻擊將不起作用。 但是，您有識別入侵的機制嗎？

僅僅因為這一次嘗試未能打開您的登錄頁面，並不意味著其他人不會。 登錄頁面也可能不是您擁有的唯一潛在後門。 如果不是出於其他原因，有人可能會嘗試對您使用損壞的訪問控制。 即使是精心設計的應用程序也應該知道有人試圖攻擊它們，即使這可能是不可能的。 不過，它總是這樣。

為了盡最大努力保護自己免受此類攻擊，請執行以下步驟：

  • 記錄應用程序中發生的所有故障和警告，無論是代碼中引發的異常還是訪問控制、驗證和數據操作錯誤。 存儲的所有信息都必須被複製並保留足夠長的時間，以便可以進行回顧性檢查和分析。
  • 確定格式和持久層很重要。 擁有任意文本格式的大文件很容易實現； 稍後處理它不是。 選擇一種便於存儲和讀取數據的存儲選項，以及一種便於快速（反）序列化的格式。 將 JSON 存儲在數據庫中可以實現快速訪問，從而簡化使用。 通過定期備份來保持數據庫較小。
  • 如果您正在處理重要且有價值的數據，請跟踪可用於審計最終狀態的操作。 實施防止數據篡改的機制。
  • 讓後台系統分析日誌並在出現問題時提醒您。 檢查——就像測試用戶是否反复嘗試訪問應用程序的受保護部分一樣簡單——幫助。 但是，不要用虛擬檢查使系統過載。 監控系統必須作為單獨的服務運行，並且不得影響主系統的性能。

解決問題時，請特別注意不要將錯誤日誌洩露給外部用戶。 不這樣做會使您容易受到敏感信息的洩露。 日誌記錄和監控應該幫助您解決問題，而不是攻擊者更有效地完成工作。

日誌記錄和監控示意圖

下一步

了解 Web 應用程序中的潛在威脅和漏洞非常重要。 更重要的是開始在您的應用程序中識別它們並應用補丁來刪除它們。

注意應用程序安全是軟件開發項目所有步驟的重要組成部分。 軟件架構師、開發人員和測試人員都必須將軟件測試程序整合到他們的工作流程中。 在軟件開發過程的適當步驟中使用安全檢查表和自動化測試以降低安全風險是有益的。

無論您是分析現有應用程序還是開發新的應用程序，您都應該研究 OWASP 應用程序安全驗證標準項目 (ASVS)。 該項目的目標是開發應用程序安全驗證的標準。 該標準列舉了開發安全 Web 應用程序的測試和要求。 這些測試被分配了從一到三的級別，其中一級表示危險最小，三表示潛在威脅最高。 該分類允許應用程序管理員決定哪些威脅更可能和更重要。 不必在每個應用程序中包含每個測試。

新的和現有的 Web 應用程序項目，尤其是那些遵循敏捷原則的項目，都受益於為保護其應用程序而進行的結構化計劃。 如果您決定使用 OWASP 安全知識框架，則 OWASP ASVS 測試的規劃會更容易。 它是一個用於管理面向安全測試的衝刺的應用程序，附帶一組關於如何解決常見安全問題的示例，以及基於 OWASP ASVS 的易於遵循的清單。

如果您剛剛開始探索 Web 應用程序的安全性並需要一個安全的沙盒遊樂場，請使用來自 OWASP 的 Web 應用程序實現——WebGoat。 這是一個故意不安全的 Web 應用程序實現。 該應用程序將指導您完成課程，每節課程都集中在一個安全威脅上。

在應用程序開發期間，請確保您：

  • 識別威脅並確定優先級。 定義哪些威脅可能實際發生並對您的應用程序構成風險。 確定威脅的優先級並確定哪些威脅值得進行最多的開發和測試工作。 如果您正在為靜態博客提供服務，那麼投入大量精力來解決日誌記錄和監控不足的問題並沒有多大意義。
  • 評估應用程序的架構和設計。 在應用程序開發的後期階段，一些漏洞很難解決。 例如，如果您打算執行第三方代碼，並且沒有使用沙盒環境的計劃，那麼將很難防禦不安全的反序列化和注入攻擊。
  • 更新軟件開發流程。 針對 Web 應用程序威脅的測試必須盡可能地成為一個自動化過程。 通過嘗試發現安全漏洞的自動化測試來增強您的 CI/CD 工作流程是有益的。 您甚至可以利用現有的單元測試系統來開發安全測試並定期運行它們。
  • 學習和改進。 問題和漏洞列表不是靜態的，絕對不限於十個或十五個威脅。 新的功能和想法為新型攻擊打開了大門。 了解 Web 應用程序安全領域的當前趨勢以保持最新狀態非常重要。 應用所學； 否則，你就是在浪費時間。

結論

儘管如其名稱所示，OWASP 十大項目僅列出了十個安全漏洞，但仍有數以千計的陷阱和後門威脅您的應用程序，最重要的是威脅您的用戶及其數據。 確保保持警惕並不斷更新您的知識，因為技術的變化和改進既有好處也有壞處。

哦，還有，別忘了，世界不是非黑即白的。 安全漏洞不會單獨出現。 它們經常交織在一起。 接觸到一個通常意味著一堆其他人在拐角處，等著抬起他們醜陋的頭，有時，即使這不是你的錯，作為系統安全開發人員，你仍然需要修補漏洞來遏制網絡犯罪。 例如，請參閱被黑的信用卡號碼仍然可以在 Google 中使用。