我已经建立了参考 https://cloud.google.com/armor/docs/rules-language-reference 的Google Cloud Armor安全策略。它工作正常。我从办公室检测到模拟的SQL注入攻击，随后的访问被阻止。堆栈驱动程序日志条目显示相应的强制安全策略结果为"拒绝"，应用的表达式 ID 为"owasp-crs-v030001-id942421-sqli"。关键 WAF 规则如下：
evaluatePreconfigExpr('xss-stable'( && evaluatePreconfigExpr('sqli-stable'(
有一点我无法控制。在我的模拟攻击之后，来自我办公室的所有访问都被一直阻止。一旦我从 LB 拆下并重新附加了 Cloud Armor 安全策略，仍然阻止了来自我办公室的访问。删除该安全策略并再次重新创建它无济于事。这意味着有一个看不见的SQLi和XSS攻击者的持久数据库，我的办公室IP可能在其中注册，导致"一直"拒绝。
问题是：如何在不修改规则的情况下从看不见的"SQLi 和 XSS 黑名单"数据库中删除我的 IP 以重新获得后端访问权限？在我们的 Cloud Armor 生产操作中，曾经被禁止的 IP 可能希望在删除攻击源后重新获得对目标后端服务的访问权限。
当然，如果我添加比 WAF 规则更高优先级的权限规则，我可以重新获得对目标后端的访问权限，但 WAF 检查将被绕过，这不是我想要的。
提前感谢您的时间。
R.栗岛
我也有类似的情况，几乎得出了你所做的同样的结论——有某种隐藏的黑名单。但是在尝试了更多之后，我发现，相反，我的请求中的其他一些非恶意cookie正在触发owasp-crs-v030001-id942421-sqli("受限SQL字符异常检测(cookie(：超出特殊字符#(3(" - 以及后来的owasp-crs-v030001-id942420-sqli("受限SQL字符异常检测(cookie(：超出特殊字符#(8("(。不是隐藏的黑名单。
据我所知，这两个规则使用 Cookie 标头中的"特殊"字符数，而不是每个 cookie 中特殊字符的数量。此外，等号 - 用于每个cookie - 算作一个特殊字符。与分号相同。要命。
因此，此请求将触发 942420：
curl 'https://example.com/' -H 'cookie: a=a; b=b; c=c; d=d; e=e;'
这将触发942421：
curl 'https://example.com/' -H 'cookie: a=a; b=b;'
所以最好禁用这两个规则，比如
evaluatePreconfiguredExpr('sqli-canary', [
'owasp-crs-v030001-id942420-sqli',
'owasp-crs-v030001-id942421-sqli'
])