[wp-trac] [WordPress Trac] #35532: Additional Security for XML-RPC to Prevent High Server Load - Specifically Pingbacks

[WordPress Trac]

#35532: Additional Security for XML-RPC to Prevent High Server Load - Specifically
Pingbacks
------------------------------+-----------------------------
 Reporter:  own3mall          |      Owner:
     Type:  enhancement       |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  Pings/Trackbacks  |    Version:  4.4.1
 Severity:  normal            |   Keywords:
  Focuses:                    |
------------------------------+-----------------------------
 XML-RPC requests need additional security to prevent high system resource
 usage on web hosting servers.

 Under Discussion settings, there are two settings:

 Attempt to notify any blogs linked to from the article
 Allow link notifications from other blogs (pingbacks and trackbacks) on
 new articles

 Even with both of these settings disabled OR enabled, XML-RPC pingback
 POST requests received in small increments (say 4 requests per second) can
 overwork the server resulting in a Linux server load increasing from under
 0.50 to anywhere between 5-15 from a single abuser targeting a single
 installation of WordPress.  The processing required for handling these
 requests needs to be more efficient.

 Recently, several installations of WordPress on my shared web hosting
 server have been under attack with bogus pingback requests sent repeatedly
 many times per second.  For some reason, the logic handling these requests
 is causing too much processing to happen on the server resulting in the
 server load heavily increasing until the exploiter's IP address is banned
 (via iptables) or the Disable XML-RPC Pingbacks plugin is installed
 ([https://wordpress.org/plugins/disable-xml-rpc-pingback/]).  Asking all
 of my shared hosted users to install this plugin isn't a solution to this
 problem.  It's merely a work-around.

 Here is an idea to keep the web server from working too hard to process
 these requests:

 Write a file when a pingback request is received with the name of
 {IP_ADDRESS}.txt which contains a timestamp. {IP_ADDRESS} being the IP
 address from the client sending the request (PHP can grab this easily).
 When a pingback request is received, we check to see if the file exists,
 and if it does, we check to see if the current timestamp is greater than
 the old timestamp + 60 seconds. If it's not, we do NOT process this
 request at all because not enough time has passed. If it is, we process
 the pingback and write the new timestamp to the file. If the file doesn't
 exist, we create the file with the current timestamp and process the
 request. Then, WordPress could run a "cron" like function like it does for
 updating WordPress to delete these files to cleanup every once in a while.
 This will limit a source to one pingback request per minute, which seems
 more than fair. File system operations are very fast and so are timestamp
 operations, so I could see this working. This would also prevent a single
 attacker or multiple attackers from having a noticeable impact on the
 server.  This solution could also be implemented database side assuming
 this isn't the reason for the high server load in the first place
 (initialization of the database).

 Please see these two topics for additional details (including packet
 captures) of how this problem is affecting a lot of installations:

 [https://wordpress.org/support/topic/wordpress-moderators-censoring-not-
 caring-about-important-security-issues?replies=20]

 [https://wordpress.org/support/topic/wordpress-44-xml-rpc-exploits-still-
 not-fixed?replies=25&view=all]

 I think this is an important issue that needs to be addressed.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35532>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform