文件上传漏洞是指网络攻击者上传了一个可执行的文件到服务器上,当开发者没有对该文件进行合理的校验及处理的时候,很有可能让程序执行这个上传文件导致安全漏洞。大部分网站都会有文件上传的功能,例如头像、图片、视频等,这块的逻辑如果处理不当,很容易触发服务器漏洞。这种漏洞在以文件名为 URL 特征的程序中比较多见。嗯,是的说的就是世界上最好的语言 php。例如用户上传了一个 PHP 文件,拿到对应文件的地址之后就可以执行它了,其中的危害自然不言而喻。那在 Node.js 中就没有文件上传漏洞了么?答案肯定是否的。除了可执行文件外,还有以下几个潜在的问题。
用户上传的文件里有两个东西经常会被程序使用,一个是文件本身,还有一个就是文件名了。如果文件名被用来读取或者存储内容,那么你就要小心了。攻击者很有可能会构造一个类似 ../../../attack.jpg 的文件名,如果程序没有注意直接使用的话很有可能就把服务器的关键文件覆盖导致程序崩溃,甚至更有可能直接将 /etc/passwd 覆盖写上攻击者指定的密码从而攻破服务器。
有些同学可能会说了,/ 等字符是文件名非法字符,用户是定义不了这种名字的。你说的没错,但是我们要知道我们并不是直接和用户的文件进行交互的,而是通过 HTTP 请求拿到用户的文件。在 HTTP 表单上传请求中,文件名是作为字符串存储的。只要是合法的 HTTP 请求格式,攻击者可以构造请求中的任何内容用于提交给服务器。
POST /upload HTTP/1.1
Host: test.com
Connection: keep-alive
Content-Length: 4237161
Accept: */*
Origin: http://test.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (Khtml, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary9pQqgBGwpDfftP8l
Referer: http://test.com
Accept-Encoding: gzip, deflate
Accept-Language: en,zh-CN;q=0.9,zh;q=0.8,zh-TW;q=0.7,da;q=0.6
------WebKitFormBoundary9pQqgBGwpDfftP8l
Content-Disposition: form-data; name="file"; filename="../../attack.jpg"
Content-Type: image/jpeg
------WebKitFormBoundary9pQqgBGwpDfftP8l--
虽然说 Node.js 在文件上传服务端可执行程序的漏洞没有 PHP 那么高,但是除了服务端可执行之外我们还有客户端可执行问题,所以还是要做好防备。假设用户可以上传任意格式的文件,而如果攻击者上传了 HTML 文件后可以配合 CSRF 攻击进一步制造 XSS 攻击。
如果你是一个图片上传的接口,如果你仅限制 HTML 格式的话也存在问题,因为图片中有一种特别的存在是 SVG 格式。SVG 是一种矢量图形格式,它使用 XML 来描述图片,在其内部我们是可以插入 <html>, <style>, <script> 等 dom 标签的。如果不对 SVG 中的文件内容进行过滤的话,也会发生意想不到的效果。
<svg viewBox="0 0 100 100" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<script>alert(111)</script>
<rect x="25" y="25" width="50" height="50" />
</svg>
我们知道在操作系统中软链本质上也是一种文件,只是这个文件中不包含实际的内容,它包含另外一个文件的路径名。可以是任意文件或目录,可以链接不同文件系统的文件。如果攻击者上传了一个软链文件,软链描述对应的是 /etc/passwd 的话,攻击者利用程序可以直接读取到服务器的关键文件内容,导致服务器被攻陷。
除了文件本身的问题之外,还有一种情况我们需要考虑到的是文件上传之后的处理。如果我们将用户上传的文件存储到了本地,而没有限制用户的上传频率的话,就很有可能被攻击者利用。攻击者会频繁的上传文件导致服务器磁盘占用 100%,撑爆服务器之后没办法处理程序的其它任务进而导致服务器宕机。
针对以上几个可能出现的漏洞场景,我们需要做到以下几点:
需要额外提醒的是,如果用户上传的压缩包,程序有解压的行为,那么不仅要按照上述规则校验压缩包本身,还需要按照相同的逻辑校验解压之后的所有内容。同时针对服务器磁盘被撑爆的情况,推荐限制用户的上传频率降低风险,同时增加磁盘监控告警实时关注线上服务器的状态。如果存储到本地不是必须的话也可以使用外部存储服务来降低服务器这块的风险。
随着网络的普及,黑客进行网络攻击的手段越来也多,越来越复杂。前端的HTML、JavaScript、CSS、Flash等技术变成了前端攻击者和开发者的战场,网站安全问题也开始向前端倾斜。
AJAX请求真的不安全么?AJAX请求哪里不安全?怎么样让AJAX请求更安全?本文包含的内容较多,包括AJAX,CORS,XSS,CSRF等内容,要完整的看完并理解需要付出一定的时间。
第三方内容在其沙箱区域内具有强大的能力。如果你担心恶意用户诱使你的网站加载第三方资源,可以通过 CSP 用作防护手段,其可以限制加载图片,脚本和样式的来源。
检查页面隐藏或丢失的内容:检查webserver元数据文件,如:robots.txt, sitemap.xml,.DS_Store, .htaccess,检查搜索功能可能的注入或攻击方式,检查不同agent代理访问网站显示内容的是否一致
要做到无iFrame,我将使用一种类似于之前我讨论过的方法:我将创建一个弹窗,然后在设置计时器后更改弹出窗口的位置。使用这种方法,我仍然可以加载受害者的CSS,但我不再依赖于受害者是否允许iFrame。
我当前的 chrome 版本是 v68,如果是 v66 或更低版本可能提示的警告信息略有不同。印象中只对 CORS 比较熟悉,CORB 是个什么鬼?好奇心迫使我想要了解一下它到底是什么,于是暂时把手头工作放下查了一些资料并花时间汇总了一下,就有了这篇文章
大家都喜欢target=_blank, 因为新页面打开不影响原来的页面。但是这个存在安全问题, 由target=_blank打开的页面, 可以通过window.opener访问原来的窗口。遍可以简单的将网页导航到其他网站, 这就存在很多的安全隐患了, 比如钓鱼,这种问题解决起来也很简单, 在链接中加入rel=noreferrer noopener属性就可以了
Web安全测试检查单。上传功能:绕过文件上传检查功能,上传文件大小和次数限制。注册功能:注册请求是否安全传输,注册时密码复杂度是否后台检验,激活链接测试
HTTP Strict-Transport-Security,简称为HSTS。X-Frame-Options:是否允许一个页面可在<frame>、<iframe>、<object>中展现的标记。X-XSS-Protection作用:防范XSS攻击。
第三方内容在其沙箱中具有很高的影响力。 虽然图像或沙盒iframe有着非常小的沙箱,但脚本和样式的作用范围却影响你的整个页面,甚至是整个站点。如果你担心用户会欺骗你的网站去加载第三方资源,可以使用CSP(内容安全策略)保证安全
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!