企业官网建设流程全解析

很多朋友做授权范围内的Web安全检查时，把AWVS一装、目标地址一填，就直接点Scan。等报告跑完拉到列表一看，几十条漏洞全是登录页面上的东西，扫来扫去只见一个首页和一个login.html，后台业务模块一个没进。这种情况十有八九是登录扫描没配好，AWVS爬虫根本没拿到有效会话，整个扫描等于在门外转圈。

AWVS里所谓的“3种登录方式”，其实是指三种把身份凭据交给扫描器的方式：Cookie登录、表单认证登录、录制登录。三种方式看起来只是入口不同，但背后的会话保持机制、适用场景、踩坑点完全不一样。这篇就按我实际拿授权目标反复测试的经验，把三种方式的操作步骤、配置细节和翻车现场整理一遍，顺便把登录验证器、扫描范围、账号保护这些最容易忽略的环节讲透。

1. 登录扫描的价值与方式选型

1.1 为什么不能跳过登录扫描

可以把Web扫描器理解成一个带探测器的爬虫，它沿着链接爬、按照表单提交、顺着请求翻页面，能走到哪里就在哪里做检测。如果扫描器拿不到登录态，它就永远停留在公开可见的那一层：登录页、注册页、静态资源、少数几个未授权接口。可真正藏问题的功能，在登录之后：后台管理、订单流程、用户中心、文件上传、配置变更。这些页面要么没有直接链接入口，要么没有会话就返回302到登录页。

在AWVS里不配置登录而直接扫描，本质上是“只看锁没锁门，不看保险柜里有没有少钱”。登录扫描的价值不仅仅是多几个页面，而是让安全检测回归到真实使用者的视角：一个正常用户能操作的功能，安全检测同样需要去模拟。所以我每次做授权检测，第一件事就是想清楚被测系统的登录方式，再决定用哪种方式接入扫描器，而不是一上来就全站扫描。

1.2 三种登录方式的对比与选型逻辑

AWVS登录设置界面里，一般能看到多个登录选项。我习惯按下面的思路来分：

选型逻辑没那么玄学：传统后台管理、企业站点这类表单登录很规矩的，直接用表单认证最省事；SPA和前后端分离项目，Cookie是最直接的；一旦登录页出现验证码或各种动态校验，就别硬撑着用表单方式，老老实实录制登录。顺序上，我建议优先评估表单、再考虑Cookie、最后上录制，因为录制方式虽然万能，但出问题的隐蔽性也最高。

2. 通用配置入口与登录验证器

2.1 目标添加与访问设置

在开始三种方式的细节之前，先看清AWVS的配置入口。添加目标时，常规操作是：Targets → Add Target，填写被测系统的URL。这里有一个容易被忽略的选项——访问URL时使用的协议和端口，以及目标站点是否需要特殊Header。

很多站点在登录之前先做一次跳转，或者需要指定Host头，这种情况下如果不在目标设置里提前声明，后面无论用哪种登录方式，扫描器拿到的页面都是错的。我曾经遇到一个目标，登录页地址能正常打开，但提交登录请求时服务端校验了Host头，结果AWVS回放登录脚本时总是收到400，排查了半天才发现是目标配置里少了自定义Header。所以第一节课是：在配置登录之前，先确认目标基础访问是通的，让爬虫能成功抓取登录页面，再去谈登录会话的问题。

在目标的General面板里，有的版本还有All in One Scan选项，把爬虫、漏洞检测、网页攻击全部一次性跑。对于登录配置还不太确定的情况，我不建议直接跑All in One，而是先跑一次仅爬取（Crawl Only），确认爬虫确实进入了登录后的页面，再补一次完整扫描。这样做的好处是能快速验证登录是否成功，避免一次全量扫描浪费数小时。

2.2 登录验证器：判断登录是否成功的唯一标准

登录验证器（Login Verifier）是整个登录扫描里最核心的判断机制。它的作用是告诉AWVS：当前这个请求响应，到底算“登录成功”还是“没登录上”。验证器可以是一个URL、一段文本、一个正则表达式，也可以按响应状态码来判断。

我见过很多次配置表单登录方式时，账号密码填了、登录URL填了，却随便选了一个验证器，结果扫描器误以为登录失败，直接把所有请求当成匿名用户处理。验证器的选择标准是：选一段只出现在登录成功后才可见的文本，比如后台的“欢迎，管理员”、用户中心里的“账号余额”，或者干脆是登录后才跳转到的仪表盘URL。

选验证器有一个反直觉的点，很多人喜欢选“登录失败时出现的错误提示”，然后在验证逻辑里做反向判断，这种做法在AWVS里并不总是可靠。最好还是正向选择：成功页面上的唯一标识。如果成功页面是动态内容、每次都不一样，那就用正则匹配文本，或者用登录成功后的固定URL做匹配。记住一个原则：验证器不是可有可无的装饰，它直接决定扫描器脚下踩的是不是实心地面。

3. Cookie登录方式实操与避坑

3.1 拿到Cookie的两种姿势

Cookie登录方式的第一步，是先拿到一套真实有效的会话Cookie。最常见的做法是用浏览器登录目标系统，打开开发者工具，在Network面板里找到任意一个登录后的请求，复制请求头里的Cookie字段。这里必须注意：现在很多系统种了多个Cookie，比如会话标识、偏好设置、追踪标识混在一起，不要只复制其中一小段，尽量把当前域下所有Cookie一起交给扫描器。

第二种做法是在命令行里用工具模拟登录，抓取响应的Set-Cookie，然后整理成Cookie填入AWVS。这种做法对后端接口测试更友好，尤其在SPA项目里，前端登录逻辑比较复杂，但接口层面只需要一个Authorization或Session ID时，命令行抓Cookie反而更干净。

拿到Cookie之后，在AWVS的登录设置里找到Cookie相关的Tab页，把Cookie按名称和值逐行填入。如果之前已经选了表单认证方式，需要切换到Cookie方式，避免两套凭据同时生效造成混乱。填完之后，登录验证器依然要配置，它负责判断“这个Cookie是不是已经被判定为有效”。

3.2 Cookie方式配置的现场记录

我以某个前后端分离的目标站点为例，完整跑一遍Cookie方式的操作：

1. 先用带调试工具的浏览器，登录目标站点后台。
2. 打开F12的Network面板，找到登录成功后的某个API请求。
3. 从请求头里复制整个Cookie字符串，形如“session_id=abc123; theme=dark; user_type=admin”。
4. 在AWVS目标设置的Authentication入口，选择Cookie方式，把Cookie字符串对应的Name/Value逐行解析填入。
5. 登录验证器选择登录后首页固定存在的文本“控制台总览”。
6. 先跑一次Quick Scan或者Crawl Only验证，观察爬虫是否带着登录态爬到后台页面。

这个过程中最容易出错的地方在于，很多人用浏览器复制Cookie时，顺便复制了登录页域下的其他Cookie，但这些Cookie可能是子域专用的。AWVS扫描器设置里的Cookie，默认会用在目标主域名下。如果目标系统的会话Cookie是设置在子域的，AWSV请求主域名时子域Cookie根本不会带过去，扫描范围自然还是空的。

3.3 Cookie方式的高频翻车点

Cookie方式依赖会话的有效期，这是最大的暗雷。如果目标系统设置了会话超时（比如20分钟），AWVS爬取一个大型站点动辄一两个小时，中途会话过期，后半程扫描全部变成匿名请求。解决思路有两个：第一，尽量在会话即将过期前把扫描任务排进去，缩短爬取时间；第二，在配置里添加自动登录的逻辑，让扫描器在检测到验证器失效时自动重新获取Cookie，不过这个一般要配合表单或录制方式。

Cookie值本身可能包含一些特殊字符，比如引号、分号。在AWVS里粘贴Cookie值的时候，要注意字段分隔符的处理。按我的习惯，最好逐行用Name/Value列表添加，而不是把一长串字符串直接糊进去。另一点提醒是，有些系统设置了Secure标记的Cookie，扫描器走HTTP协议访问时不会携带这类Cookie。遇到这种情况，要么把目标协议改成HTTPS，要么临时在测试环境去掉Secure标记。

提示：Cookie方式本质上是“把现有会话借给扫描器”，所以务必保证这个Cookie来自授权范围账号。使用完毕后，建议手动让该会话失效，避免测试账号长期挂着登录态。

4. 表单认证登录方式实操与避坑

4.1 表单参数定位与配置步骤

表单认证方式是最正统的登录扫描配置：扫描器拿着你给的账号密码，按照登录表单的提交地址，把用户名、密码字段填进去，自动提交，然后把返回的会话存下来继续用。

配置时往往需要在登录设置里填几组关键信息：登录页URL、表单提交URL、用户名参数名、密码参数名、验证码参数名（如果有），以及额外的固定表单字段。很多新手会以为登录页URL和表单提交URL是同一个，实际上很多系统把GET请求的登录页和POST请求的接口分开，如果填错了，扫描器要么拿到一个空白表单，要么把账号密码提交到错误地址。

定位表单参数的方法很简单：用浏览器打开登录页，F12切到Network，清空日志后手动登录一次，找到那条提交登录的请求，查看请求体或Form Data。比如：

POST /api/login.jsp HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded username=admin&password=123456&csrf_token=7a9d3f

这里面username和password就是扫描器要用的参数名，csrf_token这类额外参数，在AWVS里可以作为一个固定字段填进去。但注意：如果这个token是每次刷新登录页都会变化的动态值，表单认证方式就没法直接处理，因为扫描器每次都想用同一个固定token提交，服务端不认。这种情况要么找开发关闭动态token校验，要么换录制登录方式。

4.2 登录验证器的选择与登录校验

表单认证方式的配置界面里，登录验证器的地位尤其重要。因为扫描器是自动提交表单的，它成功与否完全依赖验证器来判断。我给一个常用方案：验证器选择一段登录后才出现的文本；如果登录成功后跳转到固定地址，比如/dashboard，也可以选择URL匹配；如果目标系统登录后首页有用户专属内容，比如“欢迎回来，张三”，这就非常适合作为文本验证器。

在填写账号密码时，有两点提醒：一是测试账号尽量选一个权限适中的账号，不要用超级管理员账号跑扫描，免得扫描器在授权逻辑测试环节触发对自己系统的写入行为；二是如果被测系统有登录失败次数限制，AWVS的自动登录如果因为验证器问题反复重试，很可能直接把测试账号锁掉。

表单认证方式对登录失败后的响应也要留意。有些系统登录失败会返回200和一段报错文本，而扫描器可能把这个响应当作成功页面来解析。验证器如果能匹配上登录失败页面里的关键词，扫描器会兴高采烈地认为“登录成功了”，然后带着一个失效的会话继续爬。这个现象我踩过一次，后来排查发现是验证器选了登录页上本来就存在的公共字段，算不上真正的登录态标记。

4.3 表单认证方式的坑与对策

表单认证最大的坑就是验证码。AWVS本身不具备验证码识别能力，它只能把验证码参数当作一个固定字符串提交。所以，如果目标登录页有开启的图形验证码，表单认证方式基本走不通。正常的处理方式是在测试环境临时关闭验证码，或者通过后台白名单机制跳过登录验证码，再跑扫描。如果没法关闭验证码，就直接转录制登录方式，让扫描器复用一次人工登录生成的会话。

动态csrf token的处理类似。很多新式登录页面会在表单里嵌入一个随每次访问变化的token，AWVS每次自动提交登录请求时，都需要重新获取这个token才能成功。表单认证方式一次只提交固定参数，动态token没法保证正确。这个问题在扫描器等安全加固做得好的系统上尤其常见，所以遇到这种系统，我就默认改用录制登录，把token的获取过程一并录进去。

注意：表单认证方式里填写的密码，会以明文形式保存在扫描器目标配置中。如果是共享的扫描环境，务必做好项目文件的访问控制，扫描结束后及时清理目标配置或修改测试账号密码。

5. 录制登录方式实操与避坑

5.1 内置浏览器录制一次登录

录制登录方式是最接近人工操作的方案：AWVS启动一个内置浏览器，你在这个浏览器里正常访问登录页、输入账号密码、完成登录，AWVS把整个过程录制下来，之后扫描器每次需要会话时，都在后台静默回放这套操作，从而拿到新Cookie。

在登录设置里选择登录录制方式，通常会出现一个“记录登录”的入口，点击后弹出录制窗口。里面会显示一个代理地址和端口，比如127.0.0.1:9000，扫描器通过这个代理转发浏览器流量并记录脚本。录制的要点是：

1. 在录制浏览器里打开被测系统首页，先预热一下环境。
2. 进入登录页，输入测试账号密码，正常点击登录。
3. 确认进入登录后的页面，出现预期内容。
4. 立即停止录制，不要继续乱点页面。
5. 保存录制脚本，并运行一遍回放测试。

初次录制时，我犯过一个很低级的错误：登录成功后，又顺手点击了几个菜单，结果录制脚本里包含了管理员列表、用户详情这些接口请求。扫描器回放时不仅会登录，还会把录制期间访问过的这些接口按原样重新请求一遍，轻则产生大量垃圾数据，重则触发审计告警。正确的操作是：登录成功后就停手，其他功能留给爬虫自己去探索。

5.2 回放验证与脚本检查

录制完成之后，AWVS一般会生成一个登录序列（Login Sequence），并提供回放（Replay）功能。这一步不能跳过，一定要回放一次，确认脚本能稳定拿到有效的登录会话。

回放时观察几个点：登录请求是否发出去了、Cookkie是否更新、验证器是否认为登录成功。如果回放失败，最常见的两个原因：一是录制时使用的动态验证码已经失效，扫描器回放时提交的还是旧验证码，被服务端拒绝；二是目标系统登录流程里有短信码或者邮件验证码，这类人机交互环节回放时不可能自动填充，录制登录也没法兜住，只能绕道处理。

我建议在回放过后，顺手导出一份登录序列脚本，看一眼关键步骤：访问登录页、提取token（如果有）、提交登录请求、加载会话。AWVS一般会把提取动态参数的动作自动化，但偶尔会漏掉某些页面里藏在JS里的参数。遇到这种情况，可以在录制时手动添加一个“提取值”的动作，从响应中用正则提取token，填入下一步请求。

5.3 录制方式的高级问题

录制登录方式不是万能的，它最大的问题是“脚本脆弱性”。被测系统只要改了登录页的HTML结构，原本录制的脚本就可能失效。遇到这种情况，重新录制一次是最快的解决办法，别浪费时间在手工修脚本上。

另一个高级问题是会话保持与并发扫描的矛盾。AWVS扫描时会有大量并发爬取线程，而录制登录获取到的会话可能被多个线程同时使用。如果目标应用对单个会话的并发请求做了限速或踢出机制，扫描过程中会出现部分请求401、部分请求200的诡异现象。这时候可以把扫描速度调整为低速（Low），减少并发，确认会话不被冲掉。

提示：录制登录方式其实非常适合带验证码或者SSO跳转的系统，因为人工登录一次之后，扫描器能持续复用这个登录状态。但一定要在授权范围内使用，并且测试账号不要用生产环境的真实用户数据。

6. 常见问题速查表与排错思路

6.1 问题与解决对照表

6.2 三个值得长期记住的排错逻辑

第一，先验证登录是否成功，再谈漏洞检测。很多扫描问题表面上是漏洞少、爬取范围小，本质上都是登录会话没建起来。配置完成后先只跑爬虫模式，输出一个站点结构图，看看里面有没有登录后的后台路径。没有就说明登录还没通，不要继续浪费时间跑完整扫描。

第二，观察日志比猜原因更高效。AWVS的爬虫日志和扫描日志记录了每一个请求的响应状态，登录失败那一刻的HTTP响应码和响应正文，就是最直接的线索。我曾经通过日志发现，扫描器提交的登录请求被WAF拦了，而不是业务登录失败。这种问题看表面配置永远找不出原因。

第三，测试账号要“抗造”。登录扫描会因为配置失误对账号发起大量重复登录请求，如果被测系统没有防自动化机制，账号很快被锁。建议准备两个测试账号，一个用于登录配置调试和爬虫验证，一个用于正式扫描。正式扫描的过程里，一旦发现登录失效，先停任务，不要一键重扫，免得把账号锁得更死。

7. 关于登录扫描的几点个人体会

最后分享一个我习惯上的细节。配置登录方式的时候，不管选哪种方案，我都会确保扫描器在扫完整个站点后能把会话正常退掉，或者在测试完成后手动使会话过期。很多人忽略这一步，觉得测试完了就完了，但一个长期挂在系统后台的测试账号，本身就是一种安全隐患。

另一个体会是，AWVS的登录配置看似只是扫面前的一道工序，其实决定了整个安全检测的深度。花十五分钟把登录方式、验证器和扫描范围理顺，换来的是数倍有价值的检测结果，这笔时间非常划算。如果你在做某个站点的登录扫描时反复遇到“扫不进后台”的问题，建议先别急着怀疑扫描器，回到这三种登录方式上去逐一排查，大概率能解决。