应拦截含eval、system等敏感值及phpinfo、globals等敏感名的参数，优先检查原始query_string并用rawurldecode循环解码，通过stripos匹配预编译关键词数组，解析后过滤，命中则返回400响应且不记录完整query。
中间件该拦截哪些参数名和值
直接过滤所有 $_GET 不现实，真正要拦的是常见攻击入口：比如含 eval、system、exec 的参数值，或参数名带 phpinfo、_SERVER、GLOBALS 这类敏感词。Laravel 的 Request 对象在中间件里已解析过 GET，但原始未解码的值可能藏恶意编码（如 %3Cscript%3E），所以得同时检查 $request->query() 和 $_SERVER['QUERY_STRING']。
- 优先匹配参数名黑名单：
cmd、exec、phpinfo、GLOBALS、_REQUEST、GLOBALS、HTTP_ACCEPT_LANGUAGE（曾被用于 RCE 链路） - 值检测需解码后判断：
urldecode()一次不够，有些 payload 多层编码，建议用rawurldecode()+ 循环解码直到不变 - 避免正则回溯爆炸：别用
/(eval|assert|system)\s*\(/i这种贪婪模式，改用字符串函数stripos()或预编译的固定关键词数组
Laravel 中间件里怎么安全读取原始 GET 字符串
$request->fullUrlWithQuery([]) 会丢掉原始编码，$request->server('QUERY_STRING') 才是原始未处理字符串。但注意：如果应用启用了 trusted proxies 或用了 CDN，QUERY_STRING 可能被篡改，必须配合 Request::isTrustedProxy() 校验来源 IP。
- 不要依赖
$request->query()做过滤——它已自动 urldecode，会把%253Cscript%253E（即 %3Cscript%3E 的二次编码）解成无害字符串，漏掉真实 payload - 用
parse_str($rawQuery, $parsed)手动解析原始字符串，再逐个检查键和值；parse_str比$_GET更可控，不会触发 PHP 自动全局变量注入 - 若项目用了 Laravel 的
TrimStrings中间件，它会在你之前运行并修改$_GET，所以必须在TrimStrings之前注册本中间件
匹配到恶意参数后该返回什么状态码
返回 400 Bad Request 是最稳妥选择。别用 403 Forbidden——它暗示“你有权但不许”，而实际是请求本身结构非法；更不能重定向或返回空页，这会给扫描器反馈信号。
- 记录日志时只记参数名和客户端 IP，**绝不记录完整 query string**——防止日志中存储 XSS payload 或数据库密码片段
- 响应体保持极简：
return response('', 400);，避免输出任何 HTML 或 JSON，防止被利用做内容注入 - 别在生产环境抛异常（如
abort(400)），因为 Laravel 默认异常页会暴露框架版本和路径，应直接响应
为什么不能只靠 .htaccess 或 Nginx 规则
Nginx 的 if ($args ~ ...) 规则容易绕过：大小写变换（EvAl）、空格/制表符分隔、URL 编码嵌套都可能逃逸。而且 Nginx 规则无法感知 Laravel 的路由前缀（如 /api/v1 下才需要严控），也无法与 Auth 中间件协同（比如仅对未登录用户启用过滤）。
- .htaccess 对 POST body 无效，但 GET 参数常被用作 bypass 路径，比如
?callback=<script>...</script>用于 JSONP 注入 - PHP 层过滤能统一处理所有入口：命令行 Artisan 命令、队列任务里的 URL 构造、甚至测试用的
Http::get()调用 - 真正的难点不在写规则，而在更新——OWASP Top 10 每年变，黑名单得随 CVE 同步，建议把关键词列表抽成配置文件，而非硬编码在中间件里
