SyncAttackData query parameters

Hi Caleb,

I thought this sounded a bit odd so I reached out to QA to make sure. The syncAttackData call isn’t supposed to appear in the page source for visitors. It does not normally do that. However, it can do that if your site is not able to make the call in the normal way. So if your site defaults to showing the script in HTML it means syncAttackData is not running as it should. It could mean the site is blocking it’s own IP for example, or it could be something else that is interfering with it.

It is not blocking its own IP. Callbacks is used for many other things.

Did some quick debug, and here is the real rub for future reference of others.

On a multi-site install, all sites were moved to use SSL/https.
The htaccess for all was updated to redirect any attempts to access https:// over to https:// All sites have been running fine on https only for a long time, everyone happy. Except WordFence apparently. ??

In WordPress, all sites but ONE (main domain), had also had site-info edited for options/meta tables to point to the https:// locations. All EXCEPT the main site, which WordPress do not allow you to edit in WordPress site settings. It for some odd reason must be handled by manually rooting around and hand-editing meta-values in the raw tables.

Anyway.. Since all sites were happily running on https, that last manual database edit was never done, and so any calls to “home_url()” for that site would return the https:// version. Never noticed, because any such attempt was happily redirected onto https:// by htaccess. ?? Everything working fine.

Except now, that leads us back to WordFence. ??

WordFence issues a non-blocking POST (not a GET) to call home_url(‘/’) with wordpress_syncattackData as a query parameter. I am not sure why it is a POST, since it is not actually “Posting” any data. At least at first glance it seems a GET would work just as well, and it would follow the redirects..

wp_remote_post(add_query_arg('wordfence_syncAttackData', microtime(true),
      home_url('/')), array(
		'timeout'   => 0.01,
		'blocking'  => false,
		'sslverify' => apply_filters('https_local_ssl_verify', false)
));

But on the un-edited site, a POST to https:// is met with a 301 Redirect. Repeatedly.
Since a POST, unlike a GET, is not allowed to follow the redirect to the better location, it instead fails. Unseen anywhere, since it is a non-blocking call. The attempt just vanishes into the blue yonder. No failures logged anywhere.

WordFence then VERY quickly counts to 10 (attempts), goes into panic mode, and start echo’ing it’s call-pattern through JS script calls into the page-source to instead be visible and called by real visitors. Which is how GoogleBot finds the WordFence link in the page-code. ??

Interesting analysis Caleb. I’ll pass it to QA in case it’s something we can improve at some point.

Thanks for your contribution!

In that case, I should probably point out why I used the term “VERY quickly” above.

The attempts are “protected” by this code:

if (empty($_GET['wordfence_syncAttackData'])) {
   $lastAttackMicroseconds = $wpdb->get_var("SELECT MAX(attackLogTime) FROM {$wpdb->base_prefix}wfHits");
   if (get_site_option('wordfence_lastSyncAttackData', 0) < time() - 4) {
      if ($waf->getStorageEngine()->hasNewerAttackData($lastAttackMicroseconds)) {
         if (get_site_option('wordfence_syncingAttackData') <= time() - 60) {

The ‘wordfence_syncingAttackData’ timestamp is used to assure that there is 60 seconds since the last “attempt”.

It is reset/changed only when the query parameter is actually met.
However, because of the 301s, no call is ever seen initially, so the above code, which is seen on every normal user-page call instead waits 60 seconds between attemp #1 and #2. But the timer (wordfence_syncingAttackData) is only reset when the Sync query arg is actually seen.

The result is, that after the first 60 seconds wait, the remaining attempt counts (#3-#10) happen just as quickly as incoming users can call for pages. Those attempts see that the timer is STILL past 60 seconds, and so go ahead with a new call.
Hence there is no 60 second wait between all those remaining POST attempts. Confirmed by Apache access logs, which shows the WordFence generated calls being issued, and then attempted redirected to https by htaccess. Redirects never received or acted upon.
But the calls show up in very quick succession, since a new “attempt” is done on EVERY pass through, after that initial 60 second wait.