XF 1.2 Server slowdown because of many POST <forum>/login/csrf-token-refresh requests (?)

[Erel]

We encountered a somewhat strange server issue.

In the last day or two our server is being bombarded with these requests. They come from a single IP address. The server was unresponsive until we blocked this IP address.

Later it happened with another IP address. I've installed mod_qos however it doesn't seem to help. Whenever I remove the IP blocking the server load jumps and we see the same request sent from the same IP address hundreds of times a minute.

Any help will be appreciated...

 

[Mike]

If it's happening 100s of times a minute, it sounds like there's something malicious -- or at least gone horribly wrong somewhere (probably client side). This is a call that is made in the background essentially once every 50 minutes at most (as in, it won't be made until a page is open for 50 minutes, and then only after another 50 minutes, etc).

 

[W1zzard]

I see several hundred of these requests from some IPs every day.

630 88.13.239.207 /forums/login/csrf-token-refresh
378 184.99.145.229 /forums/login/csrf-token-refresh
348 69.254.74.77 /forums/login/csrf-token-refresh
333 134.147.24.203 /forums/login/csrf-token-refresh
297 62.165.229.119 /forums/login/csrf-token-refresh
209 24.14.148.84 /forums/login/csrf-token-refresh

First number is the hit count in a 24 hour period

 

[Erel]

It was not anything malicious. I contacted the forum member. It seems like his Android tablet browser started sending these rapid requests for some unknown reason.

 

[W1zzard]

Oh yeah, I've seen some Android user agents in the logs for these accesses. @Mike Any thoughts what could cause it?

 

[Mike]

Well every browser will access it, but the question is how frequently. Hundreds of times per minute (continuously) isn't how it's supposed to work and seems to point to some sort of browser issue (not handling the timer as expected). I haven't reproduced an issue like that in Android.

I do see the occasional IP hitting it fairly extensively here. The code is designed to only run if the tab is focused, so switching to the tab would normally be required to trigger a refresh (after X amount of time). That's how it generally works for me, but I can see a case with this one particular IP/user where it's not doing that. It certainly looks like he has a huge number of tabs open. Note this person is running Chrome on Windows -- I didn't notice any significant number of Android calls to this.

Ideally, we need to come up with some sort of cross-tab communication technique so we only need to trigger this once for each browser instance.

 

[W1zzard]

Could the server response include some caching headers, so that the browser will fetch from cache until the timeout is expired?

 

[timothy259856]

Well every browser will access it, but the question is how frequently. Hundreds of times per minute (continuously) isn't how it's supposed to work and seems to point to some sort of browser issue (not handling the timer as expected). I haven't reproduced an issue like that in Android.

I do see the occasional IP hitting it fairly extensively here. The code is designed to only run if the tab is focused, so switching to the tab would normally be required to trigger a refresh (after X amount of time). That's how it generally works for me, but I can see a case with this one particular IP/user where it's not doing that. It certainly looks like he has a huge number of tabs open. Note this person is running Chrome on Windows -- I didn't notice any significant number of Android calls to this.

Ideally, we need to come up with some sort of cross-tab communication technique so we only need to trigger this once for each browser instance.

How about now? Does cross-tab communication technique exist in last version of XenForo? Because we just saw some strange action of csrf-token-refresh now!

 

[Xon]

https://github.com/slimjack/IWC
Something like this can do it. Only for modern browsers (and your usual laundry list of browser issues), but that is about all you can do.

Probably the most reliable solution is to actually use a cookie with the CSRF token (+ timestamp), and try to get it before doing a polling request.