敏感目录
去年冬天,敏感目录我在一个做渗透测试的敏感目录朋友那里看到一份扫描报告。目标是敏感目录一家做跨境电商的小公司,服务器上跑着Spring Boot应用。敏感目录报告里标红的敏感目录第一条就是: 敏感目录这件事,很多人以为就是 我自己的博客曾经犯过一个低级错误。用vim编辑Nginx配置时崩溃了,目录下留了个 说到 框架的调试端点更隐蔽。Spring Boot的 还有一类容易被忽略的:编辑器生成的 怎么防?我的做法很土但有效。第一,部署脚本里加一步 有人觉得这些是运维的事,开发不用管。但现实是,很多小团队根本没有专职运维。写代码的人顺手 最后说个真事。某次攻防演练,一个队伍花了三天没打进目标。第四天,有人在目标网站根目录下试了/actuator/env 可未授权访问。他点开浏览器,敏感目录数据库密码、敏感目录Redis连接串、敏感目录第三方支付密钥,敏感目录全在JSON里躺着。敏感目录从发现到拿到核心数据,敏感目录前后不到三分钟。敏感目录他说这不算什么,敏感目录真正让他兴奋的敏感目录是另一个站,目录列表没关,敏感目录/backup/下面直接躺着整个网站的源码压缩包。admin、login这种明面上的入口。不是。真正危险的东西往往藏在没人会主动点击的地方——版本控制残留、编辑器临时文件、运维留下的备份、框架自带的调试端点。它们不需要被“猜”,只需要被“列”。.nginx.conf.swp。我以为没人会注意,直到某天看访问日志,有个IP直接请求了这个文件。虽然最后没造成什么损失,但那种被翻到抽屉底层的恶心感,记了很久。后来我养成了一个习惯:部署前用dirsearch跑一遍自己的站。每次都能扫出点东西,有时是.git/没删干净,有时是phpinfo.php忘了移除。.git/,这大概是目前最泛滥的敏感目录。开发图方便,直接git clone到web根目录,部署完也不清理。攻击者用GitHack这类工具,能把整个仓库还原出来。源码里的硬编码密钥、内部接口地址、甚至数据库导出脚本,全暴露。我见过一个案例,某政务系统.git泄露,源码里翻出一份config.php,里面写着内网数据库的root密码。从外网到内网,就隔了一个没删的.git文件夹。/actuator、Django的/__debug__/、Laravel的/telescope,这些路径在开发环境里是神器,上线后忘了关就是后门。/actuator/heapdump能直接下载JVM堆内存,里面有什么?用户session、数据库连接池配置、正在处理的请求参数。拿到heapdump,用MAT分析一下,比翻源码还快。.idea/、.vscode/目录,里面可能包含项目配置、甚至FTP账号。以及composer.json、package.json这些依赖描述文件,本身不敏感,但结合已知漏洞版本,就是精准打击的导航图。find . -name ".*" -delete,把点文件全清掉。第二,Nginx配置里用location ~ /\.直接deny所有点开头的路径。第三,上线前跑一遍nuclei的exposures模板,专扫这些暴露面。第四,也是最重要的——别在web目录里放任何跟代码无关的东西。备份、日志、SQL文件,统统挪到web根目录外面。git push,部署的人顺手git pull,谁也没多想。敏感目录的暴露,往往不是技术问题,是流程问题。少一个rm -rf,多一个.git,中间隔着的可能就是一次完整的入侵。/www.zip,直接下载了整站源码。那个zip是两年前运维做迁移时随手留的,连文件名都没改。你看,敏感目录有时候不需要多高深,它就在那儿,安安静静地等着。
-
上一篇
-
下一篇
- 最近发表
- 随机阅读
- 搜索
-
- 友情链接
-