「第八章」文件上传漏洞

「第三篇」服务器端应用安全 

    批注
        [……]    表示他人、自己、网络批注
            参考资料来源于
                * 优快云
                * GitHub
                * Google
                * 维基百科
                * YouTube
                * MDN Web Docs
            由于编写过程中无法记录所有的URL
            所以如需原文，请自行查询
        {……}    重点内容
        *……*    表示先前提到的内容，不赘述

    「第三篇」服务器端应用安全

        「0.6本书结构」
            就常见的服务器端应用安全问题进行了阐述
            这些问题往往能引起非常严重的后果，在网站的安全建设之初需要优先解决这些问题，避免留下任何隐患

        「第八章」文件上传漏洞

			[
				上传漏洞与SQL注入或XSS相比，其风险更大，如果Web应用程序存在上传漏洞，攻击者上传的文件是Web脚本语言，服务器的Web容器解释并执行了用户上传的脚本，导致代码执行
				如果上传的文件是Flash的策略文件crossdomain.xml，黑客用以控制Flash在该域下的行为
				如果上传的文件是病毒、木马文件，黑客用以诱骗用户或者管理员下载执行
				如果上传的文件是钓鱼图片或为包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈
				甚至攻击者可以直接上传一个webshell到服务器上完全控制系统或致使系统瘫痪
				原理
					大部分的网站和应用系统都有上传功能，而程序员在开发任意文件上传功能时，并未考虑文件格式后缀的合法性校验或者是否只在前端通过js进行后缀检验
					这时攻击者可以上传一个与网站脚本语言相对应的恶意代码动态脚本，例如(jsp、asp、php、aspx文件后缀)到服务器上，从而访问这些恶意脚本中包含的恶意代码，进行动态解析最终达到执行恶意代码的效果，进一步影响服务器安全
				绕过技巧
					一般来说文件上传过程中检测部分由客户端javascript检测、服务端Content-Type类型检测、服务端path参数检测、服务端文件扩展名检测、服务端内容检测组成
					但这些检测并不完善，且都有绕过方法
					客户端检测绕过(js检测)
						利用firebug禁用js或使用burp代理工具可轻易突破
					服务端MIME检测绕过(Content-Type检测)
						使用burp代理，修改Content-Type的参数
					服务端扩展名检测绕过
						文件名大小写绕过，例如Php，AsP等类似的文件名
						后缀名字双写嵌套，例如pphphp，asaspp等
						可以利用系统会对一些特殊文件名做默认修改的系统特性绕过
						可以利用asp程序中的漏洞，使用截断字符绕过
						可以利用不再黑名单列表中却能够成功执行的同义后缀名绕过黑名单的限制
						可以利用解析/包含漏洞配合上传一个代码注入过的白名单文件绕过
					服务端内容检测绕过
						通过在文件中添加正常文件的标识或其他关键字符绕过
				文件加载检测绕过，针对渲染加载测试
				代码注入绕过，针对二次渲染测试
				服务器解析漏洞
					Apache解析漏洞
						Apache解析文件的规则是从右到左开始判断解析，如果后缀名为不可识别文件解析，就再往左判断比如test.php.owf.rar
						.owf和.rar这两种后缀是apache不可识别解析，apache就会把wooyun.php.owf.rar解析成php
						若一个文件名abc.x1.x2.x3，Apache会从x3开始解析，如果x3不是一个能解析的扩展名，就往前解析x2以此往复，直到能遇到一个能解析的文件名为止
					IIS解析漏洞
						在test.asp/jkl，IIS的某些版本中会直接当成asp来解析，test.asp;jkl，IIS某些版本也会按照asp来解析，任意文件名/任意文件名.php，IIS某些版本会直接当php来解析
						IIS6.0在解析asp时有两个解析漏洞，一个是如果任意目录名包含.asp字符串，那么这个目录下的所有文件都会按照asp去解析，另一个是文件名中含有asp，就会优先当作asp来解析
						IIS7.0/7.5对php解析有所类似于Nginx的解析漏洞
						只要对任意文件名在url后面追加上字符串/任意文件名.php就会按照php去解析
						例如，上传test.jpg，然后访问test.jpg/.php或test.jpg/abc.php当前目录下就会生成一句话木马shell.php
					Nginx解析漏洞
						将shell语句，如<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>’);?>
						写在文本xx.txt中(或者shell语句直接写一句话木马，用菜刀、cknife等直连，只是容易被查杀)，然后用命令将shell语句附加在正常图片xx.jpg后copy xx.jpg/b + xx.txt/a test.jpg
						上传test.jpg，然后访问test.jpg/.php或test.jpg/abc.php当前目录下就会生成一句话木马shell.php
				防御
					系统运行时的防御
						* 文件上传的目录设置为不可执行，只要web容器无法解析该目录下面的文件，即使攻击者上传了脚本文件，服务器本身也不会受到影响，因此这一点至关重要
						* 判断文件类型
							在判断文件类型时，可以结合使用MIME Type、后缀检查等方式，在文件类型检查中，强烈推荐白名单方式，黑名单的方式已经无数次被证明是不可靠的
							此外，对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的HTML代码
						* 使用随机数改写文件名和文件路径
							文件上传如果要执行代码，则需要用户能够访问到这个文件
							在某些环境中，用户能上传，但不能访问，如果应用了随机数改写了文件名和路径，将极大地增加攻击的成本
							再来就是像shell.php.rar.rar和crossdomain.xml这种文件，都将因为重命名而无法攻击
						* 单独设置文件服务器的域名
							由于浏览器同源策略的关系，一系列客户端攻击将失效，比如上传crossdomain.xml、上传包含Javascript的XSS利用等问题将得到解决
						* 使用安全设备防御
							文件上传攻击的本质就是将恶意文件或者脚本上传到服务器，专业的安全设备防御此类漏洞主要是通过对漏洞的上传利用行为和恶意文件的上传过程进行检测
							恶意文件千变万化，隐藏手法也不断推陈出新，对普通的系统管理员来说可以通过部署安全设备来帮助防御
					系统开发阶段的防御
						* 系统开发人员应有较强的安全意识，尤其是采用PHP语言开发系统，在系统开发阶段应充分考虑系统的安全性
						* 对文件上传漏洞来说，最好能在客户端和服务器端对用户上传的文件名和文件路径等项目分别进行严格的检查
							客户端的检查虽然对技术较好的攻击者来说可以借助工具绕过，但是这也可以阻挡一些基本的试探
							服务器端的检查最好使用白名单过滤的方法，这样能防止大小写等方式的绕过，同时还需对%00截断符进行检测，对HTTP包头的content-type也和上传文件的大小也需要进行检查
					系统维护阶段的防御
						* 系统上线后运维人员应有较强的安全意思，积极使用多个安全检测工具对系统进行安全扫描，及时发现潜在漏洞并修复
						* 定时查看系统日志，web服务器日志以发现入侵痕迹
							定时关注系统所使用到的第三方插件的更新情况，如有新版本发布建议及时更新，如果第三方插件被爆有安全漏洞更应立即进行修补
						* 对于整个网站都是使用的开源代码或者使用网上的框架搭建的网站来说，尤其要注意漏洞的自查和软件版本及补丁的更新，上传功能非必选可以直接删除。除对系统自生的维护外，服务器应进行合理配置，非必选一般的目录都应去掉执行权限，上传目录可配置为只读
			]

            「8.1文件上传漏洞概述」
                文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器命令的能力，这种攻击方法是最为直接和有效的，有时候几乎没有技术门槛
                在互联网中，我们经常到文件上传功能，比如上传一张自定义的图片，分享一段视频或者照片，论坛发帖时附带一个附件，在发送邮件时附带附件等
                文件上传功能本身是一个正常的业务需求，对于网站来说，很多时候也确实需要用户将文件上传服务器，所以文件上传本身没有问题，但有问题的是文件上传后，服务器怎么处理、解释文件，如果服务器的处理逻辑做得不够安全，则会导致严重的后果
                文件上传后导致的常见安全问题有
                    * 上传文件是Web脚本语言，服务器的Web容器解释并执行了用户上传的脚本，导致代码执行
                    * 上传文件是Flash的策略文件crossdomain.xml，黑客用以控制Flash在该域下的行为(其他通过类似方式控制策略文件的情况类似)
                    * 上传文件是病毒、木马文件，黑客用以诱使用户或者管理员下载执行
                    * 上传文件是钓鱼图片或包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈
                除此之外，还有一些还有一些不常见的方法，如将上传文件作为一个入口，一处服务器的后台处理程序，或者上传一个合法的文本文件，其内容包含PHP脚本，再通过本地文件包含漏洞(Local File Include)执行脚本等等
                在大多数情况下，文件上传漏洞一般都是指上传Web脚本能够被服务器解析的问题，也就是通常说的Webshell的问题
                要完成这个攻击，要满足以下条件
                    * 上传的文件能够本Web容器解析执行，所以文件上传后所在的目录要是Web容器所覆盖到的路径
                    * 用户能够从Web上访问这个文件，如果文件上传了，但用户无法通过Web访问，或者无法使得Web容器解释这个脚本，那么也不能称之为漏洞
                    * 用户上传的文件如果被安全检查、格式化、图片压缩等功能改变了内容，则也可能导致攻击不成功

                8.1.1FCKEditor文件上传漏洞
                    FCKEditor是一款非常流行的富文本编辑器，为了方便用户，它带有一个上传文件功能，但是这个功能却出过许多次漏洞
                    FCKEditor针对ASP/PHP/JSP等环境都有对应的版本
                    黑名单与白名单的问题，在第一章中就有过论述，黑名单是一种非常不好的设计思想
                    由于FCKEditor一般是作为第三方应用集成到网站中的，因此文件上传的目录一般默认都会被Web容器所解析，很容易形成文件上传漏洞
                    很多开发者在使用FCKEditor时，可能都不知道它存在一个文件上传功能，如果不是特别需要，建议删除FCKEditor的文件上传代码，一般情况下也用不到它

                8.1.2绕过文件上传检查功能
                    在针对上传文件的检查中，很多应用都是通过判断文件名后缀的方法来验证文件的安全性的
                    但是在某些时候，如果攻击者手动修改了上传过程的POST包，在文件名后添加一个%00字节，则可以截断某些函数对文件名的判断
                    因为在许多语言的函数中，比如在C、PHP等语言的常用字符串处理函数中，0x00被认为是终止符，受此影响的环境有Web应用和一些服务器
                    比如应用原本只允许上传JPG图片，那么可以构造文件名(需要修改POST包)为xxx.php[\0].JPG，其中[\0]为十六进制的0x00字符，.JPG绕过了应用的上传文件类型判断，但对于服务器端来说，此文件因为0字节截断的关系，最终却会变成xxx.php，%00字符截断的问题不只在上传文件漏洞中有所利用，因为这是一个被广泛用于字符串处理函数的保留字符，因此在各种不同的业务逻辑中都可能出现问题，需要引起重视
                    除了常见的检查文件名后缀的方法外，有的应用，还会通过判断上传文件的文件头来验证文件的类型
                    在正常情况下，通过判断前10个字节，基本上就能判断出一个文件的真实类型
                    浏览器的MIME Sniff功能实际上也是通过读取文件的前256个字节，来判断文件的类型的

            「8.2功能/漏洞」
                在文件上传漏洞的利用过程中，攻击者发现一些和Web Server本身特性相关的功能，如果加以利用，就会变成威力巨大的武器，这往往是因为应用的开发者没有深入理解Web Server的细节所导致的

                8.2.1Apache文件解析问题
                    Apache对于文件名的解析是从后往前解析的，直到遇见一个Apache认识的文件类型为止
                    --------------------------------
                    Phpshell.php.rar.rar.rar.rar.rar
                    --------------------------------
                    因为Apache不认识.rar这个文件类型，所以会一直遍历后缀到.php，然后认为这是一个PHP类型的文件
                    Apache的这个特性，很多工程师在写应用时并不知道，即便知道，可能有的工程师也会认为这是Web Server该负责的事情
                    如果不考虑这些因素，写出的安全检查功能可能就会存在缺陷

                8.2.2IIS文件解析问题
                    IIS 6在处理文件解析时，也出过一些漏洞
                    前面提到的0x00字符截断文件名，在IIS和Win-dows环境下曾经出过非常类似的漏洞，不过截断字符变成了;
                    当文件名为abc.asp;xx.jpg时，IIS 6会将此文件解析为abc.asp，文件名被截断了，从而导致脚本被执行
                    除此漏洞外，在IIS 6中还曾经出过一个漏洞——因为处理文件夹扩展名出错，导致将/*.asp/目录下的所有文件都作为ASP文件进行解析
                    这个abc.jpg，会被当做ASP文件进行解析
                    注意这两个IIS的漏洞，是需要在服务器的本地硬盘上确实存在这样的文件或者文件夹，若只是通过Web应用映射出来的URL，则是无法触发的
                    这些历史上存在的漏洞，也许今天还能在互联网中找到不少未修补漏洞的网站
                    谈到IIS，就不得不谈在IIS中，支持PUT功能所导致的若干上传脚本问题
                    PUT是在WebDav中定义的一个方法，Web-Dav大大扩展了HTTP协议中GET、POST、HEAD等功能，它所包含的PUT方法，允许用户上传文件到指定的路径下
                    在许多Web Server中，默认都禁用了此方法，或者对能够上传的文件类型做了严格限制，但在IIS中，如果目录支持写权限， 同时开启了WebDav，则会支持PUT方法，再结合MOVE方法， 就能够将原本只允许上传文本文件改写为脚本文件，从而执行webshell，MOVE能否执行成功，取决于IIS服务器是否勾选了“脚本资源访问”复选框一般要实施此攻击过程，攻击者应先通过OP-TIONS方法探测服务器支持的HTTP方法类型，如果支持PUT，则使用PUT上传一个指定的文本文件，最后再通过MOVE改写为脚本文件
                    国内的安全研究者zwell曾经写过一个自动化的扫描工具IIS PUTScanner，以帮助检测此类问题
                    从攻击原理看，PUT方法造成的安全漏洞，都是由于服务器配置不当造成的，WebDav给管理员带来了很多方便，但如果不能了解安全的风险和细节，则等于向黑客敞开了大门

                8.2.3PHP CGI路径解析问题
                    国内的安全组织80sec发布了一个Nginx的漏洞，指出在Nginx配置fastcgi使用PHP时，会存在文件类型解析问题，这将给上传漏洞大开方便之门
                    在PHP的bug tracker上就有人分别在PHP 5.2.12和PHP5.3.1版本下提交了这一bug
                    PHP官方对此bug的描述，并同时给出了一个第三方补丁
                        http://patch.joeysmith.com/acceptpathinfo-5.3.1.patch
                    可是PHP官方认为这是PHP的一个产品特性，并未接受此补丁
                    PHP官方对此bug的回复
                        这个漏洞是怎么一回事呢?其实可以说它与Nginx本身关系不大，Nginx只是作为一个代理把请求转发给fastcgi Server，PHP在后端处理这一切，因此在其他的fastcgi环境下，PHP也存在此问题，只是使用Nginx作为Web Server时，一般使用fastcgi的方式调用脚本解释器，这种使用方式最为常见
                    试想
                        如果在任何配置为fastcgi的PHP应用里上传一张图片(可能是头像，也可能是论坛里上传的图片等)，其图片内容是PHP文件，则将导致代码执行，其他可以上传的合法文件如文本文件、压缩文件等情况类似
                    出现这个漏洞的原因与在fastcgi方式下，PHP获取环境变量的方式有关
                    PHP的配置文件中有一个关键的选项cgi.fix_pathinfo，这个选项默认是开启的
                    在映射URI时，两个环境变量很重要
                        * PATH_INFO
                        * SCRIPT_FILENAME
                    这个选项为1时，在映射URI时，将递归查询路径确认文件的合法性
                    PHP官方给出的建议是将cgi.fix_pathinfo设置为0，但可以预见的是，官方的消极态度在未来仍然会使得许许多多的不知情者遭受损失

                8.2.4利用上传文件钓鱼
                    前面讲到Web Server的一些“功能”可能会被攻击者利用，绕过文件上传功能的一些安全检查，这是服务器端的事情
                    但在实际环境中，很多时候服务器端的应用，还需要为客户端买单
                    钓鱼网站在传播时，会通过利用XSS、服务器端302跳转等功能，从正常的网站跳转到钓鱼网站
                    但钓鱼网站，仍然会在URL中暴露真实的钓鱼网站地址，细心点的用户可能不会上当
                    而利用文件上传功能，钓鱼者可以先将包含了HTML的文件上传到目标网站，然后通过传播这个文件的URL进行钓鱼，则URL中不会出现钓鱼地址，更具有欺骗性
                    在正常情况下，浏览器是不会将jpg文件当做HTML执行的，但是在低版本的IE中，比如IE 6和IE 7，包括IE 8的兼容模式，浏览器都会自作聪明地将此文件当做HTML执行
                    这个问题在很早以前就被用来制作网页木马，但微软一直认为这是浏览器的特性，直到IE 8中有了增强的MIMESniff，才有所缓解
                    从网站的角度来说，它似乎是无辜的受害者，但面临具体业务场景时，不得不多多考虑此类问题

            「8.3设计安全的文件上传功能」
                本章一开始就提到，文件上传功能本身并没错，只是在一些条件下会被攻击者利用，从而成为漏洞
                * 文件上传的目录设置为不可执行
                    只要Web容器无法解析该目录下的文件，即使攻击者上传了脚本文件，服务器本身也不会受到影响
                    因此此点至关重要，在实际应用中，很多大型网站的上传应用，文件上传后会放到独立的存储上，做静态文件处理，一方面方便使用缓存加速，降低性能损耗，另一方面也杜绝了脚本执行的可能
                    但是对于一些边边角角的小应用，如果存在文件上传功能，则仍需要多加关注
                * 判断文件类型
                    在判断文件类型时，可以结合使用MIMEType、后缀检查等方式，在文件类型检查中，强烈推荐白名单的方式，黑名单的方式已经无数次被证明是不可靠的
                    此外，对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的HTML代码
                * 使用随机数改写文件名和文件路径
                    文件上传如果要执行代码，则需要用户能够访问到这个文件，在某些环境中，用户能上传，但不能访问，如果应用使用随机数改写了文件名和路径，将极大地增加攻击的成本
                    与此同时，像shell.php.rar.rar这种文件，或者是crossdo-main.xml这种文件，都将因为文件名被改写而无法成功实施攻击
                * 单独设置文件服务器的域名
                    由于浏览器同源策略的关系，一系列客户端攻击将失效，比如上传crossdomain.xml、上传包含JavaScript的XSS利用等问题将得到解决
                    但能否如此设置，还需要看具体的业务环境
                文件上传问题，看似简单，但要实现一个安全的上传功能，殊为不易
                如果还要考虑到病毒、木马、色情图片与视频、反动政治文件等与具体业务结合更紧密的问题，则需要做的工作就更多了，
                不断地发现问题，结合业务需求，才能设计出最合理、最安全的上传功能

            「8.4总结」
                文件上传本来是一个正常的功能，但黑客们利用这个功能就可以跨越信任边界，如果应用缺乏安全检查，或者安全检查的实现存在问题，就极有可能导致严重的后果
                文件上传往往与代码执行联系在一起
                因此对于所有业务中要用到的上传功能，都应该由安全工程师进行严格的检查
                同时文件上传又可能存在诸如钓鱼、木马病毒等危害到最终用户的业务风险问题，使得我们在这一领域需要考虑的问题越来越多