文件下載接口的URL構造分析與討論
某學院的文件下載接口
http://www.****.edu.cn/item/filedown.asp?id=76749&Ext=rar&fname=filedown.rar
參數分析：
id資源的idExt資源的文件下載格式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
這是多數網站采用的文件下載的方式方法，該方法就是通過<a href="****"/>來下載某個目錄下的文件，該方法時最低技術水平的有效方法，當然了，在信安測試，為了放置目錄資料被有效的遍歷，都會要求將所有上傳的文件重命名保存。
此類的文件下載URL構造，數不勝數。
還有一些喜歡“捉迷藏”的文件下載URL：
結束語
上述的文件下載URL構造，就是我在近期挖掘“任意文件下載”一類漏洞常見的構造方式；通常來說，此類的URL構造類似於“<a/>”標簽，都具有一種比較難有方法的；而對於使用id參數值進行文件下載，往往是采用“SQL注入”的方式來進行突破，但這就並不是“任意文件下載”了，以為以id作為唯一文件下載索引方式的URL，是無法構造出下載約定計划以外的文件；當然了最有可能存在“任意文件下載”漏洞的URL就是“某協會文件下載接口”中的那類URL，它是通過我們給腳本文件傳遞一個path來下載該path指向的文件，本文中的對象，它采用了不同的服務器，無法通過任意文件下載來突破網站，除此之外，還有的則是采用“第三方”存放資源，只可惜我在撰寫本文時，瀏覽眾多網站並沒有找到相關的。
討論
2021/01/13
個人認為，目前我所遇到的所有文件下載的URL構造，無非通過三類：
-
直接使用a標簽指向資源路徑位置，此類URL極難形成任意文件下載。
-
后端采用數據庫的ID索引方式，每一個ID指向一個資源path，在后端執行path獲取和下載，最大程度的減少意料之外的資源paht和惡意URL的出現，不過與此同時寫需要加強SQL防注入。
-
向文件下載的download接口傳遞一個"URL/Path"，接口向該地址的文件資源發起下載並返回給當前位置；這類方式是最容易出現“任意文件下載”危害的，所以不建議采用此類。