判断 ?s= 请求是扫描还是正常访问,核心在于分析请求的上下文特征。如果该参数伴随大量不同的路径、高频的请求频率或典型的 payload 特征(如 sql 注入尝试),则极大概率为扫描;若请求频率稳定且路径符合业务逻辑,则为正常访问。通常可以通过检查 user-agent、referer 以及请求的具体参数值来辅助判断。

如何识别恶意扫描的特征?
恶意扫描通常具有明显的自动化特征和攻击意图。扫描器往往会发送大量的随机或字典式路径,并尝试在 ?s= 参数中注入恶意代码。例如,常见的扫描行为包括遍历 /admin、/wp-login.php 等敏感路径,或者在参数中包含 ' OR '1'='1 等 SQL 注入语句。此外,扫描器的 User-Agent 往往为空、包含 "Scanner" 字样,或者使用默认的工具标识如 "Nikto"、"sqlmap"。通过日志分析工具提取这些特征,可以有效区分扫描流量。

将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算,采用设计 token 模式使颜色天生可访问,设定排版和焦点状态规则,并提供语义检查清单。适用于构建或审查 UI。
import re
from collections import defaultdict
def analyze_access_log(log_file):
scan_indicators = []
normal_requests = []
# 定义扫描特征的关键词
sql_injection_patterns = [r"'\s*OR\s*'", r"UNION\s+SELECT", r"DROP\s+TABLE"]
sensitive_paths = [r"/admin", r"/wp-login", r"/phpmyadmin"]
with open(log_file, 'r') as f:
for line in f:
# 简单解析 Apache/Nginx 日志格式
if '?s=' not in line:
continue
# 提取关键信息 (简化版)
path_match = re.search(r'GET (\S+) HTTP', line)
ua_match = re.search(r'"(\S+)"$', line)
if path_match:
path = path_match.group(1)
ua = ua_match.group(1) if ua_match else "Unknown"
is_scan = False
reason = []
# 检查路径是否为敏感路径
for pattern in sensitive_paths:
if re.search(pattern, path, re.IGNORECASE):
is_scan = True
reason.append("Sensitive Path")
break
# 检查参数是否包含 SQL 注入特征
for pattern in sql_injection_patterns:
if re.search(pattern, path, re.IGNORECASE):
is_scan = True
reason.append("SQL Injection Attempt")
break
# 检查 User-Agent
if "Scanner" in ua or "sqlmap" in ua.lower():
is_scan = True
reason.append("Suspicious UA")
if is_scan:
scan_indicators.append({"path": path, "ua": ua, "reason": reason})
else:
normal_requests.append({"path": path, "ua": ua})
return scan_indicators, normal_requests
# 示例调用
# scans, normals = analyze_access_log('access.log')
# print(f"Detected {len(scans)} potential scans.")
如何配置 WAF 拦截此类请求?
Web 应用防火墙(WAF)是防御此类扫描的有效手段。通过配置规则,可以自动拦截包含特定恶意模式的 ?s= 请求。例如,可以设置规则匹配 SQL 注入关键字、XSS 脚本标签或已知的扫描器 User-Agent。当请求命中这些规则时,WAF 可以直接返回 403 Forbidden 状态码,从而阻止恶意请求到达后端服务器。此外,还可以结合 IP 信誉库,对来自已知恶意 IP 段的请求进行更严格的限制。

# Nginx 配置示例:拦截包含 SQL 注入特征的 ?s= 请求
server {
listen 80;
server_name example.com;
location / {
# 检查查询字符串中是否包含 SQL 注入特征
if ($query_string ~* "'(\s)*OR(\s)*'") {
return 403;
}
# 检查 User-Agent 是否为常见扫描器
if ($http_user_agent ~* "(nikto|sqlmap|nmap)") {
return 403;
}
proxy_pass http://backend;
}
}
基于程序中某个输入、条件或结果的具体问题
在实际应用中,如果程序本身依赖 ?s= 参数进行搜索功能,那么正常的用户请求也会被误判为扫描。例如,当用户搜索包含单引号的内容时,可能会触发 SQL 注入检测规则。为了避免这种情况,需要在 WAF 规则中排除白名单 IP 或特定的业务路径。此外,可以通过记录被拦截的请求日志,定期审查误报情况,优化规则配置。对于正常的业务请求,确保其参数经过适当的编码和验证,以减少被误判的风险。

















