|
「第三篇」服务器端应用安全?
?? ?批注
?? ??? ?[……]?? ?表示他人、自己、网络批注
?? ??? ??? ?参考资料来源于
?? ??? ??? ??? ?* CSDN
?? ??? ??? ??? ?* GitHub
?? ??? ??? ??? ?* Google
?? ??? ??? ??? ?* 维基百科
?? ??? ??? ??? ?* YouTube
?? ??? ??? ??? ?* MDN Web Docs
?? ??? ??? ?由于编写过程中无法记录所有的URL
?? ??? ??? ?所以如需原文，请自行查询
?? ??? ?{……}?? ?重点内容
?? ??? ?*……*?? ?表示先前提到的内容，不赘述
?? ?「第三篇」服务器端应用安全
?? ??? ?「0.6本书结构」
?? ??? ??? ?就常见的服务器端应用安全问题进行了阐述
?? ??? ??? ?这些问题往往能引起非常严重的后果，在网站的安全建设之初需要优先解决这些问题，避免留下任何隐患
?? ??? ?「第八章」文件上传漏洞
?? ??? ??? ?「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总结」
?? ??? ??? ??? ?文件上传本来是一个正常的功能，但黑客们利用这个功能就可以跨越信任边界，如果应用缺乏安全检查，或者安全检查的实现存在问题，就极有可能导致严重的后果
?? ??? ??? ??? ?文件上传往往与代码执行联系在一起
?? ??? ??? ??? ?因此对于所有业务中要用到的上传功能，都应该由安全工程师进行严格的检查
?? ??? ??? ??? ?同时文件上传又可能存在诸如钓鱼、木马病毒等危害到最终用户的业务风险问题，使得我们在这一领域需要考虑的问题越来越多
?
|