The dev console returns a CORS error which looks like this:
Access to XMLHttpRequest at 'https://api.domain.com/login/' from origin 'https://domain.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Am I missing some sort of headers on the initial GET request to the initial login page? Or on the POST request? I tried using “HTTP Response Header Modification rule” but don’t think it works at all. Adding an Response header for Access-Control-Allow-Origin: * did not help change anything.
If the user got challenged initially when requesting the log page (entire page via GET), it’s all good (they get the challenge screen). The problem comes when CF initially let the user load the page (not challenged on GET), and then blocks any subsequent POST requests the user makes within that page (login, upload content, send message, etc.).
Blockquote Why not challenge the entire page no matter it is GET or POST?
Aside from the login request/page, this happens across other routes/post requests. So it’s hard to create a rule which encapsulates all that.
In our case, it’s a react app (the page does not refresh upon any request or redirect). I probably should have pointed that out sooner. I tried replicating this on a Wordpress site (wp-login) and since the page itself refreshes after a login POST request, the challenge page gets rendered successfully.
I was thinking of creating a JS handler that tells the browser to redirect the user to a challenge page (custom firewall rule for a special path where everyone is challenged).
@user5905 This is a “known issue” in many CMS (forums, blogs, etc). You might be performing everyday actions, and suddenly, progress is lost due to the challenge expiring or facing a new one .
There is no proper way to fix it without introducing issues. However, you can try the following.
Check if the session cookie is present and bypass the firewall based on that.
Increase the challenge passage significantly.
An intelligent attacker could notice (1) and inject that cookie; in that case, you would have to either deploy more detailed rules or temporarily remove it.
The second approach could make launching attacks towards your site cheaper and easier to abuse.
Overall to have it exploited, you need somebody to specifically target your site and notice the “hole” you are introducing, very unlikely unless you face daily/weekly attacks.
We’ve experienced a series of attacks. One of the more recent ones bypassed Cloudflare with a 99.4% success rate (direct to API). Around 36 million requests over the course of the weekend (4 waves). Rate limiting rules were of no use as the attackers used over 10k different IPs.
I came up with a solution that seems to have fixed the issue:
created a page “/challenge” with one single function - redirect back to referrer URL. This was done at React app level, although it can be done at NGINX and CF worker level as well.
added a custom firewall rule for the /challenge path to challenge all requests
added a handler to all our app pages to redirect the browser to /challenge when/if CORS issues are returned on POST requests within the page.
This way, if a user gets this error, he is directed to /challenge where he must solve it, after which he is redirected back to the referrer page where he initially encountered this issue (but this time with a validated/revalidated certificate).
That sounds like a challenging attack to mitigate; what plan are you in? Can you show the firewall tab if you are in a paid package? Even if only 0.6% was mitigated, it might be enough to see patterns in the attack.
Pro plan. Unfortunately, can’t go back that far (72 hours max as I recall).
Fortunately, we use Kibana for logging and were able to segregate and analyze the patterns of all that traffic. I will share a report within this thread shortly.
.