Blocked user-agent being wrongly whitelisted

Security
,
#24

Hi @Zenexer,

In CF Firewall documentation, JS Challenge seems to be a degree higher than Challenge (Captcha). At least it is listed in a way that gives that impression.

While the captcha challenge will test whether it’s a bot or a human, and whitelist the visit if from a human, therefore being a user-centric measure, the JS Challenge, as I understand it, is supposed to not only verify that the browser (bot or not) has JS enabled but that it passes Cloudflare test to be admitted. What this test is is a mystery. Documentation says very little about it.

As for the bot in case, it was stopped by JS Challenge many times, and only whitelisted a few times. And these were successive requests, sometimes over a few times in a second. I don’t think (though I don’t discard it) the bot would have shifted from having JS to not having JS enabled between hits. But anyway, this is the purpose of this thread, to make Cloudflare aware that this happened, and to clarify whether there’s something wrong with either my account in general or with my firewall settings.

#25

I can confirm @alexcf’s findings. If a user agent rule triggers a challenge and that challenge is passed subsequent requests show up as whitelisted. Thats pretty confusing.

Not related but very similar to another issue I discovered, where completed challenged (imposed by firewall rules) still show up in the list for every single subsequent request.

#26

The problem here, as I pointed out to @alexcf, is that I never had any UA block rule with Challenge that applied to that particular UA. The rule in place had action JS Challenge. Another JS Challenge rule, by country, would also apply to this visits. The only Challenge (Captcha) rules I had were specific to other UAs.

I finally downloaded the origin server raw access log, and out of the 6 times this bot was whitelisted yesterday, only 3 visits made it to the server. All three were caught by my WP firewall. This only makes this whole thing a bit more strange.

I’ve since changed this specific UA block rule to “Block” instead of JS Challenge.

#27

It is not specific to captcha challenges but applies to all, including JavaScript challenges.

#28

And my doubt remains: how could a bot that was stopped by a JS Challenge many times suddenly be allowed in? It makes no sense to me, unless this were a Captcha, which only depends on the visitor’s action (check a box and click on). Challenge is what @alaexcf used in his example.

#29

If that bot runs a full-fledged browser it will pass the captcha.

#30

Then if the bot was running a full-fledged browser it wouldn’t be stopped many times over to begin with. Please see these timestamps:

uablock-whitelist-php-files-07
uablock-whitelist-php-files-07.jpg820×660 56.1 KB

uablock-whitelist-php-files-08
uablock-whitelist-php-files-08.jpg823×590 49.5 KB

As I said before, it is unlikely (though not impossible, who am I to say) that a bot would enable/disable JS on the flight.

But having shown that a bot was many times successively JS-challenged and a few times subsequently Whitelisted, I think the proper stance here should not be to take for granted that Cloudflare is infallible and list all possible hypothetical ways in which a bot could have made it to its goal, but to examine the possibility that a bug (or a performance issue) may have resulted in this bot reaching the origin server.

This thread is no longer about my website (I’ve changed the rule to Block). It’s about to what extent we can trust JS Challenge as a deterring action. Because if JS Challenge is only about certifying the bot is running JS, which I doubt, it shouldn’t be listed a higher protection than Challenge.

This same bot is likely probing around many websites after a few php files, and at one time will reach a website that (1) is protected by Cloudflare; (2) has firewall rules enabled that were meant to JS Challenge these visits; (3) has WP and the plugin or theme containing the specific php files being sought; and (4) does not have a strong server-level (htaccess or equivalent) or WP firewall to protect itself.

I believe Cloudflare ought to explain better what each of the three blocking actions do so that we can feel more confident in using (and in knowing how to use) them.

#31

You dont need to convince me :smile:. I simply confirmed @alexcf’s explanation. If this was applicable in your case, I cant tell.

1 Like
#32

So as I said… the bot or whoever has successfully passed the JavaScript challenge. It’s not infallible for sure. Hence why I previously recommended using captcha only. The reason here is that the bot passed the challenge and has a cookie set. That will allow it to pass any challenge mechanism.

#33

In all this time, it’s been just a single IP address. At this point, I’d just block that IP address.

2 Likes
#34

The issue in question is Firewall events still list every request after challenge.

#35

I assure you, @cbrandt, that it is passing the challenge. What’s happening is that it’s making multiple requests in quick succession. The JS Challenge takes about 3-5 seconds to pass, so at this point, it hasn’t passed yet, and all the requests return a challenge. Once the first challenge received is passed, all subsequent requests appear as whitelisted. What you’re observing is the delay between the initial challenge and the time it takes to pass.

The JS Challenge isn’t meant to be infallible; it’s meant to stop rudimentary layer 7 attacks that don’t use something like Selenium. However, there are an increasing number of JS-capable bots that can pass these challenges. In this scenario, using a captcha challenge might be more effective, but some can pass those, too.

None of this is meant to be infallible; it’s just meant to filter out the majority of problematic requests.

#36

Hi @Zenexer, thank you.

I’ve already changed from JS Challenge to Block for that specific UA and IP.

However, for the sake of clarifying things, when I said infallible I didn’t mean a single rule would have to block everything. I used the word as meaning bug-free.

Once the first challenge received is passed, all subsequent requests appear as whitelisted.

The timestamps on the requests from this specific bot do not match you are describing. As you can see in the table below, with the first 42 hits by this UA, this doesn’t seem to be always the case.

Notice that after a Whitelist, in a couple instances there were other Whitelists, but they were followed by almost immediate jsChallenge:

Order Type Ray ID Time URI Action Taken
1 Firewall Rule 497fafee21d368c0 January 12, 2019 10:39:40 (-02:00) /v4web.php jsChallenge
2 User-Agent Blocking 497fafee933d68d8 January 12, 2019 10:39:40 (-02:00) /text.php Whitelist
3 Firewall Rule 497fafef44496920 January 12, 2019 10:39:40 (-02:00) /v4web.php jsChallenge
4 User-Agent Blocking 497faff15b2b68c0 January 12, 2019 10:39:41 (-02:00) /text.php Whitelist
5 User-Agent Blocking 497fb00c55626956 January 12, 2019 10:39:45 (-02:00) /v4web.php Whitelist
6 User-Agent Blocking 497fb00edebf68ba January 12, 2019 10:39:45 (-02:00) /v4web.php Whitelist
7 Firewall Rule 4984baaf350768d8 January 13, 2019 01:20:49 (-02:00) /v4web.php jsChallenge
8 Firewall Rule 4984bacb2125691a January 13, 2019 01:20:54 (-02:00) /v4web.php jsChallenge
9 Firewall Rule 4984bacc22d16908 January 13, 2019 01:20:54 (-02:00) /v4web.php jsChallenge
10 Firewall Rule 4984baccb5aa68f0 January 13, 2019 01:20:54 (-02:00) /system123.php jsChallenge
11 Firewall Rule 4984baccb159691a January 13, 2019 01:20:54 (-02:00) /prv.php jsChallenge
12 Firewall Rule 4984bacd063f6902 January 13, 2019 01:20:54 (-02:00) /text.php jsChallenge
13 Firewall Rule 4984baed170b69be January 13, 2019 01:20:59 (-02:00) /prv.php jsChallenge
14 Firewall Rule 4984baed107a68fc January 13, 2019 01:20:59 (-02:00) /text.php jsChallenge
15 Firewall Rule 4984baed164168ba January 13, 2019 01:20:59 (-02:00) /system123.php jsChallenge
16 Firewall Rule 4984baed157168b4 January 13, 2019 01:20:59 (-02:00) /v4web.php jsChallenge
17 Firewall Rule 4984baee40b268fc January 13, 2019 01:20:59 (-02:00) /text.php jsChallenge
18 Firewall Rule 4984bb08157d68fc January 13, 2019 01:21:04 (-02:00) /system123.php jsChallenge
19 Firewall Rule 4984bb087314691a January 13, 2019 01:21:04 (-02:00) /prv.php jsChallenge
20 Firewall Rule 4984bb08858f68fc January 13, 2019 01:21:04 (-02:00) /v4web.php jsChallenge
21 Firewall Rule 4984bb09c2676908 January 13, 2019 01:21:04 (-02:00) /v4web.php jsChallenge
22 Firewall Rule 4984bb09c2c368ba January 13, 2019 01:21:04 (-02:00) /prv.php jsChallenge
23 Firewall Rule 4984bb25d55e6902 January 13, 2019 01:21:08 (-02:00) /system123.php jsChallenge
24 Firewall Rule 4984bb27e32268d8 January 13, 2019 01:21:09 (-02:00) /v4web.php jsChallenge
25 Firewall Rule 4984bb27e40c68b4 January 13, 2019 01:21:09 (-02:00) /text.php jsChallenge
26 Firewall Rule 4984bb27e5ad6902 January 13, 2019 01:21:09 (-02:00) /system123.php jsChallenge
27 Firewall Rule 4984bb2804f268ae January 13, 2019 01:21:09 (-02:00) /prv.php jsChallenge
28 Firewall Rule 4984bb29800e691a January 13, 2019 01:21:09 (-02:00) /text.php jsChallenge
29 User-Agent Blocking 4984bb4681f1692c January 13, 2019 01:21:14 (-02:00) /v4web.php Whitelist
30 Firewall Rule 4984bb4681e66956 January 13, 2019 01:21:14 (-02:00) /prv.php jsChallenge
31 Firewall Rule 4984bb4691e868f0 January 13, 2019 01:21:14 (-02:00) /text.php jsChallenge
32 Firewall Rule 4984bb4692a569ac January 13, 2019 01:21:14 (-02:00) /system123.php jsChallenge
33 Firewall Rule 4984bb47b04d68fc January 13, 2019 01:21:14 (-02:00) /prv.php jsChallenge
34 Firewall Rule 4984bb47c2666908 January 13, 2019 01:21:14 (-02:00) /system123.php jsChallenge
35 User-Agent Blocking 4984bb494b796932 January 13, 2019 01:21:14 (-02:00) /v4web.php Whitelist
36 User-Agent Blocking 4984bb65177d6956 January 13, 2019 01:21:18 (-02:00) /text.php Whitelist
37 Firewall Rule 4984bb6d17ea692c January 13, 2019 01:21:20 (-02:00) /prv.php jsChallenge
38 Firewall Rule 4984bb6d25e868d8 January 13, 2019 01:21:20 (-02:00) /system123.php jsChallenge
39 Firewall Rule 4984bb6f629568f0 January 13, 2019 01:21:20 (-02:00) /system123.php jsChallenge
40 Firewall Rule 4984bb6f662b6932 January 13, 2019 01:21:20 (-02:00) /prv.php jsChallenge
41 User-Agent Blocking 4984bb6fc9e06908 January 13, 2019 01:21:20 (-02:00) /text.php Whitelist
42 Firewall Rule 4984bb8ae5266902 January 13, 2019 01:21:24 (-02:00) /system123.php jsChallenge
#37

This is most likely intentional, @cbrandt. These bots are rarely well-programmed. That means they make silly mistakes: they might not stay on a page long enough, they might change their user agent, or they might discard their cookies. If any of these events occur, or if Cloudflare decides arbitrarily that the whitelist should expire early based on their own automated assessments, the whitelist entry will likely be dropped. At that point, the bot will receive additional challenges.

#38

In the table above, you can see a few instances where the bot came from some IP in France and the applied action was

  1. JS Challenge
  2. Whitelist

Now that I have that UA Block rule set to block, that same bot came back from same IP in France and the result was:

  1. JS Challenge
  2. Block

This only reinforce my suspicion that something may be wrong with the UABlock rule when set to JS Challenge, or with this rule when in combination with other rules.

1 Like
#39

I see a lot of bots, and this is relatively normal. They have very inconsistent behavior. They might be able to pass once because they stay on the page long enough, but then they might fail the next time because they leave the page too quickly.

Remember, the logs you’re seeing aren’t necessarily representative of a linear navigation path. It’s possible that the bot does the equivalent of having multiple tabs open in one scenario, but lacks that another time. It could also randomly decide to change its UA string or botch its cookies.

#40

If you are right about this behavior (and I hope you are), then CF should change the label it places on the log to something other than Whitelist.

Whitelist is one of the actions chosen by the user.

If my rule is met then Whitelist.

Cloudflare should instead use
jsChallenge > passed and jsChallenge > failed

or something abbreviated like
jsChallenge> / jsChallenge<

Anything but call it Whitelist, which creates confusion.

@alexcf mentioned the need for using passed/failed in another discussion.

If you are not right, then CF applied the action Whitelist when it shouldn’t and the issue should be further investigated by them.

1 Like
#41

Yeah, it should definitely be changed, especially given the incosistency with the firewall logs observed in the other thread.

Although the logs aren’t intuitive, I’m pretty sure the correct behavior is occurring.

1 Like
#42

Yup, same confusion,

#43

This topic was automatically closed after 30 days. New replies are no longer allowed.