Firewall Rule syntax

Howdy, I had a (hopefully) easy question. When adding new firewall rule (using the Firewall Rule Expression syntax) do newlines impact them in anyway? The “formatted” version does seem to pass when checking against the Validate Filter Expression api endpoint but I wanted to double check.

For example, formatted:

(
    (
        (http.host contains "google.com" or http.host contains "bing.com")
        and ip.src in {127.0.0.1 0.0.0.0}
    )
    or (http.host contains "google.com" and http.request.uri contains "wp-admin")
)

Vs “unformatted”:

(((http.host contains "google.com" or http.host contains "bing.com") and ip.src in {127.0.0.1 0.0.0.0}) or (http.host contains "google.com" and http.request.uri contains "wp-admin"))**strong text**

I’ve tested on my zone writing a similar rule and it worked without problems😉

So it seems the answer here is: newlines shouldn’t impact how the firewall rule works

I imagine this type of expression ignores linebreaks unless in string literals.

It looks like you’re doing exclusion here so probably okay, but generally be careful, 0auth.com fcked up with contains vs startsWith/endsWith… If apply the same style to whitelisting you’re up for a trap if you use contains e.g. 457438usdfsdgoogle.com passes

If startsWith/endsWith isn’t available, which would be sad (not looked), then you’d need a regex and CF isn’t allowing them on non Business plans.

1 Like

@ CF Security: If you can support ‘contains’, you can support non-regex versions of startsWith / endsWith (arguably cheaper computationally wise) to prevent people making these potential mistakes. This seems quite an oversight on the CF Security audits.

Thank you both @weronika and @matt53 . Also agreed about the “contains” syntax, these sorta rules are generally scoped to a hostname + specific IP (so while a largeish hole, it’s less than just “host contains” + “path contains”).

I’d be interested in a “contains domain” where the tld / domain is specified rather than a sub-string. That would satisfy my requirement (covering a domain + it’s subdomains) while also being a “validatable” endpoint.
^ I say this knowing that the new WAF stuff might solve the underlying cause of why these rules are even made in the first place.