admin-ajax.php should only execute for browser traffic

[WebsitesbyMark]

At the moment admin-ajax.php is used for a variety of tasks in WordPress and plugins.

This means if a site is attacked admin-ajax.php can be flooded with requests which can be enough to take a site offline.

Normally with these sorts of attack the requests wont come from a browser and therefore if WordPress looked to detect access from a browser before executing the code it would stop a lot of the issues that are happening at the moment.

My clients site was taken offline for a week recently during a large attack. The hosting company identified the issue as the admin-ajax.php being hammered.

We had installed WordFence, Super cache, heartbeat control and CloudFlare without much luck. (without cloudflare the site refused to stay up, and would only stay up in under attack mode)

Within cloud flare we managed to configure so cloudflare would only allow browser based traffic to *domain.com/wp-admin/* this immediately solved the issue.

Thinking about it only browsers can utilise ajax therefore if it could be rigged to only execute when there is browser traffic this would then be a bit of a non issue.

[dd32]

As straight forward as this may seem, it's not possible to distinguish Browser traffic from malicious traffic in a PHP application. Cloudflare can do it as they have many network heuristics running which can block traffic at a lower layer than WordPress can see.

Additionally, due to the number of plugins in existence which rely on access to the file, we can't block it for logged out users either, which means we don't really have any methods which we can use to prevent a resource exhaustion attack such that you described.

A Server configuration to rate-limit the number of requests to admin-ajax could help, but once again that's not something WordPress can alter.

I'm marking as invalid for now, based on the technical limitations which WordPress operates under, if someone comes up with a solution they're free to re-open the ticket, but remember that all malicious scripts can pretend to be a browser and act the same.

[WebsitesbyMark]

With respect I don't agree if you look at ​http://php.net/manual/en/function.get-browser.php you can see its possible, and if this method is not seen as doable in all situations, you could include an wp-config option to check for browser connection. This would give users the option to use this check or not.

[WebsitesbyMark]

With respect I don't agree if you look at ​http://php.net/manual/en/function.get-browser.php you can see its possible, and if this method is not seen as doable in all situations, you could include an wp-config option to check for browser connection. This would give users the option to use this check or not.

[mdgl]

Hello Mark, function get_browser() just looks up browser capabilities in a local database, normally using the HTTP request header User-Agent which you can obtain from $_SERVER['HTTP_USER_AGENT'].

Unfortunately, there is nothing to stop a hacker or malicious script from supplying any value of User-Agent to impersonate a particular browser application. This happens quite often and browsers are also known to impersonate each other! See the section on "User agent spoofing" at ​http://en.wikipedia.org/wiki/User_agent.

It is not therefore possible to determine whether a particular HTTP request is made by a human through a browser in this way.