新上线网站漏洞排查与基础防护搭建

新站上线后的前三个月是攻击者最活跃的窗口期，很多扫描器会批量探测新解析的域名和IP段，一旦发现常见的默认后台、测试文件或未关闭的调试接口，就会直接进入利用流程。所以漏洞排查不能只依赖上线前的一次渗透测试，而要把重点放在“上线后的暴露面收敛”和“基础防护是否真正生效”这两件事上。

先看最容易被忽略的几类问题。第一类是源码包和配置文件残留，比如网站根目录下还留着www.zip、backup.tar.gz、.git目录、.svn目录或者.env文件。攻击者只要下载到源码包，就能直接审计出SQL注入和后台绕过漏洞，比黑盒测试快得多。第二类是调试模式未关闭，很多框架在debug模式下会直接回显数据库报错、堆栈信息和环境变量，等于把数据库结构主动暴露出来。第三类是默认后台地址和弱口令，新站最容易在赶工期时直接用admin/admin123这类组合，扫描器第一批就会尝试。

排查时建议按“文件系统、服务配置、应用逻辑、权限体系”四个层面走一遍。文件系统层面，用命令行检查网站目录下是否有版本控制目录和压缩包，同时确认上传目录是否具备脚本执行权限。服务配置层面，检查Web服务器是否关闭了目录浏览，是否限制了敏感文件类型的直接访问，是否隐藏了服务器版本号。应用逻辑层面，重点看登录接口、找回密码接口、文件上传接口和API接口是否有频率限制与输入校验。权限体系层面，确认后台管理路径是否做了访问控制，普通用户是否可以通过修改ID越权访问他人数据。

先确认网站根目录的物理路径，然后执行几条基础命令。Linux环境下可以这样查常见泄露文件：

find /www/wwwroot/你的站点 -maxdepth 3 -type f \( -name "*.zip" -o -name "*.tar.gz" -o -name "*.sql" -o -name "*.bak" -o -name ".env" \) -print
find /www/wwwroot/你的站点 -type d \( -name ".git" -o -name ".svn" -o -name ".hg" \) -print

如果发现.git目录，说明源码仓库被直接部署到了生产环境，攻击者可以用工具还原出完整源码。处理方式不是简单删除目录，而是重新从干净的发布包部署一次，因为.git里可能已经包含了历史提交中的敏感配置。对于压缩包和数据库备份文件，直接移出Web可访问目录，或者放到一个随机命名的目录下并设置访问密码。

上传目录的权限要单独检查。如果上传目录允许执行PHP、JSP、ASPX等脚本，攻击者传一个Webshell就能控制整台服务器。正确做法是在Web服务器配置中对该目录单独设置，禁止脚本引擎解析。以Nginx为例，可以在站点配置中加一段：

location ~* ^/uploads/.*\.(php|php5|phtml|jsp|asp|aspx)$ {
    deny all;
}

Apache环境则可以通过.htaccess关闭该目录的脚本执行：

    Require all denied

同时检查上传目录是否开启了目录浏览，如果访问uploads目录能看到所有文件列表，等于把用户上传的身份证、合同、图片全部公开了。Nginx中确认autoindex为off，Apache中确认Options没有Indexes。

Web服务器返回的响应头会泄露大量信息。用curl命令查看：

curl -I https://你的域名

重点看Server头是否暴露了具体版本号，X-Powered-By是否暴露了PHP版本，X-AspNet-Version是否暴露了.NET版本。这些信息能帮助攻击者精准选择对应版本的漏洞利用脚本。Nginx可以在主配置中加server_tokens off;隐藏版本号，PHP需要在php.ini中设置expose_php = Off。

目录浏览问题要全站检查，不能只看首页。很多站点只在根目录关闭了目录浏览，但子目录继承的配置不一致，或者某些虚拟目录单独开启了Indexes。可以手动访问几个常见路径，比如/css/、/js/、/images/、/upload/、/backup/，看是否返回文件列表。如果返回403或404是正常的，返回200并显示文件清单就是漏洞。

跨域配置也经常出问题。检查站点响应头中Access-Control-Allow-Origin的值，如果是*且Access-Control-Allow-Credentials为true，等于允许任何网站携带用户凭证访问你的接口，攻击者可以在恶意页面中调用你的API窃取数据。正确做法是明确指定允许的域名，并且不要同时使用通配符和凭证模式。

登录接口是第一优先级的检查对象。先看是否有验证码或频率限制，用脚本连续提交错误密码测试，如果服务端没有返回429或者锁定提示，说明可以暴力破解。再看登录失败和成功的响应差异，如果失败时返回“用户名不存在”和“密码错误”两种不同提示，攻击者可以枚举出有效用户名。统一提示“用户名或密码错误”是最基本的要求。

SQL注入的排查重点放在URL参数和搜索框上。手动测试时在参数后加单引号，观察页面是否出现数据库报错。如果站点有WAF，单引号可能被拦截，可以换用数字型参数测试，比如把id=1改成id=1 and 1=1和id=1 and 1=2，对比两次返回结果是否一致。一致说明参数没有直接拼接到SQL语句中，不一致则存在注入可能。更高效的方式是使用自动化扫描工具对全站参数做一轮测试，但扫描前要确认目标站点是自己的资产，并且扫描频率控制在合理范围，避免对生产环境造成压力。

文件上传漏洞的检查不能只看扩展名过滤。攻击者常用的绕过方式包括：上传带双扩展名的文件如shell.php.jpg、利用大小写混淆如shell.Php、使用特殊扩展名如shell.php5或shell.phtml、在文件名中加入空格或点号、修改Content-Type头为image/jpeg。测试时要逐一尝试这些变体，确认服务端是否真正检查了文件内容和扩展名的一致性。如果条件允许，上传目录最好使用对象存储或独立域名，与主站完全隔离。

越权漏洞在新站中非常普遍，尤其是用户中心相关的接口。测试方法是注册两个普通账号A和B，用A登录后，将请求中的用户ID参数改成B的ID，看是否能读取或修改B的数据。这类问题通常出现在“查看订单详情”“修改个人资料”“删除收货地址”等功能中。修复的核心是服务端必须从会话中获取当前用户身份，而不是信任客户端传来的ID参数。

漏洞排查完成后的修复只是第一步，基础防护要同步搭建起来。优先级最高的是访问控制，包括后台管理路径的IP白名单、登录接口的失败次数限制、敏感操作的二次验证。后台路径不要使用常见的/admin或/manage，可以改成随机字符串，并且只允许公司出口IP或VPN网段访问。如果团队没有固定IP，至少加上HTTP Basic Auth作为额外一层保护。

第二优先级是输入输出过滤。所有用户输入在服务端做白名单校验，能限制长度就限制长度，能限制字符集就限制字符集。输出到页面时根据上下文做HTML编码、JavaScript编码或URL编码，防止存储型XSS。对于富文本内容，使用成熟的过滤库而不是自己写正则，因为绕过正则的方式太多。

第三优先级是日志与监控。确保Web服务器和应用程序都开启了访问日志和错误日志，日志中要包含真实客户端IP、请求方法、请求路径、状态码和User-Agent。在此基础上配置简单的告警规则，比如同一IP在1分钟内请求超过100次、连续出现404状态码、请求路径中包含敏感关键词如phpmyadmin或actuator，这些都可能是在被扫描。日志至少要保留30天，方便事后溯源。

第四优先级是备份与恢复。新站上线后要立即建立自动备份机制，数据库每天备份一次，网站文件每周全量备份一次，备份文件存储在独立的服务器或对象存储中，不要放在网站根目录下。同时要定期做恢复演练，确认备份文件真的能还原，而不是等到出事才发现备份是坏的。

HTTPS的配置也属于基础防护的一部分。确认全站强制跳转HTTPS，证书在有效期内，没有混合内容问题。同时检查TLS协议版本，关闭SSLv2、SSLv3和TLS1.0这些已经不安全的老版本，只保留TLS1.2和TLS1.3。安全响应头也要补上，包括X-Content-Type-Options: nosniff、X-Frame-Options: SAMEORIGIN、Content-Security-Policy和Referrer-Policy，这些头能有效降低点击劫持、MIME嗅探和数据泄露的风险。

最后要强调的是，新站上线后的安全维护是一个持续过程，不是一次性工作。建议每周固定时间检查一次日志中的异常请求，每月做一轮全站漏洞扫描，每季度对服务器和依赖组件做一次版本升级评估。攻击手法在不断变化，新漏洞每天都在披露，保持对安全公告的关注和快速响应能力，比任何单次加固都重要。