# 檔案下載介面的URL構造分析與討論 ## 某學院的檔案下載介面 `http://www.****.edu.cn/item/filedown.asp?id=76749&Ext=rar&fname=filedown.rar` 引數分析： - `id` 資源的id - `Ext` 資源的檔案下載格式 - `fname` 檔案下載後的名字 邏輯原理： 傳送引數給filedown.asp，asp檔案接收引數id的值並從資料庫查詢對於ID資源的URL地址，並且下載；按照ext格式進行下載返回，按照fname對下載返回的檔案命名。 **** ## 某協會檔案下載介面 `http://www.****.org.cn/content/download.do?filename=test.doc&url=group1/M00/05/38/Cj0BE16hNJKAIuAEAAFkAF_b3No247.doc` 引數分析： - `filename` 檔案下載後的名字 - `url` 檔案的下載路徑  通過頁面的標籤分析，我們尋找到`downloadfile()`函式，我們呼叫該函式，我們則成功的下載了該函式，我們綜合分析該URL地址： ``` http://www.****.org.cn/content/download.do?filename=test.doc&url=group1/M00/05/38/Cj0BE16hNJKAIuAEAAFkAF_b3No247.doc ``` > `filename` 檔案下載後的名字 > > `url` 檔案的下載路徑 分析得知`group1/M00/05/38/Cj0BE16hNJKAIuAEAAFkAF_b3No247.doc`是該檔案的一個“相對”路徑，但我們不知道這個路徑的全部，於是我們測試一下： ``` http://www.****.org.cn/group1/M00/05/38/Cj0BE16hNJKAIuAEAAFkAF_b3No247.doc ``` 結果是不盡人意的。 根據開發的習慣，通常這類的檔案資源都會放到同一個路徑位置，於是我們去尋找該站點的檔案資源（比如：聲音、圖片、視訊）；果然，找到了這樣的一個地址： ``` http://118.***.**.***:80/group1/M00/07/15/Cj0BE18NZcyAAI-uAAEGa1djidw254.jpg ``` 仔細一看和我們之前DOC檔案的路徑大致相同，於是我們“動手”吧： ``` http://118.***.**.***:80/group1/M00/05/38/Cj0BE16hNJKAIuAEAAFkAF_b3No247.doc ```  成功，我們現在確定了該檔案的位置，在接下來就是一步一步的構造POC： ``` http://118.***.**.***:80/../../../../../../../../../../etc/passwd ``` Payload： ``` url=../../../../../../../etc/passwd ``` 在不繼續追究討論如果突破的前提下，我分析就到此了；不過細心的人已經發現，檔案資源存放的伺服器和網站並不在同一臺機器中，也就是說，我們的"任意檔案下載"並無法直接危害到網站，這也是一種有效的預防措施。（突破失敗） **** ## 某基金會檔案下載處介面URL和資料包 `http://www.****.org.cn//downlog/insert`  > ninfor.js  ``` POST //downlog/insert HTTP/1.1 Host: www.****.org.cn Content-Length: 187 Cache-Control: max-age=0 Origin: http://www.****.org.cn Upgrade-Insecure-Requests: 1 DNT: 1 Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 Edg/87.0.664.75 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Referer: http://www.****.org.cn/front/download/list/1 Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6 Cookie: JSESSIONID=70C46A039204087FEA92625A1FBBBA22; tq_current_visit_time=1610441247471; tracqinfo={r$"241470177168012"#ct$1#tt$0#lv$"2021-1-12^2C16^3A47^3A28"#lt$""#pu$""#cn$""#ib$0#bt$0#lb$1610441248270#ci$""#cr$""#pt$""} Connection: close url=http://www.****.org.cn/front/download/list/1&id=60&type=7&typename=1&contype=2&title=5-****** ``` 分析post的資料，可以發現，id引數是索引檔案的關鍵引數。 **** ## 某律師事務所網站的檔案下載處URL  這是多數網站採用的檔案下載的方式方法，該方法就是通過``來下載某個目錄下的檔案，該方法時最低技術水平的有效方法，當然了，在信安測試，為了放置目錄資料被有效的遍歷，都會要求將所有上傳的檔案重新命名儲存。 此類的檔案下載URL構造，數不勝數。  **** ## 還有一些喜歡“捉迷藏”的檔案下載URL：    **** ## 結束語 上述的檔案下載URL構造，就是我在近期挖掘“任意檔案下載”一類漏洞常見的構造方式；通常來說，此類的URL構造類似於“``”標籤，都具有一種比較難有方法的；而對於使用`id`引數值進行檔案下載，往往是採用“SQL注入”的方式來進行突破，但這就並不是“任意檔案下載”了，以為以`id`作為唯一檔案下載索引方式的URL，是無法構造出下載約定計劃以外的檔案；當然了最有可能存在“任意檔案下載”漏洞的URL就是“某協會檔案下載介面”中的那類URL，它是通過我們給指令碼檔案傳遞一個path來下載該path指向的檔案，本文中的物件，它採用了不同的伺服器，無法通過任意檔案下載來突破網站，除此之外，還有的則是採用“第三方”存放資源，只可惜我在撰寫本文時，瀏覽眾多網站並沒有找到相關的。 # 討論 ## 2021/01/13 個人認為，目前我所遇到的所有檔案下載的URL構造，無非通過三類： - 直接使用a標籤指向資源路徑位置，此類URL極難形成任意檔案下載。 - 後端採用資料庫的ID索引方式，每一個ID指向一個資源path，在後端執行path獲取和下載，最大程度的減少意料之外的資源paht和惡意URL的出現，不過與此同時寫需要加強SQL防注入。 - 向檔案下載的download介面傳遞一個"URL/Path"，介面向該地址的檔案資源發起下載並返回給當前位置；這類方式是最容易出現“任意檔案下載”危害的，所以不建議採用