Has anyone run into this before?
nc -l -p 1234 -q 1 > testfile.txt < /dev/null
The other one doesn't. alias foobar=nc
cat testfile.txt | foobar 192.168.2.100 1234
I was hoping that it was a "useless use of cat" filter, but nope. It just doesn't like the bytes nc next to an IPv4 address.This is also fine, but blocked if you change the slash to a dot:
nc 192/168.2.100 1234
This works too: nc \
192.168.2.100 1234
OK, that's all for now. Can you believe people pay money for "web application firewalls"?
Additionally cloudflare doesn't know what is safe for a given site, so it has to be a little conservative. The sites that can handle malicious input, or are tech sites that expect things that are SQL or commands that may contain directory traversal, these are in the minority.
Essentially these are false positives, which are typically viewed as more acceptable than false negatives as those would allow attacks through.
These things are configurable by the site owners, but the issue here is that the site owners are not shown the code of the rules, so have to guess from the names and descriptions whether something is safe to disable, meaning everyone just leaves everything enabled. Usually reporting this to a site owner with the cloudflare trace id is sufficient to enable the site owner to disable a rule that is causing false positives, as the site owner can use the cloudflare dashboard to search the trace id.
I do not work there any longer (left 3 years ago), but did write significant parts of the firewall and also manage the firewall, WAF, and DDoS protection teams.
nc 192.168.1.100 8000
../ ../ ../ etc/ passwd
(remove the spaces)
Well, it's a client that has no Javascript engine.
There is no need to use Javascript. This works for me just fine:
Minimal test, if I try to edit this post removing the asterisk, I get the "banned" page
nc* 192.168.2.100
Any idea whether that's just an overloaded application server, or something Cloudflare is doing?
`nc 192.168.2.100`