前端安全-XSS、CRSF、SSRF總結

引用
作者：美團技術團隊
前端安全系列之一：如何防止XSS攻擊？
鏈接：https://juejin.im/post/5bad9140e51d450e935c6d64
前端安全系列之二：如何防止CSRF攻擊？
鏈接：https://juejin.im/post/5bc009996fb9a05d0a055192
作者：BerL1n　鏈接：https://www.jianshu.com/p/d1d1c40f6d4c
作者：z3r0yu 鏈接：https://xz.aliyun.com/t/2115

1.XSS攻擊

1.1XSS定義

​ Cross-Site Scripting（跨站腳本攻擊）簡稱 XSS，是一種代碼注入攻擊。攻擊者通過在目標網站上注入惡意腳本，使之在用戶的瀏覽器上運行。利用這些惡意腳本，攻擊者可獲取用戶的敏感信息如 Cookie、SessionID 等，進而危害數據安全。

​ XSS 的本質是：惡意代碼未經過濾，與網站正常的代碼混在一起；瀏覽器無法分辨哪些腳本是可信的，導致惡意腳本被執行。

1.2XSS注入方式

• 在 HTML 中內嵌的文本中，惡意內容以 script 標籤形成注入。
• 在內聯的 JavaScript 中，拼接的數據突破了原本的限制（字符串，變量，方法名等）。
• 在標籤屬性中，惡意內容包含引號，從而突破屬性值的限制，注入其他屬性或者標籤。
• 在標籤的 href、src 等屬性中，包含 javascript: 等可執行代碼。
• 在 onload、onerror、onclick 等事件中，注入不受控制代碼。
• 在 style 屬性和標籤中，包含類似 background-image:url("javascript:..."); 的代碼（新版本瀏覽器已經可以防範）。
• 在 style 屬性和標籤中，包含類似 expression(...) 的 CSS 表達式代碼（新版本瀏覽器已經可以防範）。

總之，如果開發者沒有將用戶輸入的文本進行合適的過濾，就貿然插入到 HTML 中，這很容易造成注入漏洞。攻擊者可以利用漏洞，構造出惡意的代碼指令，進而利用惡意代碼危害數據安全。

1.3預防方式

• 輸入過濾：在用戶提交時，由前端過濾輸入，然後提交到後端。

  • 缺點：會導致亂碼問題，只能解決特定的XSS問題。
  • 適用於有明確輸入類型的數據的過濾：如數字、URL、電話號碼、郵件地址等用戶提交信息。

• 預防存儲型和反射型XSS攻擊：存儲型和反射型 XSS 都是在服務端取出惡意代碼後，插入到響應 HTML 裏的，攻擊者刻意編寫的“數據”被內嵌到“代碼”中，被瀏覽器所執行。預防這兩種漏洞，有兩種常見做法：

  • 改成純前端渲染，把代碼和數據分隔開，瀏覽器先加載一個靜態 HTML，此 HTML 中不包含任何跟業務相關的數據，然後執行HTML中JavaScript通過Ajax加載業務數據。-
  • 對 HTML 做充分轉義：使用更完善更細緻的轉義策略，設置自定的HTML轉義規則。

• 預防 DOM 型 XSS 攻擊：DOM 型 XSS 攻擊，實際上就是網站前端 JavaScript 代碼本身不夠嚴謹，把不可信的數據當作代碼執行了。要通過避免在字符串中拼接不可信數據。

---

2.CSRF攻擊

2.1 CSRF定義

​ CSRF（Cross-site request forgery）跨站請求僞造：攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的註冊憑證，繞過後臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操作的目的。

CSRF的特點

• 攻擊一般發起在第三方網站，而不是被攻擊的網站。被攻擊的網站無法防止攻擊發生。
• 攻擊利用受害者在被攻擊網站的登錄憑證，冒充受害者提交操作；而不是直接竊取數據。
• 整個過程攻擊者並不能獲取到受害者的登錄憑證，僅僅是“冒用”。
• 跨站請求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等。部分請求方式可以直接嵌入在第三方論壇、文章中，難以進行追蹤。

CSRF通常是跨域的，因爲外域通常更容易被攻擊者掌控。但是如果本域下有容易被利用的功能，比如可以發圖和鏈接的論壇和評論區，攻擊可以直接在本域下進行，而且這種攻擊更加危險。

2.2CSRF攻擊方式

2.2.1攻擊流程

1. 受害者登錄a.com，並保留了登錄憑證（Cookie）。
2. 攻擊者引誘受害者訪問了b.com。
3. b.com 向 a.com 發送了一個請求：a.com/act=xx。瀏覽器會默認攜帶a.com的Cookie。
4. a.com接收到請求後，對請求進行驗證，確認受害者的憑證，誤以爲是受害者自己發送的請求。
5. a.com以受害者的名義執行了act=xx。
6. 攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者，讓a.com執行了不當的操作。

2.2.2攻擊類型

• GET類型的CSRF

GET類型的CSRF利用非常簡單，只需要一個HTTP請求，一般會這樣利用：

 <img src="http://bank.example/withdraw?amount=10000&for=hacker" > 

在受害者訪問含有這個img的頁面後，瀏覽器會自動向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker發出一次HTTP請求。僞裝頁面bank.example就會收到包含受害者登錄信息的一次跨域請求。

• POST類型的CSRF

這種類型的CSRF利用起來通常使用的是一個自動提交的表單，如：

 <form action="http://bank.example/withdraw" method=POST>
    <input type="hidden" name="account" value="xiaoming" />
    <input type="hidden" name="amount" value="10000" />
    <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script> 

訪問該頁面後，表單會自動提交，相當於模擬用戶完成了一次POST操作。

POST類型的攻擊通常比GET要求更加嚴格一點，但仍並不複雜。任何個人網站、博客，被黑客上傳頁面的網站都有可能是發起攻擊的來源，後端接口不能將安全寄託在僅允許POST上面。

• 鏈接類型的CSRF

鏈接類型的CSRF並不常見，比起其他兩種用戶打開頁面就中招的情況，這種需要用戶點擊鏈接纔會觸發。這種類型通常是在論壇中發佈的圖片中嵌入惡意鏈接，或者以廣告的形式誘導用戶中招，攻擊者通常會以比較誇張的詞語誘騙用戶點擊，例如：

  <a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
  重磅消息！！
  <a/>

由於之前用戶登錄了信任的網站A，並且保存登錄狀態，只要用戶主動訪問上面的這個PHP頁面，則表示攻擊成功。

2.3預防方式

CSRF通常從第三方網站發起，被攻擊的網站無法防止攻擊發生，只能通過增強自己網站針對CSRF的防護能力來提升安全性。

上文中講了CSRF的兩個特點：

• CSRF（通常）發生在第三方域名。
• CSRF攻擊者不能獲取到Cookie等信息，只是使用。

針對這兩點，我們可以專門制定防護策略，如下：

• 阻止不明外域的訪問（例如：知乎、簡書跳轉外域時提醒）
  • 同源檢測
  • Samesite Cookie
• 提交時要求附加本域才能獲取的信息
  • CSRF Token
  • 雙重Cookie驗證

---

3.SSRF攻擊

3.1 SSRF定義

​ SSRF(Server-Side Request Forgery:服務器端請求僞造) 是一種由攻擊者構造由服務端發起請求的一個安全漏洞。一般情況下，SSRF是要目標網站的內部系統。（因爲他是從內部系統訪問的，所有可以通過它攻擊外網無法訪問的內部系統，也就是把目標網站當中間人）

​ SSRF漏洞就是通過篡改獲取資源的請求發送給服務器，但是服務器並沒有檢測這個請求是否合法的，然後服務器以他的身份來訪問其他服務器的資源。

3.2 SSRF攻擊方式

3.2.1攻擊流程

比如 ： A網站，是一個所有人都可以訪問的外網網站，B網站是一個他們內部的OA網站。

普通用戶只可以訪問a網站，不能訪問b網站。但是攻擊者可以同過a網站做中間人，訪問b網站，從而達到獲取b網站未公開信息的目的。

1. 輸入A網站URLwww.a.com/xxx.php?image=URL，發送請求
2. A服務器接受請求處理
3. 返回用戶相應

產生的原因：服務器端的驗證並沒有對其請求獲取圖片的參數（image=）做出過濾以及限制，導致A網站可以從其他服務器的獲取數據。如：

1. 輸入的URL爲：www.baidu.com/xxx.php?image=www.abc.com/1.jpg

2. 如果我們將www.abd.com/1.jpg換爲與該服務器相連的內網服務器地址，直接進行訪問。

3. 如果存在該內網地址就會返回1xx 2xx 之類的狀態碼，不存在就會其他的狀態碼。

由此就導致了內部網站資源的泄露，出現如下等問題:

1.內外網的端口和服務掃描；2.主機本地敏感數據的讀取； 3.內外網主機應用程序漏洞的利用； 4.內外網Web站點漏洞的利用。

3.3預防方式

1.禁止跳轉

2.過濾返回信息，驗證遠程服務器對請求的響應是比較容易的方法。如果web應用是去獲取某一種類型的文件。那麼在把返回結果展示給用戶之前先驗證返回的信息是否符合標準。

3.禁用不需要的協議，僅僅允許http和https請求。可以防止類似於file://, gopher://, ftp:// 等引起的問題

4.設置URL白名單或者限制內網IP（使用gethostbyname()判斷是否爲內網IP）

5.限制請求的端口爲http常用的端口，比如 80、443、8080、8090

6.統一錯誤信息，避免用戶可以根據錯誤信息來判斷遠端服務器的端口狀態。