大約一年前，我們 DataLine 推出了 搜尋和分析 IT 應用程式中的漏洞。 該服務基於Qualys雲端解決方案，其運作方式 。 在使用該解決方案的一年時間裡，我們對不同網站進行了 291 次掃描，並累積了 Web 應用程式中常見漏洞的統計資料。
在下面的文章中，我將向您展示不同嚴重程度背後隱藏的網站安全漏洞。 讓我們看看掃描器最常發現哪些漏洞、它們可能發生的原因以及如何保護自己。
Qualys 將所有 Web 應用程式漏洞分為三個嚴重程度等級：低、中和高。 如果按照「嚴重程度」來觀察分佈情況，似乎一切都還不錯。 很少有嚴重程度較高的漏洞，大多數都是非嚴重的：
但不批判並不意味著無害。 它們還會造成嚴重損害。
最重要的「非關鍵」漏洞
- 混合內容漏洞。
網站安全的標準是透過HTTPS協定在客戶端和伺服器之間傳輸數據，該協定支援加密並保護資訊不被攔截。
有些網站使用 混合內容：有些資料是透過不安全的HTTP協定傳輸的。 這是最常傳達的方式 被動內容 – 僅影響網站顯示的資訊：圖片、CSS 樣式。 但有時這就是它的傳播方式 活躍內容：控制網站行為的腳本。 在這種情況下，使用特殊的軟體，您可以分析來自伺服器的活動內容的訊息，動態修改您的回應，並使機器以非其創建者預期的方式運作。
較新版本的瀏覽器會警告使用者含有混合內容的網站不安全並阻止該內容。 網站開發人員也會在控制台中收到瀏覽器警告。 例如，這就是它的樣子 :
為什麼它很危險？：攻擊者使用不安全的協議來攔截使用者資訊、替換腳本並向網站發送請求。 即使網站訪客沒有輸入數據，這也不能保護他免受 網路釣魚 – 使用詐欺方法取得機密資訊。 例如，使用腳本，您可以將使用者重新導向到偽裝成使用者熟悉的網站的不安全網站。 在某些情況下，惡意網站看起來甚至比原始網站更好，使用者可以自己填寫表格並提交機密資料。Web 開發人員應該記住什麼：即使網站管理員安裝並配置了 SSL/TLS 證書，也可能因人為錯誤而出現漏洞。 例如，如果您在其中一個頁面上放置的不是相對鏈接，而是來自 http 的絕對鏈接，而且您沒有設定從 http 到 https 的重定向。
您可以使用瀏覽器偵測網站上的混合內容：搜尋頁面的原始程式碼，閱讀開發人員控制台中的通知。 然而，開發人員將不得不長時間且乏味地修改程式碼。 您可以使用自動分析工具加快流程，例如： 、免費 Lighthouse 軟體或付費軟體 Screaming Frog SEO Spider。
此外，該漏洞可能是由於遺留程式碼（繼承的程式碼）的問題而出現的。 例如，如果某些頁面是使用舊範本產生的，則沒有考慮網站向 https 的轉換。
- 沒有「HTTPOnly」和「secure」標誌的 Cookie。
「HTTPOnly」屬性可防止 cookie 被攻擊者用來竊取使用者資料的腳本處理。 「安全性」標誌不允許以明文形式發送 cookie。 僅當使用安全 HTTPS 協定發送 cookie 時才允許通訊。
這兩個屬性都在 cookie 屬性中指定：
Set-Cookie: Secure; HttpOnly為什麼它很危險？：如果網站開發者沒有指定這些屬性，攻擊者就可以從 cookie 攔截使用者資訊並利用它。 如果cookie用於身份驗證和授權，他將能夠劫持使用者的會話並代表他在網站上執行操作。
Web 開發人員應該記住什麼：通常，在流行的框架中，這些屬性是自動設定的。 但仍檢查 Web 伺服器配置並設定標誌：Set-Cookie HttpOnly； 安全的。
在這種情況下，「HTTPOnly」屬性將使 cookie 對您自己的 JavaScript 不可見。
- 基於路徑的漏洞。
如果掃描器發現包含潛在機密資訊的可公開存取的文件或網站目錄，則會報告此類漏洞。 例如，它會偵測單一系統設定檔或對整個檔案系統的存取。 如果網站上的存取權限設定不正確，則可能發生這種情況。
為什麼它很危險？：如果檔案系統“突出”，攻擊者就可以進入作業系統介面並嘗試尋找帶有密碼的資料夾（如果它們以明文形式儲存）（不要這樣做！）。 或者，您可以竊取密碼雜湊值並暴力破解密碼，還可以嘗試提升系統權限並更深入了解基礎架構。
Web 開發人員應該記住什麼：不要忘記存取權並配置平台、Web 伺服器、Web 應用程序，這樣就不可能「逃脫」Web 目錄。
- 用於輸入敏感資料並啟用自動填入的表單。
如果使用者經常在網站上填寫表單，他們的瀏覽器會使用自動填充功能來儲存此資訊。
網站上的表單可能包含包含敏感資訊的字段，例如密碼或信用卡號。 對於此類字段，值得禁用網站本身的表單自動填充功能。
為什麼它很危險？：如果使用者的瀏覽器儲存敏感訊息，攻擊者可以稍後攔截它，例如透過網路釣魚。 從本質上講，一個忘記了這種細微差別的網頁開發人員正在設定他的用戶。
Web 開發人員應該記住什麼：在這種情況下，我們遇到了一個經典的衝突：便利性與安全性。 如果Web開發人員考慮使用者體驗，他可以有意識地選擇自動完成。 例如，如果遵循很重要 – 針對殘障使用者無障礙內容的建議。
對於大多數瀏覽器，您可以使用 autocompete="off" 屬性停用自動完成，例如：
<body> <form action="/zh-TW/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>但它不適用於 Chrome。 這是使用 JavaScript 來規避的，可以找到配方的變體 .
- 站點代碼中未設定 X-Frame-Options 標頭。
此標頭影響框架、iframe、嵌入或物件標記。 在它的幫助下，您可以完全禁止將您的網站嵌入框架內。 為此，您需要指定值 X-Frame-Options：deny。 或者您可以指定 X-Frame-Options: sameorigin，然後嵌入 iframe 將僅在您的網域上可用。
為什麼它很危險？：缺乏這樣的標頭可被惡意網站用來 點擊劫持。 對於此攻擊，攻擊者在按鈕頂部創建一個透明框架並欺騙用戶。 例如：詐騙者在網站上建立社交網路頁面。 用戶認為他正在點擊該網站上的按鈕。 相反，點擊會被攔截，使用者的請求會被傳送到存在活動會話的社群網路。 這就是攻擊者代表用戶發送垃圾郵件或獲得訂閱者和點讚的方式。
如果您不停用此功能，攻擊者可以將您的應用程式按鈕放置在惡意網站上。 他可能對您的推薦計劃或您的用戶感興趣。
Web 開發人員應該記住什麼：如果在 Web 伺服器或負載平衡器上設定了具有衝突值的 X-Frame-Options，則可能會出現該漏洞。 在這種情況下，伺服器和平衡器將簡單地重寫標頭，因為與後端程式碼相比，它們具有更高的優先權。
X-Frame-Options標頭的deny和sameorigin值會幹擾Yandex Web檢視器的操作。 若要允許 Web 檢視器使用 iframe，您需要在設定中編寫單獨的規則。 例如，對於 nginx，您可以這樣設定：
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI（路徑相對樣式表導入）漏洞。
這是網站樣式中的漏洞。 如果使用像 href="/zh-TW/somefolder/styles.css/" 這樣的相對連結來存取樣式文件，就會發生這種情況。 如果攻擊者找到一種將使用者重新導向到惡意頁面的方法，他們就會利用這一點。 該頁面將在其 url 中插入一個相對連結並模擬樣式呼叫。 您將收到類似 badsite.ru/.../somefolder/styles.css/ 的請求，該請求可以以樣式為幌子執行惡意操作。
為什麼它很危險？：如果詐欺者發現另一個安全漏洞，他們就可以利用此漏洞。 因此，可以從 cookie 或令牌竊取使用者資料。
Web 開發人員應該記住什麼：將 X-Content-Type-Options 標頭設定為：nosniff。 在這種情況下，瀏覽器將檢查樣式的內容類型。 如果類型不是text/css，瀏覽器將阻止該請求。
嚴重漏洞
- 帶有密碼欄位的頁面透過不安全的通道從伺服器傳輸（包含密碼欄位的 HTML 表單透過 HTTP 提供）。
伺服器通過未加密通道的回應容易受到“中間人”攻擊。 當頁面從伺服器傳輸到客戶端時，攻擊者可以攔截流量並將其本身插入客戶端和伺服器之間。
為什麼它很危險？：詐騙者將能夠替換頁面並向使用者發送機密資料表單，該表單將發送到攻擊者的伺服器。
Web 開發人員應該記住什麼：某些網站透過電子郵件/電話向使用者發送一次性代碼而不是密碼。 在這種情況下，該漏洞並不是那麼嚴重，但該機制將使用戶的生活變得複雜。
- 透過不安全的通道傳送包含登入名稱和密碼的表單（未透過 HTTPS 提交登入表單）。
在這種情況下，帶有登入名稱和密碼的表單會透過未加密的通道從使用者傳送到伺服器。
為什麼它很危險？：與之前的情況不同，這已經是一個嚴重漏洞。 攔截敏感資料更容易，因為您甚至不需要編寫程式碼來執行此操作。
- 使用具有已知漏洞的 JavaScript 程式庫。
在掃描過程中，最常用的函式庫是 jQuery，其版本數量非常多。 每個版本都至少有一個甚至更多已知漏洞。 根據漏洞的性質，影響可能會大不相同。
為什麼它很危險？：存在針對已知漏洞的利用，例如：
Web 開發人員應該記住什麼：定期返回循環：搜尋已知漏洞-修復-檢查。 如果您故意使用舊庫，例如為了支援較舊的瀏覽器或為了省錢，請尋找修復已知漏洞的機會。 - 跨站腳本（XSS）。
跨站點腳本 (XSS) 或跨站點腳本是對 Web 應用程式的攻擊，會導致惡意軟體引入資料庫。 如果Qualys發現這樣的漏洞，則表示潛在的攻擊者可以或已經將自己的js腳本引入到網站程式碼中來執行惡意操作。儲存型 XSS 更危險的是，因為該腳本嵌入在伺服器上，並且每次在瀏覽器中開啟受攻擊的頁面時都會執行該腳本。
反射式 XSS 由於可以將惡意腳本注入到 HTTP 請求中，因此更容易執行。 應用程式將收到 HTTP 請求，不會驗證數據，將其打包並立即發送。 如果攻擊者攔截流量並插入以下腳本
<script>/*+что+то+плохое+*/</script>那麼惡意請求將代表客戶端發送。
一個引人注目的 XSS 範例：js 嗅探器模擬輸入 CVC、卡片到期日期等頁面。
Web 開發人員應該記住什麼：在 Content-Security-Policy 標頭中，使用 script-src 屬性強制客戶端瀏覽器僅從受信任的來源下載和執行程式碼。 例如，script-src 'self' 僅將我們網站上的所有腳本列入白名單。
最佳實踐是內聯程式碼：僅允許內聯 javascript 使用 unsafe-inline 值。 該值允許使用內聯js/css，但不禁止包含js檔案。 與 script-src 'self' 結合使用，我們可以停用外部腳本的執行。請務必使用 report-uri 記錄所有內容，並查看將其實施到網站中的嘗試。
- SQL注入。
該漏洞表明可能將 SQL 程式碼注入到直接存取網站資料庫的網站中。 如果不篩選來自使用者的數據，則可能發生 SQL 注入：不檢查其正確性並立即在查詢中使用。 例如，如果網站上的表單不檢查輸入是否與資料類型匹配，就會發生這種情況。為什麼它很危險？：如果攻擊者在此表單中輸入 SQL 查詢，他可能會導致資料庫崩潰或洩漏機密資訊。
Web 開發人員應該記住什麼：不要相信來自瀏覽器的內容。 您需要在客戶端和伺服器端保護自己。
在客戶端，使用 JavaScript 編寫欄位驗證。
流行框架中的內建函數也有助於逃避伺服器上的可疑字元。 也建議在伺服器上使用參數化資料庫查詢。
確定與資料庫的互動到底發生在 Web 應用程式上的何處。
當我們收到任何資訊時就會發生互動：帶有 id 的請求（id 的變更）、新使用者的建立、新評論或資料庫中的新條目。 這就是 SQL 注入可能發生的地方。 即使我們從資料庫中刪除一筆記錄，SQL注入也是可能的。
一般建議
不要重新發明輪子—使用經過驗證的框架。 一般來說，流行的框架更安全。 對於 .NET - ASP.NET MVC 和 ASP.NET Core，對於 Python - Django 或 Flask，對於 Ruby - Ruby on Rails，對於 PHP - Symfony、Laravel、Yii，對於 JavaScript - Node.JS-Express.js，對於 Java - 春季MVC。
關注供應商更新並定期更新。 他們會發現一個漏洞，然後編寫一個漏洞利用程序，將其公開，然後一切都會再次發生。 訂閱軟體供應商的穩定版本更新。
檢查存取權限。 在伺服器端，始終將您的程式碼從第一個字母到最後一個字母視為由您最討厭的敵人編寫的，他們想要破壞您的網站，破壞您資料的完整性。 而且，有時確實如此。
使用克隆、測試站點，然後將它們用於生產。 首先，這將有助於避免生產環境中的錯誤和錯誤：生產環境帶來金錢，簡單的生產環境至關重要。 在添加、修復或解決任何問題時，值得在測試環境中工作，然後檢查發現的功能和漏洞，然後計劃在生產環境中工作。
保護您的 Web 應用程式 並將漏洞掃描器的報告與其集成。 例如，DataLine 使用 Qualys 和 FortiWeb 作為服務包。
來源： www.habr.com