讀軟體開發安全之道：概念、設計與實施13Web安全

躺柒發表於2024-08-30
Web

1. Web安全

1.1. 當蜘蛛網中出現文字時，所有人都說這是個奇蹟。但是沒有人指出蜘蛛網本身就是一個奇蹟

  • 1.1.1. E.B.懷特

1.2. 全球資訊網的巨大成功在很大程度上歸因於一個明顯的事實​：無數人對它的原理一無所知，但經常使用它

  • 1.2.1. 網路的易用性促使它的使用者持續增長

  • 1.2.2. 如此複雜的技術融合在一起所取得的這個非凡成就既是福也是禍

1.3. Web是歷史上最極端的亡羊補牢的例子

  • 1.3.1. 早期的Web設計非常幼稚，沒有過多考慮安全性

  • 1.3.1.1. 如果早期創新者在過去試圖設計一個完全安全的系統，那麼這項任務將會非常艱鉅，如果他們失敗了，所有努力可能永遠不會得到任何成果

  • 1.3.2. 現代Web是一個標準長期演變的產物，同時被競爭激烈的“瀏覽器大戰”和向後相容性所困擾

  • 1.3.3. 儘管現代Web可以變得安全，但它錯綜複雜的歷史意味著它也非常脆弱

1.4. 微小的失誤很容易造成漏洞

  • 1.4.1. 漏洞源於細節，一個安全的網站必須做對很多事情

1.5. 在安全框架上的構建要求，這個安全框架會為你處理錯綜複雜的事務

2. 建立在框架之上

2.1. 藉助現代的Web開發工具，構建網站幾乎與使用網站一樣簡單

2.2. 依賴高質量的框架，永遠不要忽視框架所提供的保護措施，讓有能力的專家來處理所有混亂的細節

  • 2.2.1. 一個可靠的框架應該可以使你免受大部分漏洞的影響，但是準確理解框架會做什麼以及不做什麼也很重要，因為這樣你就可以更有效地利用框架

  • 2.2.2. 從一開始就選擇一個安全的框架也很重要，因為你的程式碼將深深依賴於它，如果它未能達到你的預期，在將來更換框架會非常痛苦

2.3. 一般準則

  • 2.3.1. 選擇使用由值得信賴的組織或團隊開發的框架，這些組織或團隊會積極地開發和維護這個框架，以跟上不斷變化的網路技術和實踐

  • 2.3.2. 在文件中查詢明確書寫的安全宣告

  • 2.3.3. 該框架不需要有完美的記錄，但響應遲緩或持續存在的問題模式都是危險訊號

  • 2.3.4. 構建一個小型原型並檢查生成的HTML是否擁有正確的轉義和引用

  • 2.3.5. 構建一個簡單的測試平臺來試驗基本的XSS和CSRF攻擊

3. Web安全模型

3.1. Web是一種客戶端/伺服器技術

  • 3.1.1. 雙方的安全利益經常存在爭議，尤其是考慮到潛在的攻擊者會透過網際網路入侵

  • 3.1.2. 只有在伺服器能夠很好地提供安全性的情況下，Web才能工作，這樣誠信的終端使用者才能有機會獲得安全的Web體驗

3.2. 客戶端瀏覽器的角色

  • 3.2.1. 即使Web伺服器嘗試對客戶使用的瀏覽器型別進行限制，使其只能使用特定的版本，但瀏覽器可以輕易實現錯誤表明自己的身份並繞過這類限制

  • 3.2.2. 只要伺服器是安全的，惡意客戶就無法對伺服器提供給其他客戶的服務造成影響

  • 3.2.3. Web伺服器過度信任那些不值得信任的客戶端瀏覽器，可能是眾多Web安全漏洞的根源

3.3. HTTP

  • 3.3.1. HTTP本身是Web的核心

  • 3.3.1.1. Web瀏覽已經成為日常生活的一部分

  • 3.3.2. Web瀏覽總是從一個URL（Uniform Resource Locator，統一資源定位符）開始的

  • 3.3.3. HTTP動作所指定的請求

  • 3.3.3.1. GET動作會從伺服器請求內容

>  3.3.3.1.1. GET請求不會改變伺服器的狀態
  • 3.3.3.2. 客戶端會使用POST動作來提交表單或上傳檔案
>  3.3.3.2.1. POST請求旨在改變伺服器的狀態

  • 3.3.3.3. 如果你嚴格地遵守標準規則，可以很容易地讓你的伺服器變得安全

  • 3.3.4. 一條與安全相關的“鐵則”是不要在URL中嵌入敏感資料，而是使用表單POST請求向伺服器傳送敏感資料，否則REFERER請求頭在暴露請求所在的網頁URL時會洩露敏感資料

  • 3.3.5. 一個容易犯的錯誤是在URL中包含使用者名稱

  • 3.3.5.1. 即使使用了不透明型別的識別符號（比如使用者名稱的雜湊值）​，也會洩露資訊，因為竊聽者能夠透過觀察，發現兩個單獨的URL指向同一個使用者

3.4. 數字證書和HTTPS

  • 3.4.1. 如果你無法獲得可靠的專家建議，你可以看看那些主流且值得信賴的網站是怎樣做的，並且遵循它們的做法

  • 3.4.2. 安全Web瀏覽的第一個挑戰是與正確的伺服器進行可靠的通訊

  • 3.4.2.1. 如果網路正確地路由並傳輸了這個請求，則請求應該到達預期的伺服器

  • 3.4.2.2. 攻擊者可能會干擾DNS查詢、路由或者路由途中任何位置的資料

>  3.4.2.2.1. HTTPS（也稱為HTTP over TLS/SSL）是專為緩解這些威脅而開發的協議
  • 3.4.2.3. 沒有人對使用HTTPS來保護網路金融交易的必要性提出過異議，但主流網站完全採用HTTPS的時間線拉得太長了
>  3.4.2.3.1. 臉書在2013年才完全採用HTTPS

  • 3.4.2.4. 很難想出什麼理由不將網站設定為僅使用HTTPS

  • 3.4.3. HTTPS提供了一個安全的防篡改端到端加密隧道，並且向客戶端保證隧道的另一端確實是預期的伺服器

  • 3.4.3.1. 將這個安全隧道視為用於確認伺服器身份的防資料篡改管道

  • 3.4.3.2. 攻擊者可能會竊聽到加密資料，但如果沒有金鑰的話，他只能看到一堆無意義的位元

  • 3.4.3.3. 攻擊者可以篡改無保護網路上的資料，但如果使用了HTTPS，任何篡改都會被發現

  • 3.4.3.4. 攻擊者可以阻止通訊的進行，比如在物理上割斷電纜，但你可以確保資料總是真實的

  • 3.4.4. HTTPS對於確保真實性和完整性也很重要

  • 3.4.4.1. HTTPS確保客戶端正在與請求URL中指定的真實伺服器進行通訊，並且它們之間傳輸的資料不會被窺探或篡改

  • 3.4.5. 隨著HTTPS和技術環境的成熟，廣泛採用HTTPS的最後一個障礙是獲得伺服器證書的開銷

  • 3.4.5.1. 儘管大公司能夠負擔受信任的CA收取的費用，並且會有工作人員負責管理和更新證書，但較小網站的所有者卻對這份額外的成本和管理工作猶豫不決

  • 3.4.5.2. 受益於電子前線基金會的大力推動和眾多行業公司的贊助，非營利組織網際網路安全研究小組的產品Let’s Encrypt為全球使用者提供了一個免費、自動化和開放的CA

>  3.4.5.2.1. 可以免費向任何網站所有者提供DV（Domain Validation，域驗證）證書

>  3.4.5.2.2. DV證書通常是你用來證明網站身份所需的全部內容

>  3.4.5.2.3. DV證書只能證明這個Web伺服器的域名已經經過了驗證

>  3.4.5.2.4. 隨著免費DV證書的激增，其他型別證書的使用前景變得模糊

  >   3.4.5.2.4.1. 使用者很少關心這種信任的區別，OV和EV證書在技術和法律上的細微差別也比較難以說清

  • 3.4.6. 在將Web伺服器設定為使用帶有證書的HTTPS後，你必須確保它始終使用HTTPS

  • 3.4.7. 利用HTTPS選項，讓通訊雙方為加密隧道協商密碼套件(cipher suite)

  • 3.4.7.1. 最好的防禦措施是確保你的HTTPS配置僅執行安全的現代加密演算法

  • 3.4.8. 為了緩解這類攻擊，我們可以始終將HTTP重定向到HTTPS，並且僅為HTTPS使用Web cookie

  • 3.4.8.1. 在HTTP響應頭中包含Strict-Transport-Security指令，以便瀏覽器知道該網站始終使用HTTPS

  • 3.4.8.2. 要想完全保障HTTPS網頁的安全性，它必須僅使用HTTPS

  • 3.4.8.3. 意味著伺服器上的所有內容（所有指令碼、影像、字型、CSS，以及其他引用資源）都應該使用HTTPS

3.5. 同源策略

  • 3.5.1. Same Origin Policy，SOP

  • 3.5.2. 瀏覽器會將來自不同網站的資源隔離開（通常透過視窗或標籤頁）​，因此這些資源不會相互影響

  • 3.5.3. 僅當資源的主機域名和埠號相同時，資源之間才可以進行互動

  • 3.5.4. 同源策略適用於指令碼和cookie（與一般的同源策略有些許不同）​，它們都有可能在獨立網站之間洩露資料

  • 3.5.5. 儘管同源策略阻止了來自其他網站頁面中指令碼的進入，但網頁始終可以隨意選擇訪問不同的網站，並將其內容拉到視窗中

3.6. Web cookie

  • 3.6.1. cookie是指伺服器要求客戶端為其儲存在本地的小的資料字串，客戶端會根據後續請求將其提供給伺服器

  • 3.6.2. 雖然任何客戶端都可以篡改自己的cookie，並將自己的會話偽裝成其他會話，但如果會話cookie設計得當的話，客戶端應該無法偽造有效的會話cookie

  • 3.6.3. 並不意味著cookie沒有用，cookie可以用來記住客戶的偏好、最喜愛的商品或其他詳細資訊，篡改這些資訊不會對商家造成傷害

  • 3.6.4. 伺服器可以設定會話cookie的過期時間，但由於伺服器不能總是依賴於客戶來主動執行這個操作，伺服器還必須對需要更新的會話cookie的有效性進行限制

  • 3.6.5. cookie會受到同源策略的約束，並對子域之間的共享做出明確規定

  • 3.6.5.1. 雖然子域可以看到其父域設定的cookie，但不能修改這些cookie

  • 3.6.6. 指令碼在名義上可以透過DOM訪問cookie，但這種便利性會為設法在網頁中執行的惡意指令碼提供機會以竊取cookie，因此最好透過執行httponly cookie屬性來阻止指令碼的訪問

  • 3.6.6.1. HTTPS網站還應該應用secure屬性，指示客戶端只透過安全隧道傳送cookie

  • 3.6.7. 向後相容性與現代安全性之間的緊張關係帶來了妥協的解決方案，這也說明了如果一開始沒有考慮安全性的話，未來安全性會變得模糊不清

  • 3.6.8. HTML5為安全模型新增了很多擴充套件

  • 3.6.8.1. 一個典型的例子是CORS（Cross-Origin Resource Sharing，跨源資源共享）​，它允許有選擇地放寬同源策略的限制，以使其他受信任的網站能夠訪問資料

  • 3.6.8.2. 瀏覽器也提供了Web儲存API，這是用於Web應用程式的一種更現代的客戶端側儲存功能，它也受限於同源策略

4. 跨站指令碼攻擊

4.1. XSS（Cross-Site Scripting，跨站指令碼）攻擊

4.2. 同源策略提供的隔離是構建安全網站的基礎，但如果我們不採取必要的預防措施，這種保護很容易遭到破壞

4.3. XSS攻擊是針對Web的注入攻擊，它的惡意輸入會改變網站的行為，通常會允許執行未經授權的指令碼

4.4. XSS漏洞對於攻擊者來說並不難發現，因為他們可以輕易地檢視網頁內容，來了解這個HTML內部的工作原理

  • 4.4.1. 攻擊者會設法將惡意資料儲存在伺服器或客戶端中

4.5. 基於DOM的XSS攻擊，它將HTML DOM作為惡意注入的來源，但其他方面的工作方式大致相同

4.6. 一個安全的Web框架應該內建XSS保護，在這種情況下，只要在框架內你就是安全的

  • 4.6.1. 與任何注入漏洞一樣，防禦機制包含避免任何不受信任的輸入進入Web頁面，以及有可能發生的惡意行為，或者執行輸入驗證來確保安全地處理輸入

5. 跨站請求偽造

5.1. CSRF（Corss-Site Request Forgery，跨站請求偽造）

5.2. 跨站請求偽造（CSRF，有時縮寫為XSRF）是對同源策略基本限制的攻擊

5.3. Web框架應該提供CSRF保護，但深入瞭解底層問題也很有價值，這樣你就可以確認保護機制確實有效，並且能夠確保不會干擾該機制

5.4. 同源策略對於POST的處理與GET相同，並且POST請求可以修改站點的狀態

5.5. 為了防止CSRF攻擊，請確保攻擊者無法猜測有效的狀態更改請求

  • 5.5.1. 將每個有效的POST請求都視為一片特殊的雪花，它只能在其預期的使用環境中工作一次

  • 5.5.2. 一個簡單的方法是在所有表單中包含一個秘密令牌並將其作為隱藏欄位，然後檢查每個請求中是否包含與給定Web會話相同的秘密令牌

  • 5.5.3. 從會話cookie中派生出令牌是一個很好的解決方案

  • 5.5.3.1. 檢查所必需的資訊都可以在POST請求中獲得

  • 5.5.4. 另一種緩解措施是使用隨機數（不可猜測的一次性令牌）​，但為了抵禦CSRF攻擊，你仍須將其與預期的客戶會話繫結在一起

  • 5.5.4.1. 這個解決方案會為表單的CSRF令牌生成一個隨機數，將令牌儲存在一個由會話進行索引的表中，然後透過查詢會話的隨機數並判斷它與表單中的隨機數是否匹配，對錶單進行驗證

5.6. 現代瀏覽器在cookie上支援使用SameSite屬性來緩解CSRF攻擊

  • 5.6.1. SameSite=Strict會阻止頁面上的任何第三方請求向其他域傳送cookie，這就會阻止CSRF攻擊，但在導航到另一個需要其cookie的站點時可能會破壞由cookie帶來的有用行為

  • 5.6.2. 一種客戶端側對於CSRF的防禦措施，伺服器完全依賴它可能會面臨風險，因此應該將其作為額外的緩解措施，而不是唯一的緩解措施

6. 注意的問題

6.1. 不要讓攻擊者將不受信任的輸入注入HTTP頭（類似於XSS）

6.2. 指定準確的MIME內容型別，以確保瀏覽器正確地處理響應

6.3. 開放式重定向可能會出現問題：不允許重定向到任意URL

6.4. 僅使用＜IFRAME＞嵌入你可以信任的網站（很多瀏覽器支援X-Frame-Options頭緩解措施）​

6.5. 在處理不受信任的XML資料時，要注意XXE攻擊

6.6. CSS的:visited選擇器可能會披露瀏覽器歷史中是否有給定的URL

6.7. CSP（Content Security Policy，內容安全策略）響應頭，以減少XSS暴露

  • 6.7.1. 可以為指令碼或影像指定擁有授權的來源（和其他類似功能）​，允許瀏覽器阻止從其他域注入內聯指令碼或其他惡意內容的嘗試

  • 6.7.2. 客戶端側的防禦措施，不受你的控制，因此不要將其看作對XSS完全免疫的通行證

6.8. 在測試環境中，在所有Web頁面中新增特定的安全策略，然後對網站進行測試，並針對每個問題追蹤被阻止的行為

6.9. 很多HTTP響應頭可以幫助你指定瀏覽器應該允許或不應該允許的內容，包括Content- Security-Policy響應頭、Referrer-Policy響應頭、Strict-Transport-Security響應頭、X-Content-Type-Options響應頭和X-Frame-Options響應頭

相關文章