2022面試精選之常規應用漏洞 - 網安 - 專業的網絡安全產業、社區、知識平臺

今天分享一篇文章，涉及Redis未授權、SSRF漏洞、寬字節注入、JSONP劫持、CORS、CRLF注入等技能，并詳細講述了其原理和漏洞利用等。

常規應用漏洞

Redis未授權訪問漏洞如何入侵利用

redis漏洞產生原因

(1) redis綁定在 0.0.0.0:6379，且沒有進行添加防火墻規則避免其他非信任來源 ip 訪問等相關安全策略，直接暴露在公網；

(2) 沒有設置密碼認證（一般為空），可以免密碼遠程登錄redis服務。

(3) root 身份運行redis

redis利用方法

(1) 能夠回連且權限夠的話，寫crontab利用計劃任務執行命令反彈shell

(2) 開啟22端口且權限夠大的情況下，通過寫公鑰到服務器獲得系統權限

(3) 知道物理路徑且web目錄有寫權限寫webshell (4) redis 4.x之后,主從復制getshell

(4) redis 4.x之后,主從復制getshell

SSRF漏洞原理、利用方式及修復方案？Java和PHP的SSRF區別

SSRF漏洞原理

原理：利用一個可以發起網絡請求的服務，當作跳板來攻擊其他服務。

SSRF漏洞位置

SSRF漏洞一般位于遠程圖片加載、圖片或文章收藏功能、URL分享、通過URL在線翻譯、轉碼等功能點處。

(1) 分享：通過url地址分享網頁內容

(2) 轉碼：通過URL地址把原地址的網頁內容調優使其適合手機屏幕瀏覽

(3) 在線翻譯：通過URL地址翻譯對應文本的內容

(4) 圖片加載與下載：通過URL地址加載或下載圖片

(5) 圖片、文章收藏功能

SSRF漏洞利用

(1) CURL支持協議

(2) 利用file協議讀取文件

(3) 利用dict協議查看端口開放

(4) 利用gopher協議反彈shell

SSRF漏洞利用繞過

(1)使用@：http://A.com@10.10.10.10 = 10.10.10.10

(2)IP地址轉換成十進制、八進制：127.0.0.1 = 2130706433

(3)使用短地址：http://10.10.116.11 = http://t.cn/RwbLKDx

(4)端口繞過：ip后面加一個端口

(5xip.io：10.0.0.1.xip.io = 10.0.0.1

(6)通過js跳轉..

(7)利用DNS解析

(8)利用句號（127。0。0。1）

(9)利用[::]（http://[::]:80/）；

(10)利用短地址（http://dwz.cn/11SMa）；

（11）協議（Dict://、SFTP://、TFTP://、LDAP://、Gopher://）

SSRF漏洞修復方式

(1) 過濾返回信息，驗證遠程服務器對請求的響應是比較容易的方法；

(2) 統一錯誤信息，避免用戶可以根據錯誤信息來判斷遠端服務器的端口狀態；

(3) 限制請求的端口為http常用的端口，比如，80,443,8080,8090；

(4) 黑名單內網ip。避免應用被用來獲取獲取內網數據，攻擊內網；

(5) 禁用不需要的協議。僅允許http和https請求；

(6) 使用正則對參數進行效驗，防止畸形請求繞過黑名單。

(7) 禁止30x跳轉

Java和PHP的SSRF區別

PHP支持的協議：
·file:// — Accessing local filesystem
·http:// — Accessing HTTP(s) URLs
·ftp:// — Accessing FTP(s) URLs
·php:// — Accessing various I/O streams
·zlib:// — Compression Streams
·data:// — Data (RFC 2397)
·glob:// — Find pathnames matching pattern
·phar:// — PHP Archive
·ssh2:// — Secure Shell 2
·rar:// — RAR
·ogg:// — Audio streams
·expect:// — Process Interaction Streams
Java支持的協議：
·file
·ftp
·gopher
·http
·https
·jar
·mailto
·netdoc

寬字節注入漏洞原理、利用方式及修復方案？

注入

gbk編碼 %df

使用mysql_set_charset(GBK)指定字符集

簡述JSONP的業務意義，JSONP劫持利用方式及修復方案？如何設計落地一個CSRF Token？

如何設計落地一個CSRF Token

在請求中添加一個攻擊者不知道的參數（且該參數瀏覽器不會自動發送），讓服務端可以區別出請求是否經過用戶的同意。

這樣用戶知道該參數，發送請求的時候，攜帶 cookie 和該參數；而攻擊者不知道該參數，瀏覽器發送請求時，只自動攜帶了 cookie。服務端即可通過校驗該參數，來判斷操作是否是用戶真實想進行的。

這個參數，就被稱為 csrf token。

HTTP request Header

將 token 添加在 header 中發送，它具有一個天然的優勢，可以利用瀏覽器的同源策略：csrf token header 相當于一個自定義 header，在跨域請求時，攜帶自定義 header，會觸發預檢請求，若預檢請求不通過，正式請求就不會發送。

雙重提交（Double Submit Cookie）

在請求到達服務端后，服務端不需要再從數據庫/緩存中讀取對應的值來跟 csrf token 比對。只需要跟請求中的 csrf cookie 比對即可。這個 cookie 就是服務端當初簽發出去的 token 參數。只要它們相等，就證明請求是經過用戶同意發送的，因為攻擊者無法讀取這個 cookie 值，也就無法將這個值作為 token 參數，添加到請求中發送，而用戶是知道的（用戶可以讀取 csrf token cookie）。我們可以使用加密簽名的方式：將用戶的 session token 作為明文，使用服務端的密鑰進行加密簽名，將后面的密文作為 csrf token value 發送給客戶端。使用 session token 作為明文有 2 個好處：即保證了 csrf token 跟 user 綁定，又保證了 csrf token 的隨機且唯一。即：csrf_token = HMAC(session_token, application_secret)

當服務端收到請求后，從緩存/數據庫/cookie 中獲取原來的加密明文 session_token，使用服務端的密鑰再進行一次加密簽名，比對簽名后的結果和請求中攜帶的 csrf token 參數是否相等，若相等，則：csrf token 是服務端簽發的

簽名的內容沒有被篡改，即該 token 就是當前用戶的。

CORS原理、利用及修復？

原理、利用、修復

(1)CORS全稱是"跨域資源共享"（Cross-origin resource sharing）,Origin源未嚴格，從而造成跨域問題,允許瀏覽器向跨源服務器，發出XMLHttpRequest請求

(2)Origin為*的時候，使用curl測試CORS，

curl -H “Origin: https://evil.com” -I

CRLF注入原理

原理

CRLF 指的是回車符(CR，ASCII 13，\r，%0d) 和換行符(LF，ASCII 10，\n，%0a)。

CRLF注入漏洞的本質和XSS有點相似，攻擊者將惡意數據發送給易受攻擊的Web應用程序，Web應用程序將惡意數據輸出在HTTP響應頭中。（XSS一般輸出在主體中）

所以CRLF注入漏洞的檢測也和XSS漏洞的檢測差不多。通過修改HTTP參數或URL，注入惡意的CRLF，查看構造的惡意數據是否在響應頭中輸出。

URL白名單如何繞過？

繞過方式

(1)利用問號繞過限制

http://www.aaa.com/acb?Url=http://login.aaa.com 
http://www.aaa.com/acb?Url=http://test.com?login.aaa.com

(2)利用反斜杠和正斜杠繞過限制

http://www.aaa.com/acb?Url=http://login.aaa.com/ 
http://www.aaa.com/acb?Url=http://test.com/login.aaa.com 
http://www.aaa.com/acb?Url=http://test.com\login.aaa.com 
http://test.com.login.aaa.com

(3)利用@繞過URL限制

http://www.aaa.com/acb?Url=http://login.aaa.com@test.com

(4)白名單缺陷繞過限制 testxxx.com

(5)多重跳轉的問題導致可繞過URL限制

(6)可信站點（baidu.com）302跳轉繞過限制

(7)利用#號繞過

https://www.baidu.com/#login.aaa.com

XSS持久化如何實現？

XSS持久化

XSS持久化依賴于儲存型XSS漏洞，當發現有存儲型XSS漏洞時，會嘗試插入一段JS代碼用于竊取cookie，配合hook可以實現更多操作。持久化一般采用無感記錄，如登錄記錄，cookie記錄等，并發送到指定接收端。

Fastjson常見漏洞原理？如何徹底解決Fastjson漏洞？

Fastjson漏洞原理

1.fastjson-1.2.24

(fastjson接受的JSON可以通過艾特type字段來指定該JSON應當還原成何種類型的對象，在反序列化的時候方便操作)

2.fastjson-1.248以下

(checkAutoType中使用

TypeUtils.getClassFromMapping(typeName)去獲取class不為空，從而繞過了黑名單檢測)

3.fastjson-1.2.60以下

(在此版本以下，字符串中包含\x轉義字符時可以造成dos漏洞)

1.2.70及以上版本，目前暫未被披露存在高危的漏洞利用鏈。

當autotype開啟時，參數中使用“@type”字段，可以指定任意的類，fastjson將反序列化為指定的對象。

官方維護了一份常見危險類型的黑名單，但眾所周知，黑名單的機制很難覆蓋全面。如果有攻擊者找到黑名單以外的危險類型，依然會產生嚴重危害。

解決Fastjson漏洞

方案一：開啟safemode 適用于完全不需要autoType的應用。開啟時，會強制關閉autoType。

優點：最安全的方案，完全禁用autoType，新的版本再爆出反序列化漏洞時，極大概率不需要再升級也能免疫。

不足：僅適用于完全不需要autoType的應用。

方案二：配置一個autoType白名單。

優點：相對安全，可以避免一些惡意類的傳入，前提是白名單范圍要盡量縮小。新的版本再爆出反序列化漏洞時，大概率不需要再升級也能免疫。

不足：情況復雜的業務，梳理有哪些數據是需要用到autoType反序列化的，整理出白名單需要一定時間。

方案三：autoType黑名單

優點：整改成本低，處理速度快。

不足：安全性不如前兩種方案，短期內可作為臨時方案，緩解外部漏洞探測。有極低的概率會對已有業務產生影響（反序列化的內容里包含java.net.前綴類型對象的情況）。