Salta al contenuto

How to stop getting "Max Challenge Attempts Exceeded"

0

We use the ChallengeAction to block crawlers on our website, but it has false positives that we don't know what to do about. We haven't been able to reproduce them until today, so we're hopeful somebody can help us fix this.

The errors our users regularly see says:

Max challenge attempts exceeded. Please refresh the page to try again!

When users see this, it takes up the whole page. It's bad and we never know how to fix it either.

We finally have a way of reproducing it that another website sent us:

  1. Open an incognito tab and load this page from a website that links to ours: https://callidusai.com/wp/ai/cases/108713/roe-v-wade
  2. Click on 'View Full Case Test'
  3. This page from our website will load in another tab https://www.courtlistener.com/opinion/108713/roe-v-wade, and will show the error.

If you go back and try to press the button again, it works!

Does anybody know what's going on here? The AWS docs don't seem to have any advice and I don't think we're doing anything that unusual, but for some reason the challenge fails.

posta 2 mesi fa899 visualizzazioni
4 Risposte
1

This will be difficult to unpick without knowing what your WebACL configuration looks like but, at a first guess, as you are working with multiple domains, I would start by validating what domains you have configured in your token settings: https://docs.aws.amazon.com/waf/latest/developerguide/waf-tokens-domains.html#waf-tokens-domain-lists

AWS
con risposta 2 mesi fa
0

The issue you're experiencing with "Max challenge attempts exceeded" is related to how AWS WAF Challenge actions work with Single Page Applications (SPAs) or when making cross-domain requests.

When a user clicks on a link that opens your protected page in a new tab, the challenge may not complete properly before your application attempts to load resources. This happens because:

  1. The AWS WAF Challenge action requires JavaScript execution to complete a "proof of work" and generate a token (cookie called 'aws-waf-token')
  2. When opening a new tab via a link from another domain, this challenge process can fail if your application makes requests before the challenge completes

To fix this issue, you have a few options:

  1. Implement the AWS WAF JavaScript integrations in your application:
  • Use AwsWafIntegration.fetch wrapper to ensure the challenge completes before making fetch requests
  • Or use AwsWafIntegration.getToken() which returns a promise that resolves when the challenge completes
  1. Consider adjusting your Challenge rule configuration:
  • Rate-limit rules are more effective for triggering challenges against malicious bots
  • Avoid triggering challenges based solely on headers or user-agent strings
  • Be careful about implementing challenges on non-HTML content or API endpoints
  1. Ensure the challenge is only applied to appropriate requests:
  • The token can only be acquired via HTTP GET requests with the 'Accept' header containing 'text/html'
  • Don't configure a Challenge response for non-page requests unless you've already acquired the token

The reason it works on the second attempt is that the browser has already completed the challenge and stored the token as a cookie, which is then used for subsequent requests to your domain.
Sources
Optimizing web application user experiences with AWS WAF JavaScript integrations | Networking & Content Delivery
How to mitigate bot traffic by implementing Challenge actions in your AWS WAF custom rules | AWS Security Blog
DDoS Resilience - Using AWS WAF to protect against DDoS Botnets | AWS re:Post

con risposta 2 mesi fa
  • Thanks, this is helpful, but I don't think it will solve our problem. Our application is not a SPA, and we barely use any JavaScript. I also don't know how our application could be loading code before the challenge attempt completes, since we're doing this in an incognito window that wouldn't have any of our application's code in cache or anywhere else. I like the idea of using rate limit rules instead of the challenges, but we can't because we need protection from orgs that have millions of IP addresses (it's very annoying). Any other ideas?

0

The other domain is a partner that wants to link to us. I think a solution I found was to disable the challenge attempts if the referer is their domain.

That fixes the immediate problem, but we do still have users that run into this when simply loading the page and I'm not sure how to reproduce their issue. I assume it's a cookie/browser thing, but I don't have steps to reproduce yet, unfortunately.

con risposta 2 mesi fa
0

I was having the same problem and was able to recreate the issue on my iPhone 12 using Firefox, DuckDuckGo, and Brave.

The Athena query below helped tremendously. See here to create the Athena table required for it. It lists the host and all labels associated with Challenge requests from a specified IP address that was receiving the errors.

In my case, I noticed the label awswaf:managed:token:rejected:domain_mismatch. I believe it is related to an ALB redirect going from example.com to www.example.com, but that hasn't been confirmed.

My Fix:
I went to the CAPTCHA/Challenge configuration and added my apex host (example.com) to the Token domains list.

In your case, you might need to add your partner's apex domain also if you're experiencing the domain mismatch error. If not, I believe the query may guide you to a solution. I hope this helps.

Also, rereading best practices may help avoid placing challenges on pages that can't handle the interstitials properly(see below).

-- Athena Query
SELECT
  FROM_UNIXTIME(w."timestamp" / 1000) AS time,
  h.value AS host,
  l.name AS label_name
FROM waf_logs w
CROSS JOIN UNNEST(w.labels) AS t(l)
CROSS JOIN UNNEST(w.httprequest.headers) AS th(h)
WHERE w."date" = '2025/10/07'
  AND w.action = 'CHALLENGE'
  AND w.httprequest.clientip = '<ip address having issue>'
  AND lower(h.name) IN ('host', ':authority')
ORDER BY time DESC
LIMIT 200;

Decide where to run CAPTCHA puzzles and silent challenges on your clients

Configure your Challenge and CAPTCHA use so that AWS WAF only sends CAPTCHA puzzles and silent challenges in response to GET text/html requests. You can't run either the puzzle or the challenge in response to POST requests, Cross-Origin Resource Sharing (CORS) preflight OPTIONS requests, or any other non-GET request types. Browser behavior for other request types can vary and might not be able to handle the interstitials properly.

It's possible for a client to accept HTML but still not be able to handle the CAPTCHA or challenge interstitial. For example, a widget on a webpage with a small iFrame might accept HTML but not be able to display a CAPTCHA or process it. Avoid placing the rule actions for these types of requests, the same as for requests that don't accept HTML.

con risposta un mese fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.