Routing 全局条件过滤恶意请求参数与非法 IP【请求守卫】-php教程-PHP中文网

apache中需用mod_rewrite配合rewritecond %{query_string}匹配原始编码后的敏感参数（如cmd=cat%20%2fetc%2fpasswd），再通过rewriterule ^ - [f]返回403；必须启用模块、allowoverride fileinfo并开启rewriteengine on。

routing 全局条件过滤恶意请求参数与非法 ip【请求守卫】

Apache 里怎么用 RewriteCond 拦截带敏感参数的请求

Apache 没有 RewriteFilter，真正起作用的是 mod_rewrite + RewriteCond %{QUERY_STRING} 组合。关键不是“写规则”，而是确保规则能真正匹配到原始编码后的查询字符串。

RewriteRule 默认只匹配路径（如 /api/user），?token=abc 这部分必须显式用 RewriteCond %{QUERY_STRING} 检查
常见错误：写 RewriteRule ^/admin\.php\?token=.* - [F] —— 这条完全无效，Apache 不解析 URL 中的 ? 后内容
%{QUERY_STRING} 是原始编码值：是 +，/ 是 %2f，中文是 %E4%BD%A0；正则必须按这个形式写，比如匹配 cmd=cat%20%2fetc%2fpasswd，不能写成 cmd=cat /etc/passwd

推荐写法：

RewriteCond %{QUERY_STRING} (cmd|exec|phpinfo|env)= [NC]
RewriteRule ^ - [F]

——拦截任意路径下含这些参数名的请求

Nginx 的 if + $args 怎么防 SQL/XSS 参数

别依赖 $request_uri 做全部匹配，它包含路径和未解码的 query，容易漏或误杀；$args 才是解码后、可读性更好的参数串，但要注意它不包含键名结构，只适合做关键词扫描。

Apache Superset Dashboard and SQL Exploration Skill

Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

下载

SQL 注入特征要覆盖大小写和常见变体：union select、UNION+SELECT、or+1=1 都得进正则，建议用 ~*（忽略大小写）
XSS 关键词如 <script></script>、javascript:、onerror= 必须在 $args 和 $request_uri 里都检查，防止攻击者把 payload 放在路径里绕过

注意 if 在 Nginx 里是“慎用”指令：它不能嵌套，且多个 if 是独立执行的，要用变量累积状态，例如：

set $block 0;
if ($args ~* "(union|select|insert|drop)") { set $block 1; }
if ($request_uri ~* "<script>|javascript:") { set $block 1; }
if ($block = 1) { return 403; }</script>

不要在 if 里调用 rewrite 或 proxy_pass，极易引发重写循环或配置失效

Spring Cloud Gateway 怎么全局过滤非法 IP 和脏参数

全局过滤器（GlobalFilter）是 Gateway 最自然的守卫位置，但它不自动解析 query 或 body，必须手动调用 exchange.getRequest().getQueryParams() 或 ServerWebExchange.getFormData()，否则规则形同虚设。

IP 拦截别只靠 getRemoteAddress()：反向代理后它返回的是 Nginx 或 LB 的地址，要用 X-Forwarded-For 头，并做可信跳数校验（如只取第 1 个非内网 IP）
参数过滤必须区分场景：GET 参数走 getQueryParams()，POST/PUT 表单数据要先触发 getFormData()（会自动解析 application/x-www-form-urlencoded），JSON 则需读取 body 流并解析——不能假设所有请求都走同一路径
白名单逻辑要前置：比如健康检查 /actuator/health 或登录接口 /auth/login 必须在过滤逻辑最开头跳过，否则会导致服务不可用
注意响应体过滤是另一件事：GlobalFilter 默认只处理请求，改响应需用 ModifyResponseBodyGatewayFilterFactory，且要处理字符编码和流重放问题

ThinkPHP 和 Laravel 的全局过滤为什么容易失效

框架级过滤看似省事，但一旦配置错位置或时机，就等于没开——尤其当业务代码绕过 input() 直接读 $_GET 或 $_POST 时，所有过滤都失效。

ThinkPHP default_filter 只对 input()、param() 生效，如果控制器里写 $_GET['id']，过滤完全不触发
Laravel 的 validate() 或 validated() 是手动调用的，不加这行就不会校验；想强制全局，得靠中间件 + Request::replace() 替换原始输入，但要注意数组嵌套和文件字段兼容性
JSON 请求体（Content-Type: application/json）在 TP/Laravel 中默认不进 $_POST，必须显式用 file_get_contents('php://input') 解析，而框架过滤通常不覆盖这一路径
最稳做法：在入口文件（如 public/index.php）最开头就对 $_GET、$_POST、$_REQUEST 做递归清洗，再交由框架处理——不依赖框架钩子，也不怕中间件顺序错乱