文件下载接口的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

这是多数网站采用的文件下载的方式方法，该方法就是通过<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”，接口向该地址的文件资源发起下载并返回给当前位置；这类方式是最容易出现“任意文件下载”危害的，所以不建议采用此类。