suricata告警中sqli/xss命中需结合http字段、payload可读性及上下文判断真伪：带app_layer_proto: http且http_uri/http_client_body非空、src_ip属可信段、复现后应用异常者为真实攻击；否则多为误报。
Suricata告警里看到SQLi/XSS规则命中，先别急着删流量
Suricata本身不解析HTTP语义，它靠规则匹配payload中的特征字符串（比如SELECT.*FROM、<script></script>）或异常编码模式（如%3Cscript%3E）触发告警。这意味着：一次命中可能是真实攻击，也可能是误报——比如开发用curl测试接口时带了test' OR '1'='1，或者前端框架自动注入的data-script属性。
关键判断点是看suricata.log或eve.json中该条告警是否附带http字段（含uri、hostname、user_agent），以及payload字段是否包含可读的恶意片段。没有http上下文的纯tcp层告警，大概率是误报或协议混淆。
- 检查告警是否带
app_layer_proto: http—— 不带的直接归为低置信度 - 确认
payload是否被Suricata成功解码（http_client_body或http_uri字段存在且非空） - 比对
src_ip是否属于你信任的内网段或CDN回源IP（如阿里云SLB回源IP段100.64.0.0/10）
从eve.json快速定位SQL注入原始请求
Suricata默认输出JSON格式的eve.json，比文本日志更适合做结构化分析。SQL注入的关键线索藏在http和http_client_body字段里，而不是告警消息文字本身。
用jq快速过滤含SQL关键字的真实请求：
jq -r 'select(.event_type == "alert" and .alert.signature_id == 1000001) | "(.src_ip) (.http.hostname)(.http.uri) (.http_client_body)"' eve.json | grep -i -E "(select|union|insert|drop|exec|xp_cmdshell)"
注意：signature_id需替换成你实际启用的SQLi规则ID（常见如ET OPEN规则集的2019400或Emerging Threats的2012751）；http_client_body只在Suricata配置了stream.inline: yes且HTTP解码成功时才存在。
- 如果
http_client_body为空但payload有内容，说明HTTP流未完整重组，需检查stream.reassembly配置 - URI中出现
%27、%3B等编码，要先用printf解码再判断：printf '%b' "$(echo '%3Cscript%3E' | sed 's/%/\x/g')" - 真实SQLi常伴随
User-Agent异常（如sqlmap、nikto）或Referer为空，这些字段在eve.json中都有对应字段
XSS告警为什么总在静态资源路径上触发？
Suricata的XSS规则（如ET WEB_SPECIFIC_APPS Possible XSS in URI）常在/static/js/app.js?callback=<script></script>这类路径上误报，本质是规则太宽泛：它只匹配URI中是否含<script></script>，不校验是否在合法参数位置或是否被引号包裹。
真正需要关注的是http_client_body中提交的POST数据，尤其是表单类接口（/api/comment、/user/profile）。XSS利用必须能反射或存储到页面DOM中，单纯URI含标签不构成风险。
- 优先排查
http.method == "POST"且http.content_type含application/x-www-form-urlencoded或application/json的告警 - 忽略
http.uri中.js、.css、.png后缀的XSS告警（除非你真在JS文件里动态拼接用户输入） - 检查
http.cookie字段是否含<script></script>——这是更隐蔽的XSS入口，容易被漏掉
怎么验证是真攻击还是规则太松？
最直接的办法是复现：用curl构造告警里记录的src_ip、dst_port、http.uri和http_client_body，发包到目标服务，看应用层是否真的执行了恶意代码（比如返回数据库表名、弹窗alert(1)）。
但要注意两点：
- 别在生产环境直接复现——先用
tcpdump抓取原始包，用tcpreplay在测试环境重放 - Suricata规则可能依赖
flowbits状态跟踪（如先检测UNION再检测SELECT），单包复现会失败，得用完整TCP流 - 如果复现后应用无异常，大概率是WAF或应用层已拦截，此时Suricata告警只是“冗余检测”，应调低该规则权重或加
suppress规则
真正难处理的不是告警本身，而是那些没触发Suricata但绕过WAF的编码变种（如javascript:alert(1)），它们不会出现在eve.json里，得靠应用日志反查——这点最容易被忽略。
