Issues with JS challenge

This is causing all of our sites issues. Since the cf_chl_jschl_tk showed up, none of our basic HTTP AUTHs which occur after a challenge work right away. It takes several iterations to get it to work.

For example
– Say domain.com/admin has a site login page
– We put a CF challenge in front of that page
– When we visit the page, we get the CF browser challenge holding page
– Once it goes away, we actually get the HTTP AUTH pop-up in chrome
– Typing the correct login does noting, over and over
– But, hit cancel, wait about 10 seconds, then refresh
– You get the pop-up again, but this time when you enter good credentials, it lets you past

Turning off the page rule for /admin, which is where browser challenge and security level = UNDER ATTACK are active, fixes the problem immediately.

Please fix this.

@mdemoura, I somewhat seem to be able to confirm @kkcc’s observation.

The new challenge appears to POST the result. That appears to interfere with basic authentication, however it also makes it impossible to block POST requests with e.g. a firewall rule.

I guess the new challenge does need some overhaul :slight_smile:

I’m afraid I can’t reproduce your issue.

I created a worker that serves a 401 with WWW-Authenticate and enabled IUAM.
Opening the page gives the challenge and after my browser passes it I get the auth prompt. Entering my credentials yields the protected page, as expected.

Can you provide more information? Feel free to send me a private message.

This is not correct. You can use Firewall Rules to block POST requests as that won’t interfere with any of the challenges.

That does not seem to reflect my observation. The challenge shows up, but the subsequent POST is blocked.

@mdemoura, just open sitemeer.com with Firefox to reproduce the issue.

@sandro, if you move the rule that blocks POST requests to the end of the priority list (or at least after the rule that triggers the challenge), do you still experience the same issue?

I havent tried that, but I wouldnt want to tamper with the rules either at this point, however I somewhat doubt it would make a change. The issue is not that the challenge does not fire because of the POST block (it does), but rather that once the challenge fired the subsequent POST does not work because of aforementioned rule.

If I moved the rule that would effectively (almost) disable it, as there is a good chance the request will be caught by another rule earlier and never reach the POST block.

The issue, as far as I can tell, simply is the apparent change in the challenge approach with that mandatory POST now.

Below are two examples. The first one demonstrates the problem on a site that has the challenge page enabled in front of the login page. The second demonstrates nonexistence of the problem on a site the is not using the challenge page. However, the site used in the second example does present the problem when the challenge page is enabled.

Some information is redacted and highlighted by surrounding underscores _.

######## Server-side httpd logs

Instance WITH the problem (challenge enabled)

Initial load (while CF challenge page is pending)

REDACTED - - [04/Dec/2019:16:17:53 -0500] “GET https://DOMAIN_1/wp-admin” 301 178 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:-/0.000 XFF:REDACTED CFRAY:5400cf4a7d45e3ce-ATL
REDACTED - - [04/Dec/2019:16:17:53 -0500] “GET https://DOMAIN_1/wp-admin/” 302 5 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:0.000/0.001 XFF:REDACTED CFRAY:5400cf4acde9e3ce-ATL
REDACTED - - [04/Dec/2019:16:17:53 -0500] “GET https://DOMAIN_1/wp/wp-admin/” 302 5 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:0.200/0.199 XFF:REDACTED CFRAY:5400cf4b0e7be3ce-ATL

After challenge page complete, these are the requests which result in the 401 (auth required) response. Here you are seeing the first attempted load, plus 3 requests where I have actually submitted the login info.

REDACTED - - [04/Dec/2019:16:17:58 -0500] “GET https://DOMAIN_1/wp/wp-login.php?redirect_to=https%3A%2F%2F_DOMAIN_1_%2Fwp%2Fwp-admin%2F&reauth=1” 401 590 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:-/0.000 XFF:REDACTED CFRAY:5400cf65fc69e3ce-ATL
REDACTED - - [04/Dec/2019:16:18:04 -0500] “GET https://DOMAIN_1/wp/wp-login.php?redirect_to=https%3A%2F%2F_DOMAIN_1_%2Fwp%2Fwp-admin%2F&reauth=1” 401 590 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:-/0.000 XFF:REDACTED CFRAY:5400cf8c1a21e3ce-ATL
REDACTED - - [04/Dec/2019:16:18:05 -0500] “GET https://DOMAIN_1/wp/wp-login.php?redirect_to=https%3A%2F%2F_DOMAIN_1_%2Fwp%2Fwp-admin%2F&reauth=1” 401 590 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:-/0.000 XFF:REDACTED CFRAY:5400cf96090de3ce-ATL
REDACTED - - [04/Dec/2019:16:18:07 -0500] “GET https://DOMAIN_1/wp/wp-login.php?redirect_to=https%3A%2F%2F_DOMAIN_1_%2Fwp%2Fwp-admin%2F&reauth=1” 401 590 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:-/0.000 XFF:REDACTED CFRAY:5400cf9e3b41e3ce-ATL

Once the 3 logins failed, I hit cancel so that no more requests are sent. Then I wait a couple seconds, go to the URL/Address bar, hit enter to visit the page. The HTTPAUTH login prompt pops up, I input a correct login, and you see the very next request actually shows success (HTTP 200). *** Take note of the fact that now the USERNAME is only now being recognized at the destination server with the request

REDACTED - - [04/Dec/2019:16:18:14 -0500] “GET https://DOMAIN_1/wp/wp-login.php?redirect_to=https%3A%2F%2F_DOMAIN_1_%2Fwp%2Fwp-admin%2F&reauth=1” 401 590 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:-/0.000 XFF:REDACTED CFRAY:5400cfcc3d33e3ce-ATL
REDACTED - USERNAME [04/Dec/2019:16:18:16 -0500] “GET https://DOMAIN_1/wp/wp-login.php?redirect_to=https%3A%2F%2F_DOMAIN_1_%2Fwp%2Fwp-admin%2F&reauth=1” 200 1290 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:0.208/0.208 XFF:REDACTED CFRAY:5400cfd96b35e3ce-ATL
REDACTED - USERNAME [04/Dec/2019:16:18:16 -0500] “GET https://DOMAIN_1/wp/wp-admin/load-styles.php?c=1&dir=ltr&load%5B%5D=dashicons,buttons,forms,l10n,login&ver=4.7.2” 200 38637 “https://DOMAIN_1/wp/wp-login.php?redirect_to=https%3A%2F%2F_DOMAIN_1_%2Fwp%2Fwp-admin%2F&reauth=1” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:0.012/0.013 XFF:REDACTED CFRAY:5400cfdafee9e3ce-ATL

Instance WITHOUT the problem (challenge disabled)

Initial load. No CF challenge page involved, so we immediately get a HTTP 401 rather than HTTP 302 for the challenge page

REDACTED - - [04/Dec/2019:16:27:02 -0500] “GET https://DOMAIN_2/wp-admin/” 302 5 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:0.016/0.018 XFF:REDACTED CFRAY:5400dcb11bf73880-ATL
REDACTED - - [04/Dec/2019:16:27:02 -0500] “GET https://DOMAIN_2/wp-login.php?redirect_to=https%3A%2F%2F_DOMAIN_2_%2Fwp-admin%2F&reauth=1” 401 590 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:-/0.000 XFF:REDACTED CFRAY:5400dcb18c303880-ATL

Entering the correct login, it works the first time. The username is recognized and permitted to fetch the page.

REDACTED - USERNAME [04/Dec/2019:16:27:07 -0500] “GET https://DOMAIN_2/wp-login.php?redirect_to=https%3A%2F%2F_DOMAIN_2_%2Fwp-admin%2F&reauth=1” 200 1112 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:0.024/0.023 XFF:REDACTED CFRAY:5400dcd15ca33880-ATL
REDACTED - USERNAME [04/Dec/2019:16:27:07 -0500] “GET https://DOMAIN_2/wp-admin/load-styles.php?c=1&dir=ltr&load%5B%5D=dashicons,buttons,forms,l10n,login&ver=4.9.4” 200 38631 “https://DOMAIN_2/wp-login.php?redirect_to=https%3A%2F%2F_DOMAIN_2_%2Fwp-admin%2F&reauth=1” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36” – RQT:0.004/0.005 XFF:REDACTED CFRAY:5400dcd1ecd73880-ATL

Is this going to be addressed any time soon? Please provide an update.

Thank you.

Hi @kkcc, I managed to reproduce the issue with your specific config. This will be addressed in a release this week.

1 Like

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