原理: 在開發web應用程序時，開發人員每每只關注Web應用程序所需的功能，因此經常會創建自定義的認證和會話方案。可是要正確的實現這些方案倒本章目的

普及OWASP TOP 10包含的內容、每種Web應用所面臨的安全風險及其所應采取的安全策略

OWASP Top 10簡介

OWASP（Open Web Application Security Project，開放式Web應用程序安全項目）是一個在線社區，開源的、非盈利的全球性安全組織，主要在Web應用安全領域提供文章、方法論、文檔、工具和技術，致力于應用軟件的安全研究。OWASP的使命是使應用軟件更加安全，使企業和組織能夠對應用安全風險做出更清晰的決策。目前OWASP全球擁有250個分部，近7萬名會員，共同推動了安全標準、安全測試工具、安全指導手冊等應用安全技術的發展。OWASPTop10列出了公認的最有威協性的Web應用安全漏洞，總結并更新Web應用程序中最可能、最常見、最危險的十大漏洞。

1.sql注入?????????????????????????????

原理： SQL 注入就是指 web 應用程序對用戶輸入的數據合法性沒有過濾或者是判斷，前端傳入的參數是攻擊者能夠控制，而且參數帶入數據庫的查詢，將不受信任的數據作為命令或查詢的一部分發送到解析器時，會產生諸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻擊者的惡意數據可以誘使解析器在沒有適當授權的情況下執行非預期命令或訪問數據，經過構造惡意的 sql 語句來實現對數據庫的任意操作。注入--脆弱點 應用程序存在如下情況時，是脆弱的且易受攻擊：用戶提供的數據沒有經過應用程序的驗證、過濾或凈化 動態查詢語句或非參數化的調用，在沒有上下文感知轉義的情況下，被用于解釋器。在ORM搜索參數中使用了惡意數據，這樣搜索就獲得包含敏感或未授權的數據惡意數據直接被使用或連接，諸如SQL語句或命令在動態查詢語句、命令或存儲過程中包含結構和惡意數據 ? 比如： 一、報錯注入 二、基于布爾的盲注 三、延時注入 四、寬字節注入 ? 注入--防護策略 防止注入漏洞需要將數據與命令語句、查詢語句分隔開來。 最佳選擇是使用安全的API，完全避免使用解釋器，或提供參數化界面的接口，或遷移到ORM或實體框架。 使用正確的或“白名單”的具有恰當規范化的輸入驗證方法同樣會有助于防止注入攻擊，但這不是一個完整的防御，因為許多應用程序在輸入中需要特殊字符，例如文本區域或移動應用程序的API。 對于任何剩余的動態查詢，可以使用該解釋器的特定轉義語法轉義特殊字符。OWASP的JavaEncoder和類似的庫提供了這樣的轉義例程。 在查詢中使用LIMIT和其他SQL控件，以防止在SQL注入時大量地泄露記錄

2.失效的身份認證和會話管理

原理: 在開發web應用程序時，開發人員每每只關注Web應用程序所需的功能，因此經常會創建自定義的認證和會話方案。可是要正確的實現這些方案倒是很難的。結果就在退出、密碼管理、超時、密碼找回、賬戶更新等方面存在漏洞。通過錯誤使用應用程序的身份認證和會話管理功能，攻擊者能夠破譯密碼、密鑰或會話令牌，或者利用其它開發缺陷來暫時性或永久性冒充其他用戶的身份。?失效的身份認證--脆弱點 應用程序存在如下情況時，那么可能存在身份驗證的脆弱性： 允許憑證填充，這使得攻擊者獲得有效用戶名和密碼的列表 允許暴力破解或其他自動攻擊 允許默認的、弱的或眾所周知的密碼，例如“Password1”或“admin/admin 使用弱的或失效的驗證憑證，忘記密碼程序，例如“基于知識的答案 使用明文、加密或弱散列密碼（參見：敏感數據泄露） 缺少或失效的多因素身份驗證 暴露URL中的會話ID（例如URL重寫） 在成功登錄后不會更新會話ID。 不正確地使會話ID失效。當用戶不活躍的時候，用戶會話或認證令牌（特別是單點登錄（SSO）令牌）沒有正確注銷或失效失效的身份認證--防護策略 在可能的情況下，實現多因素身份驗證，以防止自動、憑證填充、暴力破解和被盜憑據再利用攻擊不要使用發送或部署默認的憑證，特別是管理員用戶執行弱密碼檢查，例如測試新或變更的密碼，以糾正“排名前10000個弱密碼將密碼長度、復雜性和循環策略與NIST-800-63B的指導方針（記住秘密）或其他現代的基于證據的密碼策略相一致確認注冊、憑據恢復和API路徑，通過對所有輸出結果使用相同的消息，用以抵御賬戶枚舉攻擊限制或逐漸延退失敗的登錄嘗試。記錄所有失敗信息并在憑據填充、暴力破解或其他攻擊被檢測時提醒管理員。使用服務器端安全的內置會話管理器，在登錄后生成高度復雜的新隨機會話ID。會話ID不能在URL中，可以安全地存儲和當登出、閑置、絕對超時后使其失效

3.跨站腳本攻擊 XSS

XSS是跨站腳本攻擊，原理是攻擊者向有XSS漏洞的網站中輸入惡意的HTML代碼。當應用程序的新網頁中包含不受信任的、未經怡當驗證或轉義的數據時，或者使用可以創建HTML或JavaScript的瀏覽器API更新現有的網頁時，就會出現XSS缺陷。XSS讓攻擊者能夠在受害者的瀏覽器中執行腳本，并動持用戶會話、破壞網站或將用戶重定向到惡意站點。當其它用戶瀏覽該網站時，這段HTML代碼會自動執行，從而達到攻擊的目的。跨站腳本（XSS）--脆弱性 典型的XSS攻擊可導致盜取session、賬戶、繞過MFA、DIV替換、對用戶瀏覽器的攻擊（例如：惡意軟件下載、鍵盤記錄）以及其他用戶側的攻擊。 存在三種XSS類型，通常針對用戶的瀏覽器：反射式XSS：應用程序或API包括未經驗證和未經轉義的用戶輸入，作為HTML輸出的一部分。一個成功的攻擊可以讓攻擊者在受害者的瀏覽器中執行任意的HTML和JavaScript。通常，用戶將需要與指向攻擊者控制頁面的某些惡意鏈接進行交互，例如惡意漏洞網站，廣告或類似內容。 存儲式XSS：你的應用或者API將未凈化的用戶輸入存儲下來了，并在后期在其他用戶或者管理員的頁面展示出來。存儲型XSS一般被認為是高危或嚴重的風險。 基于DOM的XSS：會動態的將攻擊者可控的內容加入頁面的Javascript框架、單頁面程序或API存在這種類型的漏洞。理想的來說，你應該避免將攻擊者可控的數據發送給不安全的JavaScriptAPI。 什么是 HttpOnly? 若是您在 cookie 中設置了 HttpOnly 屬性，那么經過 js 腳本將沒法讀取到cookie 信息，這樣能有效的防止 XSS 攻擊。 ? 跨站腳本（XSS）--防護策略 防止XSS需要將不可信數據與動態的瀏覽器內容區分開。使用設計上就會自動編碼來解決XSS問題的框架，如：Ruby3.0或ReactJs。為了避免反射式或存儲式的XSS漏洞，要根據HTML輸出的上下文（包括：主體、屬性、Javascript、csS或URL）對所有不可信的HTTP請求數據進行恰當的轉義。在客戶端修改瀏覽器文檔時，為了避免DOMXSS攻擊，最好的選擇是實施上下文敏感數據編碼。如果這種情況不能避免，可以采用類似上下文敏感的轉義技術應用于瀏覽器API。使用內容安全策略（CSP）是對抗XSS的深度防御策略。如果不存在可以通過本地文件放置惡意代碼的其他漏洞（例如：路徑遍歷覆蓋和允許在網絡中傳輸的易受攻擊的庫），則該策略是有效的。

4.直接引用不安全的對象

定義： 不安全的直接對象引用（IDOR）容許攻擊者繞過網站的身份驗證機制，并經過修改指向對象連接中的參數值來直接訪問目標對象資源，這類資源能夠是屬于其余用戶的數據庫條目以及服務器系統中的隱私文件等等。 ? 出現的緣由： Web應用每每在生成Web頁面時會用它的真實名字，且并不會對全部的目標對象訪問時來檢查用戶權限，因此這就形成了不安全的對象直接引用的漏洞。 服務器上的具體文件名、路徑或數據庫關鍵字等內部資源被暴露在URL或網頁中，攻擊者能夠嘗試直接訪問其余資源。 ? 防護措施： 1.使用基于用戶或會話的間接對象訪問，這樣可防止攻擊者直接攻擊未受權資源 2.訪問檢查：對任何來自不受信源所使用的全部對象進行訪問控制檢查 3.避免在url或網頁中直接引用內部文件名或數據庫關鍵字 4.驗證用戶輸入和url請求，拒絕包含./ …/的請求

5.安全配置錯誤

定義： 安全配置錯誤是最常見的安全問題，這通常是由于不安全的默認配置、不完整的臨時配置、開源云存儲、錯誤的HTTP標頭配置以及包含敏感信息的詳細錯誤信息所造成的。因此，我們不僅需要對所有的操作系統、框架、庫和應用程序進行安全配置，而且必須及時修補和升級它們。安全配置錯誤--脆弱性 應用程序存在以下情況，可能受到攻擊：應用程序棧堆的任何部分都缺少適當的安全加固，或者云服務的權限配置錯誤。 應用程序啟用或安裝了不必要的功能（例如：不必要的端口、服務、網頁、帳戶或權限）。默認帳戶的密碼仍然可用且沒有更改。 錯誤處理機制向用戶披露堆棧跟蹤或其他大量錯誤信息。 對于更新的系統，禁用或不安全地配置最新的安全功能。 應用程序服務器、應用程序框架（Struts、Spring、ASP.NET）、庫文件、數據庫等沒有進行安全配置。 服務器不發送安全標頭或指令，或者未對服務器進行安全配置。 您的應用軟件已過期或易受攻擊（參見：使用含有已知漏洞的組件）。? 安全配置錯誤--防護策略 一個可以快速且易于部署在另一個鎖定環境的可重復的加固過程。 開發、質量保證和生產環境都應該進行相同配置，并且在每個環境中使用不同的密碼。 這個過程應該是自動化的，以盡量減少安裝一個新安全環境的耗費。搭建最小化平臺，該平臺不包含任何不必要的功能、組件、文檔和示例。移除不適用的功能和框架。 檢查和修復安全配置項來適應最新的安全說明、更新和補丁，并將其作為更新管理過程的一部分，（參見：使用含有已知漏洞的組件）。 在檢查過程中，應特別注意云存儲權限。 一個能在組件和用戶間提供有效的分離和安全性的分段應用程序架構，包括分段、容器化和云安全組。 向客戶端發送安全指令，如：安全標頭。 在所有環境中能夠進行正確安全配置和設置的自動化過程。

6.敏感信息泄露

漏洞描述： 因為管理員或者技術人員等各類緣由致使敏感信息泄露。許多web應用程序和app都沒法正確保護敏感數據，攻擊者能夠經過竊取或修改未加密的數據來實施犯罪行為。未加密的敏感數據容易受到破壞，所以，必須要對敏感數據加密，這些數據包括：傳輸過程當中的數據、存儲的數據以及瀏覽器的交互數據。 ? 敏感數據泄露--脆弱性 對于敏感數據，要確定：在數據傳輸過程中是否使用明文傳輸？這和傳輸協議相關，如：HTTP、SMTP和FTP。外部網絡流量非常危險。驗證所有的內部通信，如：負載平衡器、Web服務器或后端系統之間的通信。 當數據被長期存儲時，無論存儲在哪里，它們是否都被加密，包含備份數據？ 無論默認條件還是源代碼中，是否還在使用任何舊的或脆弱的加密算法？ 是否使用默認加密密鑰，生成或重復使用脆弱的加密密鑰，或者缺少恰當的密鑰管理或密鑰回轉？ 是否強制加密敏感數據，例如：用戶代理（如：瀏覽器）指令和傳輸協議是否被加密？ 用戶代理（如：應用程序、郵件客戶端）是否未驗證服務器端證書的有效性？ 敏感數據泄露--防護策略 對系統處理、存儲或傳輸的數據分類，并根據分類進行訪問控制。熟悉與敏感數據保護相關的法律和條例，并根據每項法規要求保護敏感數據對于沒必要存放的、重要的敏感數據，應當盡快清除，或者通過PCIDSS標記或攔截確保存儲的所有敏感數據被加密。確保使用了最新的、強大的標準算法或密碼、參數、協議和密匙，并且密鑰管理到位。確保傳輸過程中的數據被加密（HTTPS）；確保數據加密被強制執行禁止緩存對包含敏感數據的響應確保使用密碼專用算法存儲密碼。將工作因素（延退因素）設置在可接受范圍。單獨驗證每個安全配置項的有效性。

7.缺乏功能級的訪問控制

原理： 大多數Web應用程序的功能在UI頁面顯示以前,會驗證功能級別的訪問權限。不足的日志記錄和監控，以及事件響應缺失或無效的集成，使攻擊者能夠進一步攻擊系統、保持持續性或轉向更多系統，以及算改、提取或銷毀數據，比如若是請求沒有被驗證,攻擊者可以偽造請求從而在未經適當受權時訪問功能。 ? 測試方法： 一、 保證合法受權用戶能夠訪問成功 二、 限制非法未受權用戶的訪問 ? 防護措施： 一、 設計嚴格的權限控制系統，對于每一個請求和URL都要進行校驗和權限確認，防止非法請求被執行 二、 對于每一個功能的訪問，都要有明確的角色受權，采用過濾器的方式校驗每一個請求的合法性 三、 實現Web訪問的IP白名單列表，禁止不可信的IP訪問Web系統

8.跨站請求偽造 CSRF

CSRF概念： CSRF跨站點請求偽造(Cross—Site Request Forgery)，跟XSS攻擊同樣，存在巨大的危害性，你能夠這樣來理解：攻擊者盜用了你的身份，以你的名義發送惡意請求，對服務器來講這個請求是徹底合法的，可是卻完成了攻擊者所指望的一個操做，攻擊者可以利用外部實體竊取使用URI文件處理器的內部文件和共享文件、監聽內部掃描端口、執行遠程代碼和實施拒絕服務攻擊。以下：其中Web A為存在CSRF漏洞的網站，Web B為攻擊者構建的惡意網站，User C為Web A網站的合法用戶。 ? CSRF攻擊攻擊原理及過程以下： 1. 用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登陸網站A； 2.在用戶信息經過驗證后，網站A產生Cookie信息并返回給瀏覽器，此時用戶登陸網站A成功，能夠正常發送請求到網站A； 3. 用戶未退出網站A以前，在同一瀏覽器中，打開一個TAB頁訪問網站B； 4. 網站B接收到用戶請求后，返回一些攻擊性代碼，并發出一個請求要求訪問第三方站點A； 5. 瀏覽器在接收到這些攻擊性代碼后，根據網站B的請求，在用戶不知情的狀況下攜帶Cookie信息，向網站A發出請求。網站A并不知道該請求實際上是由B發起的，因此會根據用戶C的Cookie信息以C的權限處理該請求，致使來自網站B的惡意代碼被執行。 ? 分類： GET型和POST型。 ? 防護手段： 一、驗證 HTTP Referer 字段。根據HTTP協議，在HTTP頭中有一個字段叫Referer，它記錄了該HTTP請求的來源地址。 二、在請求地址中添加 token 并驗證在HTTP請求中以參數的形式加入一個隨機產生的token（隨機字符串），并在服務器端創建一個攔截器來驗證這個token，若是請求中沒有token或者token內容不正確，則認為多是CSRF攻擊而拒絕該請求。 三、二次驗證在轉帳等關鍵操做以前提供當前用戶的密碼或者驗證碼。二次驗證能夠有效防護CSRF 攻擊。

9.使用含有已知漏洞的組件

原理： 使用含有已知漏洞的組件（例如：庫、框架和其他軟件模塊）擁有和應用程序相同的權限。如果應用程序中含有已知漏洞的組件被攻擊者利用，可能會造成嚴重的數據丟失或服務器接管。同時，使用含有已知漏洞的組件的應用程序和API可能會破壞應用程序防御、造成各種攻擊并產生嚴重影響。 含有已知漏洞的組件--脆弱性 如果滿足下面的某個條件，那么應用程序就易受此類攻擊： 如果不知道所有使用的組件版本信息（包括：服務端和客戶端）。這包括了直接使用的組件或其依賴的組件。如果軟件易受攻擊，不再支持或者過時。這包括：OS、Web服務器、應用程序服務器、數據庫管理系統（DBMS）、應用程序、API和所有的組件、運行環境和庫。 如果你定期做漏洞掃描和訂閱你使用組件的安全公告。 如果不基于風險并及時修復或升級底層平臺、框架和依賴庫。很可能發生這種情況：根據變更控制，每月或每季度進行升級，這使得組織在這段時間內會受到已修復但未修補的漏洞的威脅。 如果軟件工程師沒有對更新的、升級的或打過補丁的組件進行兼容性測試 如果你沒有對組件進行安全配置。 使用含有已知漏洞的組件-防護策略應該制定一個補丁管理流程： 移除不使用的依賴、不需要的功能、組件、文件和文檔。利用如versions、DependencyCheck、retirejs等工具來持續的記錄客戶端和服務器端以及它們的依賴庫的版本信息。 持續監控如CVE和NVD等是否發布已使用組件的漏洞信息。 訂閱關于使用組件安全漏洞的警告郵件。 僅從官方渠道安全的獲取組件，使用簽名機制降低組件被算改或惡意漏洞的風險。 監控那些不再維護或者不發布安全補丁的庫和組件。 如果不能打補丁，可以考慮部署虛擬補丁來監控、檢測或保護。 每個組織都應該制定相應的計劃，對整個軟件生命周期進行監控、評審、升級或更改配置。

10.未驗證的重定向和轉發

重定向： 重定向是服務端根據邏輯，發送一個狀態碼（一般為3xx），告訴瀏覽器從新去請求那個地址.因此地址欄顯示的是新的URL。（重定向是在客戶端完成的） 轉發： 轉發是在服務器內部將請求轉發給另外一個資源，把那個URL的響應內容讀取過來,而后把這些內容再發給瀏覽器.瀏覽器根本不知道服務器發送的內容從哪里來的,由于這個跳轉過程是在服務器實現的，并非在客戶端實現的因此客戶端并不知道這個跳轉動做，因此它的地址欄仍是原來的地址。（轉發是在服務器端完成的） ? 二者的區別： 一、重定向是瀏覽器向服務器發送一個請求并收到響應后再次向一個新地址發出請求，轉發是服務器收到請求后為了完成響應跳轉到一個新的地址。 二、重定向有兩次請求，不共享數據，轉發是有一次請求且共享數據。 三、重定向后地址欄會發生變化，轉發不會。 四、重定向的地址能夠是任意地址，轉發的地址只能是當前應用類的某一個地址。 ? 預防措施： 一、重定向外部網站須要驗證是否在白名單。 二、轉發內部網站要驗證是否有權限,有權限才轉發。

總結

以上是生活随笔為你收集整理的OWASPTop10安全风险与防护的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。