1. 目录扫描的核心逻辑与应用场景很多人第一次接触目录扫描工具是在做网站安全测试或者服务器加固的时候。目标网站明明只开放了80端口怎么还能挖出后台地址答案往往就藏在一层层貌似无意义的URL路径里。所谓目录扫描简单说就是通过枚举的方式猜测Web服务器上可能存在但未公开的目录和文件再根据返回码、响应长度、页面特征来判断它们是否真实存在。dirsearch、御剑、Burp Suite里的Intruder模块背后干的事都是同一件把字典里的路径挨个请求一遍看哪个能命中。这里面最值得琢磨的不是工具本身而是“为什么能扫出来”。很多网站管理员觉得只要不在首页放链接别人就找不到后台。这个想法在实战里非常危险。开发者为了方便经常保留/admin、/backup、/phpmyadmin、/.git、/upload这样的默认路径或者把测试脚本临时扔在服务器上用完就忘。这类路径不会被搜索引擎收录也不会出现在站内导航里但它们真实存在且往往是权限最高的入口。目录扫描的价值就在这里它把“隐藏资产”暴露出来逼着管理员正视这些被遗忘的角落。对防守方来说这是自查前必须做的一个动作对测试方来说这是信息收集阶段最基础、也最有效率的一步。目录扫描工具的核心参数就那么几个目标URL、字典文件、线程数、延时、过滤规则、递归深度。看起来简单但不同的配置组合扫出来的结果可能天差地别。比如同一个站点用默认字典可能一无所获换一份包含参数和深层路径的字典可能立刻就有收获。这篇文章我会把dirsearch从安装到自定义字典、从结果分析到敏感文件识别的完整流程讲透也把御剑、Burp Suite爆破字典这些绕不开的话题放一起对比最后聊聊我实测中踩过的坑和排查思路。2. 工具选型dirsearch、御剑、Burp Suite各擅长什么2.1 dirsearch命令行里的全能扫描器dirsearch是近年使用率最高的目录扫描工具之一Python编写体积小、速度快、扩展灵活。它的特点可以概括为三点一是支持多线程默认就能开几十上百个并发效率远高于手工浏览二是自带一份相当不错的字典覆盖常见后台、备份文件、配置文件、日志路径等三是输出格式丰富可以保存成纯文本、JSON、CSV方便二次处理。用dirsearch时的常见姿势是这样的dirsearch -u https://target.com -e php,html,js这条命令的意思是对目标站点做目录枚举同时探测php、html、js这三种后缀文件。如果目标使用Nginx加PHP加-e php能直接发现index.php.bak、config.php.old这类备份文件。有人会问为什么要显式指定扩展名因为默认字典里大多数条目没有后缀只扫目录路径很容易漏掉同名的文件备份。比如字典里有config如果你加了-e php它会自动延伸出config.php、config.php.bak等组合。这个参数在实战里非常关键。dirsearch另一个好用的地方是有递归扫描能力。用-r开启递归后找到一个存在的目录它会继续在这个目录里跑一遍相同的字典。比如先扫出/admin递归后可能会进一步发现/admin/config.php。递归深度用--deep控制我一般控制在2到3层太深会拖慢速度而且很多深层路径价值不大。2.2 御剑目录扫描老牌图形化工具御剑是很多人的入门工具界面简单输入域名点一下“扫描”就能出结果。它最大的优势是无需命令行知识Windows下解压即用内置字典也比较贴近中文站点的习惯能扫出/dede、/wp-content、/data这类常见路径。缺点是线程模型不够透明对大站容易造成较大压力而且工具本身已经有几年没更新对现在很多站点使用的动态响应、状态码伪装策略稍显力不从心。如果你在Windows环境下只是快速验证一个目标御剑仍然是好用的。但如果你需要定制字典、控制并发、看请求细节还是得回到dirsearch这类命令行工具。我的建议是把御剑当作快速初筛把dirsearch当作深入探测。初筛结果能告诉你“这个站大概有哪些路子”深扫再告诉你“这些路子哪条能走通”。2.3 Burp Suite爆破字典不只是爆破很多人一提到Burp Suite里的字典就只想到Intruder爆破登录密码。其实在目录扫描这个场景里Burp的价值是让你能够精细控制请求顺序和线程并且完整看到每一次请求和响应的内容。Intruder的Sniper模式很适合跑一个字典列表Battering Ram模式则适合用同一条路径配不同Host头或不同Cookie。举个例子当你怀疑某个站点存在虚拟主机目录泄露但直接访问路径返回403你可以用Burp在请求里加上常见的X-Forwarded-For头或X-Real-IP头再看响应是否会变成200。这种基于请求头判断的扫描dirsearch也能通过--header参数实现但Burp的图形界面让你能更直观地对比每次响应差异调试header规则时尤其方便。2.4 三者如何配合使用我干活时的习惯是先用御剑或dirsearch默认字典快速扫一轮拿到一份初步结果然后根据初步结果在Burp里验证几个关键路径的返回差异最后再用dirsearch加载一份针对性的自定义字典做深度的递归扫描。这样三层配合既能覆盖广度又不放过深度。工具没有绝对的好坏关键看你在什么阶段用哪一把。3. dirsearch安装与常见问题从零到跑通3.1 在线安装与“unable to locate package dirsearch”的坑不少人在Debian或Ubuntu上执行sudo apt install dirsearch结果报错unable to locate package dirsearch。这其实是正常的因为很多发行版的软件源里根本没有打包dirsearch。碰到这个问题优先推荐用git clone方式安装git clone https://github.com/maurosoria/dirsearch.git cd dirsearch pip3 install -r requirements.txt然后运行python3 dirsearch.py -u https://target.com如果不想装Python依赖也可以用Docker方式但现在很多新版本直接python3 dirsearch.py就能跑依赖很少。还有一个小提示部分老教程里叫你用python3 dirsearch.py -u http://target.com --simple-reportout.txt这个参数在新版本里改成了--formatplain --outputout.txt看文档时要注意版本差异。3.2 手动安装的版本管理细节安装好之后建议先把工具自带字典瞄一眼。dirsearch的字典在db/dicc.txt实际使用的是db/dicc.txt配合拓展名生成组合。你可以直接修改这个文件也可以新建自己的字典文件然后用-w参数指定。我一般不改默认字典而是单独维护一份custom.txt避免工具升级时被覆盖。如果你用Kali情况就简单很多——Kali的软件源里自带dirsearch直接apt install dirsearch就能装上。不过Kali自带的版本可能不是最新的后面要用的某些新参数可能不支持。这种情况下建议还是git clone一套最新的到本地用的时候优先用最新版。3.3 常用参数速查与配置建议dirsearch参数比较多初学者容易看花眼。这里列几个我最常用的-u URL指定目标地址必须带协议头比如https://example.com。-e extensions追加扫描的扩展名逗号分隔。推荐php,html,txt,bak,old。-w wordlist指定自定义字典路径。-t threads线程数我一般设20到50目标带宽好可以更大。--delay每次请求之间的延时单位秒。担心对目标压力太大就设0.1或0.2。--random-agent随机User-Agent有些站点会对默认的Python UA做拦截。--recursive/-r递归扫描。--deep递归深度。--exclude-status排除指定状态码比如--exclude-status403,404减少干扰。--formatjson --outputresult.json保存结果。新手最容易犯的错是线程开太大导致目标服务器响应变慢甚至触发WAF封IP。这不是速度快就代表能力强目录扫描讲究的是“稳”。碰到WAF时我一般会把线程降到10以内打开--random-agent再加一个--delay0.5尽量让流量看起来像正常访问。3.4 安装后先跑一个本地靶场验证刚装完工具不建议直接去扫线上站点。可以先在本地用DVWA、sqli-labs、或一个简单的Nginx静态站点做测试。比如你在本机跑了一个Nginx里面放几个无链接的文件mkdir -p /var/www/html/admin echo test /var/www/html/admin/index.html echo config /var/www/html/backup.txt然后执行python3 dirsearch.py -u http://127.0.0.1/ -e txt --random-agent正常情况下你会在结果里看到/admin/和/backup.txt。如果连本地都扫不出来先排查网络、权限、Python版本再排查命令是否写对。这一步能帮你建立对工具输出的直觉后面分析线上结果时会快很多。4. 字典爆破从默认字典到自定义规则4.1 字典为什么是目录扫描的灵魂同样的dirsearch有人扫得出花有人扫了个寂寞区别九成在字典上。工具本身只是“发请求的机器”能不能发现敏感路径完全取决于你“问”了哪些路径。默认字典覆盖的是通用路径比如admin、login、backup、wp-admin等但每个站点的业务不同技术栈不同开发者的命名习惯也不同。一个纯Java站点你去跑PHP专属路径/wp-content自然什么都发现不了但如果你在字典里加了/actuator、/swagger-ui.html、/druid这类中间件路径结果就完全不同。所以我的做法是维护三份字典第一份是通用基础字典包含常见后台、管理路径、备份文件后缀第二份是技术栈字典按语言和框架划分比如/WEB-INF/web.xml、/.git/config、/server-status、/api/等第三份是业务字典从一个站点或一类业务中提取出来的自定义命名模式比如/tax/、/invoice/、/reports/。扫描时先用前两份做广撒网再用第三份做定向探测。4.2 如何构造一份合格的自定义字典构造字典不该是一味堆砌单词而是要理解目标站点的命名习惯。具体操作时我会关注这些点先看首页源码和JS文件里提到的接口路径整理成词条。比如页面里出现/api/user/info那我可以推断存在/api/admin、/api/config等。从已发现的路径反推。比如扫出/admin/login.html那就在字典里加入/admin、/admin/config、/admin/backup等组合。从robots.txt和历史快照里找线索。robots里Disallow的路径往往是管理员不想让人看到的但反而暴露了存在性。注意文件名规律。很多开发喜欢用backup_20240101.zip、web_old.tar.gz这种格式字典里可以加入backup、www、web加常见日期组合。一个简单实用的自定义字典示例假设是PHPMySQL的中文管理后台admin admin.php admin/login.php admin/backup.php admin/config.php manage manage/index.php system system/init.sql phpmyadmin phpmyadmin/index.php db db/backup.sql backup backup.zip backup.sql把这份字典存成custom.txt扫描时用-w custom.txt指定即可。虽然只有十几行但在特定场景下的命中率往往比几千行的通用字典还高。4.3 状态码与响应内容如何判断“扫到了”dirsearch扫描结果里最常见的状态码是200、301、302、403、500偶尔还有401。很多新手看到200就兴奋看到403就叹气其实都不绝对。一个很常见的场景某些站点的路径不存在时不返回404而是统一返回200首页内容或空内容。如果你单纯看状态码会把一堆无效路径当成存在。这时候就要看响应长度。dirsearch默认会把相同长度的200响应折叠起来并且有--min-response-size之类的参数帮你过滤。我通常会打开-i 200加--full-url看具体URL然后抓几个响应body做对比如果body都是同一个模板那基本就是伪200。反过来403也不是完全没价值。403表示服务器理解了请求但拒绝访问这说明路径本身是存在的只是当前用户没有权限。这时候可以换一个思路用Burp改Referer、改Header或者直接测试路径的大小写变体有时能绕过限制拿到内容。所以看到403别急着忽视先记录后面验证。4.4 递归不等于一直扫到底递归扫描是个好功能但也容易被滥用。很多初学者开-r --deep5对一个大站扫上一晚上最后得到几千条结果反而分不清重点。我的经验是先跑一遍非递归扫描找出所有目录然后只对其中跟管理、备份、上传、api相关的目录做递归。这样既不会漏掉关键的深层路径也不会被无效信息淹没。5. 敏感目录与敏感文件泄露到底在挖什么5.1 哪些文件泄露最致命通过目录扫描发现的路径里有些是“只要存在就很高危”的。这里列几个典型的你自查的时候也可以对照着查.git目录如果可以通过/.git/config访问说明整个项目源码很可能已经泄露。攻击者可以用工具把代码仓库拉下来代码审计之后找漏洞的难度会直线下降。/WEB-INF/web.xmlJava或/appsettings.json.NET这类配置文件里常常藏着数据库连接串、第三方密钥、内部接口地址。/backup、*.zip、*.sql备份文件一旦被下载整个数据库内容就等于裸奔。/phpmyadmin、/adminer数据库管理面板在线如果口令还弱后果不用多说。日志文件/logs、/error.log里可能记录了报错信息、真实路径、SQL语句帮助攻击者进一步构造攻击。上传目录/upload、/uploads、/files如果能列出目录可以看到用户上传的文件有些站点还会把隐私文件传上去。5.2 如何判断敏感文件的价值目录扫描结果里会出现一大批路径不可能每个都去深入测。我一般先按文件类型筛选优先看压缩包、sql文件、配置文件、文档其次看目录。然后再看状态码和响应长度有没有异样。比如/backup.zip返回200长度是几十MB那不用犹豫基本可以确认是备份文件。此时作为防守方第一件事应该是把文件移出Web目录同时检查服务器日志看是否已经有人访问过。5.3 扫描之后的验证与报告生成扫描工具只能告诉你“路径存在”不能告诉你“路径能利用”。所以拿到结果后我会用curl逐个验证关键路径的响应头、Content-Type和实际内容。响应头里的Server、X-Powered-By能暴露技术栈Content-Type如果是application/octet-stream说明是下载文件如果返回HTML再抓body看是什么页面。验证完以后把结果整理成表格按风险等级排序。给管理员写报告时不仅仅要列路径还要写清楚“这一个路径暴露了什么信息可能导致什么风险如何修复”。比如.git泄露的修复方案是删除web目录下的.git文件夹同时配置Web服务器禁止访问点开头文件备份文件的修复方案是迁移到非Web目录并调整访问权限。6. 常见问题与排查技巧实录6.1 dirsearch命令扫不出任何结果怎么办这是被问得最多的问题。如果你确定目标没有问题先检查这几点是否加了http://或https://。漏掉协议头工具会直接报错或转成莫名其妙的结果。目标是否有WAF拦截。试着加--random-agent并降低线程数。字典是否合适。默认字典对中文站点的覆盖有限换成自定义字典再试。出口IP是否被封。如果有条件换一个网络环境验证。是否使用了代理。dirsearch支持--proxy参数如果你本机有代理需要设置否则请求可能一直发不出去。有一次我扫一个站点怎么扫都是403用浏览器打开首页又正常。排查后发现是目标对默认的Python User-Agent做了封禁加上--random-agent之后立刻恢复正常。这提醒我目录扫描时不能只看路径还要看请求头是否被识别。6.2 状态码全部200无法区分是否命中前面提过这种“伪200”的情况这里讲下处理细节。当路径不存在也返回200时dirsearch的过滤规则就要起作用了。先用非递归模式扫一批然后查看响应长度分布。真实页面的响应长度一般会有明显差异比如首页20KB后台也20KB而错误页只有几百字节。这时候可以利用--min-response-size过滤掉过小的响应或者用--exclude-size排除特定长度。还有一些站点会返回一个固定的重定向页面状态码也是200这种可以用--exclude-status结合--exclude-text排除包含某些关键词的响应。6.3 扫描速度很慢如何优化线程和延时线程不是越大越好。你要先看目标服务器的响应时间。比如某个页面平均响应是200毫秒开20个线程大约每秒能发100个请求对普通Nginx不算压力但如果页面平均响应要1秒开50个线程也很容易把服务器拖到超时。建议先小线程跑一会观察稳定性和结果变化再逐步加大。另外扫描时不要对同一目标同时跑多个工具多个扫描器叠加反而容易触发防护。我一般只用一个工具做深度扫描偶尔用Burp手动补几个测例。6.4 分块大小与扫描时间估算很多工具在扫描时会告诉你进度条和剩余时间但这个预估不可靠。字典条目数乘以并发数只是理论时间实际还受网络、目标响应速度影响。我假设一个场景字典有5000条线程30平均每个请求耗时300毫秒那么每秒能完成约100个请求30线程每个1/0.3秒约3个请求总耗时约50秒。如果目标响应变慢耗时可能翻倍。心里有这笔账你就知道为什么有时候跑一个中等字典要几分钟也能判断出是不是网络卡住了。6.5 扫描被防火墙拦截怎么绕而不失礼这可能是实操里最敏感的一问但站在防守方角度我们也可以理解为“如何让自查流量更温和”。首先要明确一切测试行为都要在授权范围内。在这个前提下如果你自己的测试流量被自己的WAF拦截了通常可以这样调整放缓节奏把线程降到5加--delay1让请求频率与普通用户接近。随机化User-Agent避免明显的扫描器特征。减少一次扫描的目标范围比如只扫根目录不扫所有目录。使用更贴近业务的路径字典而不是全网通用的大字典减少无意义请求。曾经有个项目我这边跑dirsearch没几分钟就被对方安全设备封了IP后来改了策略用Burp的Intruder配合少量手工构造请求分时段慢慢测才把预期结果拿到。这件事让我明白目录扫描拼的不是跑得快而是跑得巧。7. 一点实际经验与后续扩展思路从最初在Windows下点御剑到现在日常用dirsearch配合自定义字典我个人最大的体会是工具永远只是放大器真正决定扫描效果的是你对目标的理解程度。你越清楚一个站点用什么框架、有什么习惯、哪些目录可能被遗忘你的字典就越精准扫描结果就越有价值。相反拿着一份万年不变的通用字典去扫所有目标大概率只能得到一堆无关信息。我在实际项目中养成的习惯是每次扫描前先在本地把目标的技术栈和入口梳理一遍把关键词提取出来写进临时字典。扫完之后再根据结果反推重新整理字典扫第二遍。这两轮下来基本能把站点的主要敏感目录摸清。后面还可以把这个过程沉淀成一套自己的字典库每次遇到同类型站点直接套用速度会快很多。最后分享一个小技巧dirsearch扫出来的结果不要只保存在屏幕输出里。养成每次扫描都用--formatjson --outputresult_目标名_日期.json存一份的习惯。后面写报告、对比历史变化、复盘漏洞结构这些结构化记录会省你很多事。目录扫描只是整个安全评估流程的起点但它能决定你后面是打在有意义的方向上还是在浪费时间。把这一步做扎实后面的路会顺很多。 
长河君 · 2026/9/14 18:15:49 · 阅读 1.2k 目录扫描核心原理与dirsearch实战指南
1. 目录扫描的核心逻辑与应用场景很多人第一次接触目录扫描工具是在做网站安全测试或者服务器加固的时候。目标网站明明只开放了80端口怎么还能挖出后台地址答案往往就藏在一层层貌似无意义的URL路径里。所谓目录扫描简单说就是通过枚举的方式猜测Web服务器上可能存在但未公开的目录和文件再根据返回码、响应长度、页面特征来判断它们是否真实存在。dirsearch、御剑、Burp Suite里的Intruder模块背后干的事都是同一件把字典里的路径挨个请求一遍看哪个能命中。这里面最值得琢磨的不是工具本身而是“为什么能扫出来”。很多网站管理员觉得只要不在首页放链接别人就找不到后台。这个想法在实战里非常危险。开发者为了方便经常保留/admin、/backup、/phpmyadmin、/.git、/upload这样的默认路径或者把测试脚本临时扔在服务器上用完就忘。这类路径不会被搜索引擎收录也不会出现在站内导航里但它们真实存在且往往是权限最高的入口。目录扫描的价值就在这里它把“隐藏资产”暴露出来逼着管理员正视这些被遗忘的角落。对防守方来说这是自查前必须做的一个动作对测试方来说这是信息收集阶段最基础、也最有效率的一步。目录扫描工具的核心参数就那么几个目标URL、字典文件、线程数、延时、过滤规则、递归深度。看起来简单但不同的配置组合扫出来的结果可能天差地别。比如同一个站点用默认字典可能一无所获换一份包含参数和深层路径的字典可能立刻就有收获。这篇文章我会把dirsearch从安装到自定义字典、从结果分析到敏感文件识别的完整流程讲透也把御剑、Burp Suite爆破字典这些绕不开的话题放一起对比最后聊聊我实测中踩过的坑和排查思路。2. 工具选型dirsearch、御剑、Burp Suite各擅长什么2.1 dirsearch命令行里的全能扫描器dirsearch是近年使用率最高的目录扫描工具之一Python编写体积小、速度快、扩展灵活。它的特点可以概括为三点一是支持多线程默认就能开几十上百个并发效率远高于手工浏览二是自带一份相当不错的字典覆盖常见后台、备份文件、配置文件、日志路径等三是输出格式丰富可以保存成纯文本、JSON、CSV方便二次处理。用dirsearch时的常见姿势是这样的dirsearch -u https://target.com -e php,html,js这条命令的意思是对目标站点做目录枚举同时探测php、html、js这三种后缀文件。如果目标使用Nginx加PHP加-e php能直接发现index.php.bak、config.php.old这类备份文件。有人会问为什么要显式指定扩展名因为默认字典里大多数条目没有后缀只扫目录路径很容易漏掉同名的文件备份。比如字典里有config如果你加了-e php它会自动延伸出config.php、config.php.bak等组合。这个参数在实战里非常关键。dirsearch另一个好用的地方是有递归扫描能力。用-r开启递归后找到一个存在的目录它会继续在这个目录里跑一遍相同的字典。比如先扫出/admin递归后可能会进一步发现/admin/config.php。递归深度用--deep控制我一般控制在2到3层太深会拖慢速度而且很多深层路径价值不大。2.2 御剑目录扫描老牌图形化工具御剑是很多人的入门工具界面简单输入域名点一下“扫描”就能出结果。它最大的优势是无需命令行知识Windows下解压即用内置字典也比较贴近中文站点的习惯能扫出/dede、/wp-content、/data这类常见路径。缺点是线程模型不够透明对大站容易造成较大压力而且工具本身已经有几年没更新对现在很多站点使用的动态响应、状态码伪装策略稍显力不从心。如果你在Windows环境下只是快速验证一个目标御剑仍然是好用的。但如果你需要定制字典、控制并发、看请求细节还是得回到dirsearch这类命令行工具。我的建议是把御剑当作快速初筛把dirsearch当作深入探测。初筛结果能告诉你“这个站大概有哪些路子”深扫再告诉你“这些路子哪条能走通”。2.3 Burp Suite爆破字典不只是爆破很多人一提到Burp Suite里的字典就只想到Intruder爆破登录密码。其实在目录扫描这个场景里Burp的价值是让你能够精细控制请求顺序和线程并且完整看到每一次请求和响应的内容。Intruder的Sniper模式很适合跑一个字典列表Battering Ram模式则适合用同一条路径配不同Host头或不同Cookie。举个例子当你怀疑某个站点存在虚拟主机目录泄露但直接访问路径返回403你可以用Burp在请求里加上常见的X-Forwarded-For头或X-Real-IP头再看响应是否会变成200。这种基于请求头判断的扫描dirsearch也能通过--header参数实现但Burp的图形界面让你能更直观地对比每次响应差异调试header规则时尤其方便。2.4 三者如何配合使用我干活时的习惯是先用御剑或dirsearch默认字典快速扫一轮拿到一份初步结果然后根据初步结果在Burp里验证几个关键路径的返回差异最后再用dirsearch加载一份针对性的自定义字典做深度的递归扫描。这样三层配合既能覆盖广度又不放过深度。工具没有绝对的好坏关键看你在什么阶段用哪一把。3. dirsearch安装与常见问题从零到跑通3.1 在线安装与“unable to locate package dirsearch”的坑不少人在Debian或Ubuntu上执行sudo apt install dirsearch结果报错unable to locate package dirsearch。这其实是正常的因为很多发行版的软件源里根本没有打包dirsearch。碰到这个问题优先推荐用git clone方式安装git clone https://github.com/maurosoria/dirsearch.git cd dirsearch pip3 install -r requirements.txt然后运行python3 dirsearch.py -u https://target.com如果不想装Python依赖也可以用Docker方式但现在很多新版本直接python3 dirsearch.py就能跑依赖很少。还有一个小提示部分老教程里叫你用python3 dirsearch.py -u http://target.com --simple-reportout.txt这个参数在新版本里改成了--formatplain --outputout.txt看文档时要注意版本差异。3.2 手动安装的版本管理细节安装好之后建议先把工具自带字典瞄一眼。dirsearch的字典在db/dicc.txt实际使用的是db/dicc.txt配合拓展名生成组合。你可以直接修改这个文件也可以新建自己的字典文件然后用-w参数指定。我一般不改默认字典而是单独维护一份custom.txt避免工具升级时被覆盖。如果你用Kali情况就简单很多——Kali的软件源里自带dirsearch直接apt install dirsearch就能装上。不过Kali自带的版本可能不是最新的后面要用的某些新参数可能不支持。这种情况下建议还是git clone一套最新的到本地用的时候优先用最新版。3.3 常用参数速查与配置建议dirsearch参数比较多初学者容易看花眼。这里列几个我最常用的-u URL指定目标地址必须带协议头比如https://example.com。-e extensions追加扫描的扩展名逗号分隔。推荐php,html,txt,bak,old。-w wordlist指定自定义字典路径。-t threads线程数我一般设20到50目标带宽好可以更大。--delay每次请求之间的延时单位秒。担心对目标压力太大就设0.1或0.2。--random-agent随机User-Agent有些站点会对默认的Python UA做拦截。--recursive/-r递归扫描。--deep递归深度。--exclude-status排除指定状态码比如--exclude-status403,404减少干扰。--formatjson --outputresult.json保存结果。新手最容易犯的错是线程开太大导致目标服务器响应变慢甚至触发WAF封IP。这不是速度快就代表能力强目录扫描讲究的是“稳”。碰到WAF时我一般会把线程降到10以内打开--random-agent再加一个--delay0.5尽量让流量看起来像正常访问。3.4 安装后先跑一个本地靶场验证刚装完工具不建议直接去扫线上站点。可以先在本地用DVWA、sqli-labs、或一个简单的Nginx静态站点做测试。比如你在本机跑了一个Nginx里面放几个无链接的文件mkdir -p /var/www/html/admin echo test /var/www/html/admin/index.html echo config /var/www/html/backup.txt然后执行python3 dirsearch.py -u http://127.0.0.1/ -e txt --random-agent正常情况下你会在结果里看到/admin/和/backup.txt。如果连本地都扫不出来先排查网络、权限、Python版本再排查命令是否写对。这一步能帮你建立对工具输出的直觉后面分析线上结果时会快很多。4. 字典爆破从默认字典到自定义规则4.1 字典为什么是目录扫描的灵魂同样的dirsearch有人扫得出花有人扫了个寂寞区别九成在字典上。工具本身只是“发请求的机器”能不能发现敏感路径完全取决于你“问”了哪些路径。默认字典覆盖的是通用路径比如admin、login、backup、wp-admin等但每个站点的业务不同技术栈不同开发者的命名习惯也不同。一个纯Java站点你去跑PHP专属路径/wp-content自然什么都发现不了但如果你在字典里加了/actuator、/swagger-ui.html、/druid这类中间件路径结果就完全不同。所以我的做法是维护三份字典第一份是通用基础字典包含常见后台、管理路径、备份文件后缀第二份是技术栈字典按语言和框架划分比如/WEB-INF/web.xml、/.git/config、/server-status、/api/等第三份是业务字典从一个站点或一类业务中提取出来的自定义命名模式比如/tax/、/invoice/、/reports/。扫描时先用前两份做广撒网再用第三份做定向探测。4.2 如何构造一份合格的自定义字典构造字典不该是一味堆砌单词而是要理解目标站点的命名习惯。具体操作时我会关注这些点先看首页源码和JS文件里提到的接口路径整理成词条。比如页面里出现/api/user/info那我可以推断存在/api/admin、/api/config等。从已发现的路径反推。比如扫出/admin/login.html那就在字典里加入/admin、/admin/config、/admin/backup等组合。从robots.txt和历史快照里找线索。robots里Disallow的路径往往是管理员不想让人看到的但反而暴露了存在性。注意文件名规律。很多开发喜欢用backup_20240101.zip、web_old.tar.gz这种格式字典里可以加入backup、www、web加常见日期组合。一个简单实用的自定义字典示例假设是PHPMySQL的中文管理后台admin admin.php admin/login.php admin/backup.php admin/config.php manage manage/index.php system system/init.sql phpmyadmin phpmyadmin/index.php db db/backup.sql backup backup.zip backup.sql把这份字典存成custom.txt扫描时用-w custom.txt指定即可。虽然只有十几行但在特定场景下的命中率往往比几千行的通用字典还高。4.3 状态码与响应内容如何判断“扫到了”dirsearch扫描结果里最常见的状态码是200、301、302、403、500偶尔还有401。很多新手看到200就兴奋看到403就叹气其实都不绝对。一个很常见的场景某些站点的路径不存在时不返回404而是统一返回200首页内容或空内容。如果你单纯看状态码会把一堆无效路径当成存在。这时候就要看响应长度。dirsearch默认会把相同长度的200响应折叠起来并且有--min-response-size之类的参数帮你过滤。我通常会打开-i 200加--full-url看具体URL然后抓几个响应body做对比如果body都是同一个模板那基本就是伪200。反过来403也不是完全没价值。403表示服务器理解了请求但拒绝访问这说明路径本身是存在的只是当前用户没有权限。这时候可以换一个思路用Burp改Referer、改Header或者直接测试路径的大小写变体有时能绕过限制拿到内容。所以看到403别急着忽视先记录后面验证。4.4 递归不等于一直扫到底递归扫描是个好功能但也容易被滥用。很多初学者开-r --deep5对一个大站扫上一晚上最后得到几千条结果反而分不清重点。我的经验是先跑一遍非递归扫描找出所有目录然后只对其中跟管理、备份、上传、api相关的目录做递归。这样既不会漏掉关键的深层路径也不会被无效信息淹没。5. 敏感目录与敏感文件泄露到底在挖什么5.1 哪些文件泄露最致命通过目录扫描发现的路径里有些是“只要存在就很高危”的。这里列几个典型的你自查的时候也可以对照着查.git目录如果可以通过/.git/config访问说明整个项目源码很可能已经泄露。攻击者可以用工具把代码仓库拉下来代码审计之后找漏洞的难度会直线下降。/WEB-INF/web.xmlJava或/appsettings.json.NET这类配置文件里常常藏着数据库连接串、第三方密钥、内部接口地址。/backup、*.zip、*.sql备份文件一旦被下载整个数据库内容就等于裸奔。/phpmyadmin、/adminer数据库管理面板在线如果口令还弱后果不用多说。日志文件/logs、/error.log里可能记录了报错信息、真实路径、SQL语句帮助攻击者进一步构造攻击。上传目录/upload、/uploads、/files如果能列出目录可以看到用户上传的文件有些站点还会把隐私文件传上去。5.2 如何判断敏感文件的价值目录扫描结果里会出现一大批路径不可能每个都去深入测。我一般先按文件类型筛选优先看压缩包、sql文件、配置文件、文档其次看目录。然后再看状态码和响应长度有没有异样。比如/backup.zip返回200长度是几十MB那不用犹豫基本可以确认是备份文件。此时作为防守方第一件事应该是把文件移出Web目录同时检查服务器日志看是否已经有人访问过。5.3 扫描之后的验证与报告生成扫描工具只能告诉你“路径存在”不能告诉你“路径能利用”。所以拿到结果后我会用curl逐个验证关键路径的响应头、Content-Type和实际内容。响应头里的Server、X-Powered-By能暴露技术栈Content-Type如果是application/octet-stream说明是下载文件如果返回HTML再抓body看是什么页面。验证完以后把结果整理成表格按风险等级排序。给管理员写报告时不仅仅要列路径还要写清楚“这一个路径暴露了什么信息可能导致什么风险如何修复”。比如.git泄露的修复方案是删除web目录下的.git文件夹同时配置Web服务器禁止访问点开头文件备份文件的修复方案是迁移到非Web目录并调整访问权限。6. 常见问题与排查技巧实录6.1 dirsearch命令扫不出任何结果怎么办这是被问得最多的问题。如果你确定目标没有问题先检查这几点是否加了http://或https://。漏掉协议头工具会直接报错或转成莫名其妙的结果。目标是否有WAF拦截。试着加--random-agent并降低线程数。字典是否合适。默认字典对中文站点的覆盖有限换成自定义字典再试。出口IP是否被封。如果有条件换一个网络环境验证。是否使用了代理。dirsearch支持--proxy参数如果你本机有代理需要设置否则请求可能一直发不出去。有一次我扫一个站点怎么扫都是403用浏览器打开首页又正常。排查后发现是目标对默认的Python User-Agent做了封禁加上--random-agent之后立刻恢复正常。这提醒我目录扫描时不能只看路径还要看请求头是否被识别。6.2 状态码全部200无法区分是否命中前面提过这种“伪200”的情况这里讲下处理细节。当路径不存在也返回200时dirsearch的过滤规则就要起作用了。先用非递归模式扫一批然后查看响应长度分布。真实页面的响应长度一般会有明显差异比如首页20KB后台也20KB而错误页只有几百字节。这时候可以利用--min-response-size过滤掉过小的响应或者用--exclude-size排除特定长度。还有一些站点会返回一个固定的重定向页面状态码也是200这种可以用--exclude-status结合--exclude-text排除包含某些关键词的响应。6.3 扫描速度很慢如何优化线程和延时线程不是越大越好。你要先看目标服务器的响应时间。比如某个页面平均响应是200毫秒开20个线程大约每秒能发100个请求对普通Nginx不算压力但如果页面平均响应要1秒开50个线程也很容易把服务器拖到超时。建议先小线程跑一会观察稳定性和结果变化再逐步加大。另外扫描时不要对同一目标同时跑多个工具多个扫描器叠加反而容易触发防护。我一般只用一个工具做深度扫描偶尔用Burp手动补几个测例。6.4 分块大小与扫描时间估算很多工具在扫描时会告诉你进度条和剩余时间但这个预估不可靠。字典条目数乘以并发数只是理论时间实际还受网络、目标响应速度影响。我假设一个场景字典有5000条线程30平均每个请求耗时300毫秒那么每秒能完成约100个请求30线程每个1/0.3秒约3个请求总耗时约50秒。如果目标响应变慢耗时可能翻倍。心里有这笔账你就知道为什么有时候跑一个中等字典要几分钟也能判断出是不是网络卡住了。6.5 扫描被防火墙拦截怎么绕而不失礼这可能是实操里最敏感的一问但站在防守方角度我们也可以理解为“如何让自查流量更温和”。首先要明确一切测试行为都要在授权范围内。在这个前提下如果你自己的测试流量被自己的WAF拦截了通常可以这样调整放缓节奏把线程降到5加--delay1让请求频率与普通用户接近。随机化User-Agent避免明显的扫描器特征。减少一次扫描的目标范围比如只扫根目录不扫所有目录。使用更贴近业务的路径字典而不是全网通用的大字典减少无意义请求。曾经有个项目我这边跑dirsearch没几分钟就被对方安全设备封了IP后来改了策略用Burp的Intruder配合少量手工构造请求分时段慢慢测才把预期结果拿到。这件事让我明白目录扫描拼的不是跑得快而是跑得巧。7. 一点实际经验与后续扩展思路从最初在Windows下点御剑到现在日常用dirsearch配合自定义字典我个人最大的体会是工具永远只是放大器真正决定扫描效果的是你对目标的理解程度。你越清楚一个站点用什么框架、有什么习惯、哪些目录可能被遗忘你的字典就越精准扫描结果就越有价值。相反拿着一份万年不变的通用字典去扫所有目标大概率只能得到一堆无关信息。我在实际项目中养成的习惯是每次扫描前先在本地把目标的技术栈和入口梳理一遍把关键词提取出来写进临时字典。扫完之后再根据结果反推重新整理字典扫第二遍。这两轮下来基本能把站点的主要敏感目录摸清。后面还可以把这个过程沉淀成一套自己的字典库每次遇到同类型站点直接套用速度会快很多。最后分享一个小技巧dirsearch扫出来的结果不要只保存在屏幕输出里。养成每次扫描都用--formatjson --outputresult_目标名_日期.json存一份的习惯。后面写报告、对比历史变化、复盘漏洞结构这些结构化记录会省你很多事。目录扫描只是整个安全评估流程的起点但它能决定你后面是打在有意义的方向上还是在浪费时间。把这一步做扎实后面的路会顺很多。