2

I'm getting a periodic issue with my IIS hosted website whereby one of my clients browsers (Google Chrome 77/78 or higher) suddenly begins submitting dozens of requests per second to my website for the same page.

The user is always a valid, authenticated user with my application. The requests also don't seem to follow any standard pattern that I can determine from our logs. For instance, it's not a authorization redirect issue for instance, it's almost like the browser is sending through dozens of requests which have somehow been initiated by the user. For instance, opening a bookmarked version of our page dozens of times.

Looking at the request details I can see the following fetch headers:

   HTTP_SEC_FETCH_USER: ?1
   HTTP_SEC_FETCH_SITE: none
   HTTP_SEC_FETCH_MODE: navigate

Which from what I can understand means that the action was user-initiated, and that it did not come from my own application, in terms of a ajax request or page refresh. I can only get the above combination of fetch headers when I open my page in a new tab in Chrome for instance.

Could this actually be related to the Chrome browser itself? I cannot replicate the issue in development, but it's happened a few times now and I'm not sure where to start in terms of determing a cause.

Gary
  • 742
  • 8
  • 20
  • Chrome claims to be preloading pages (even if links are not really clicked by users), so such magic can backfire significantly if it predicts wrongly, and you might have no way to fix that on IIS side. – Lex Li Nov 25 '19 at 14:19
  • Hi Lex, yes, this was one of the first things I suspected, but I cannot tell if it's the case. Fortunately I now have throttling code in place that appears to prevent a massive flood - but really interested to know why this happens. – Gary Nov 25 '19 at 14:22
  • Do you have a Service Attack? – jdweng Nov 25 '19 at 14:32
  • Why do you think it's Chrome? Agents can be faked. I would look at the client machine and see if there is malware or something on that client machine. Maybe an extension that was installed? – JAZ Nov 25 '19 at 14:47
  • Hi JAZ and jdweng. Because the request is authenticated, it's unlikely to be a dos attack, but yes, it could be a broken extension or malware on the affected client. That's something I will have to check if possible. – Gary Nov 25 '19 at 17:39
  • Have you found out reason/solution? I'm facing similar problem: https://stackoverflow.com/questions/71078285/google-oauth-callback-flood @Gary – user3686724 Feb 16 '22 at 09:08
  • @user3686724 unfortunately there is no simple fix for this. I still get these issues intermittently and I suspect they are caused by new 'features' in modern browsers. Lately, I've been getting them from the latest mobile Safari. I would recommend you implement a throttling mechanism as described here https://stackoverflow.com/questions/33969/best-way-to-implement-request-throttling-in-asp-net-mvc/1318059#1318059 since implementing this it's helped resolve the issue. – Gary Feb 17 '22 at 06:31
  • @Gary I ended with token-bucket rate limiting as well. Besides I pushed issue to Google support and they seem willing to help, but only with recorded dev console network log/HAR file. If you could somehow reproduce the issue, would you be willing to share recorded devconsole/network HAR file for further investigation? Thank you – user3686724 Feb 18 '22 at 12:32
  • @user3686724 unfortunately I cannot replicate the issue reliably either. So for now, we are stuck with rate limiting. – Gary Feb 18 '22 at 13:31
  • @Gary After I turned on rate-limiting, there is some interesting change, so far without any limits, there was endless count of these flood requests, as long as they were receiving some ok http response (302 redirect), but after rate-limiting was put in place and returns http 429 too many requests, this flood immediately stops. So there is few "flood" requests with http 302 and after first http 429 the flood immediately terminats - does your flooding act like this too? – user3686724 Feb 21 '22 at 08:09
  • @user3686724 In my case I have to redirect to an html page, so I can't just return a 429. But it's good to know that google appears to process a 429. – Gary Feb 22 '22 at 09:05

1 Answers1

1

As other users have pointed out in comments, this can be in fact caused by Mobile Chrome Predictive Loading mechanism.

A recent version of Chrome for Android (78.0.3924.108) has experimented with predictive loading, changing the rules when links are selected for prefetching. This can cause arbitrary links to be "loaded" (issuing a GET request, distorting stats and causing any side effect that action has) without any user input when visiting your website.

This has been rolling out over the past week, and has caused many issues in many different scenarios (logging users out, clicking on paid or aggregator links, etc.)

More info on the Chromium issue tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=1027991

Requests made by prefetching issue a Purpose: prefetch header - at least by Chrome, other browsers might issue other headers

This has since then been fixed today morning (25th november 2019).

Null Reference
  • 79
  • 2
  • 6
  • Unfortunately I've witnessed the behaviour from Chrome 77 and 78. Over the course of 2 months it's occurred around 3 times, and the error we get when the request is throttled does not include a Purpose: prefetch header. So possibly not related to this. – Gary Nov 25 '19 at 17:37
  • 1
    All right, too bad. What I described hit us, so I'll leave it here for now in case it helps anyone else. – Null Reference Nov 25 '19 at 18:23