Pingback

A pingback is one of four types of linkback methods for Web authors to request notification when somebody links to one of their documents. This enables authors to keep track of who is linking to, or referring to their articles. Some weblog software and content management systems, such as WordPress, Movable Type, Serendipity, and Telligent Community, support automatic pingbacks where all the links in a published article can be pinged when the article is published. Other content management systems, such as Drupal and Joomla, support pingbacks through the use of addons or extensions.

Essentially, a pingback is an XML-RPC request (not to be confused with an ICMP ping) sent from Site A to Site B, when an author of the blog at Site A writes a post that links to Site B. The request includes the URI of the linking page. When Site B receives the notification signal, it automatically goes back to Site A checking for the existence of a live incoming link. If that link exists, the pingback is recorded successfully. This makes pingbacks less prone to spam than trackbacks. Pingback-enabled resources must either use an X-Pingback header or contain a element to the XML-RPC script.

History

The Pingback specification was developed in 2002 by Stuart Langridge, Simon Willison, and Ian Hickson.

Exploits

In March 2014, Akamai published a report about a widely seen exploit involving pingback that targets vulnerable WordPress sites. This exploit led to massive abuse of legitimate blogs and websites and turned them into unwilling participants in a DDoS attack. Details about this vulnerability have been publicized since 2012, with Akismet reporting in 2013 that "almost 100% of trackbacks and pingbacks are spam".

The pingback attacks consist of "reflection" and "amplification": an attacker sends a pingback to a legitimate Blog A, but providing information of the legitimate Blog B (impersonation). Then, Blog A needs to check Blog B for the existence of the informed link, as it's how the pingback protocol works, and thus it downloads the page off Blog B server's, causing a ''reflection''. If the target page is big, this ''amplifies'' the attack, because a small request sent to Blog A causes it to make a big request to Blog B. This can lead to 10x, 20x, and even bigger amplifications (DoS). It's even possible to use multiple reflectors, to prevent exhausting each of them, and use the combined amplification power of each to exhaust the target Blog B, being by overloading bandwidth or the server CPU (DDoS).

WordPress changed a bit how the pingback feature works to mitigate this kind of vulnerability: the IP address that originated the pingback (the attacker address) started being recorded, and thus shown in the log. Notwithstanding, in 2016, pingback attacks continued to exist, supposedly because the website owners don't check the user agent logs, that have the real IP addresses. It has to be noted that, if the attacker is more than a script kiddie, he will know how to prevent his IP address being recorded, by, for example, sending the request from another machine/site, so that this machine/site IP address is recorded instead, and the IP logging then, becomes less worthy. Thus, it's still recommended to disable the pingbacks, to prevent attacking other sites (although this does not prevent being target of attacks).

See also

* Weblogs.com, an earlier XML-RPC interface for weblogs to send pingbacks.

* Webmention, a modern re-implementation of Pingback using HTTP and x-www-urlencoded POST data.
* Linkback, the suite of protocols that allows websites to manually and automatically link to one another.
* Refback, a similar protocol but easier than pingbacks since the site originating the link doesn't have to be capable of sending a pingback.
* Trackback, a similar protocol but more prone to spam.
* Search engine optimization

References

External links

Documentation: Trackbacks / Pingbacks in SerendipityWordPress Codex specificationsPingback Specifications

Blogs
WordPress
Drupal

{{internet-publish-stub