The Blogsphere - How pingbacks work

03 May 2019 - tsp

Pingbacks are one of the core features of providing automated social interconnections between different blog pages in the blogsphere. They are formally specified at http://www.hixie.ch/specs/pingback/pingback. Pingback offers an automated way to ping all pages that are linked inside an blog entry about them being linked. This allows the called page to first verify that this is indeed the case, fetch some metadata about the page that links it and if it wants to it allows this page to add a list of pages that reference if (for example as an this article is mentioned by section or similar)

Pingback is normally implemented by your content management system or your static site generator. It processes your blog posts or webpage content, optionally verifies it against a blacklist (or a list of previously pinged resources), fetches the remote webpage and checks either for an HTTP header (X-Pingback or an meta information element <link rel="pingback" href="...">. Either mechanism may be used (of course as always the HTTP header is highly encouraged if possible in any way). This element references to an XML-RPC API endpoint that will be used to deliver the endpoint.

The XML-RPC API endpoint provides a single interface for the pingback.ping function. This function has the signature

String pingback.ping(String sourceURI, String targetURI)

The parameter sourceURI is the URI of the post that contains the link to the target site, targetURI is the absolute URI of the target of the link as given on the source page. Note that these links may have to be renormalized by the endpoint to be easily compareable.

In case the pingback is successful the server has to respond with a single string that contains as much information as the server deems useful (this is expected to be used for debugging purposes). In case of an failure the server must respond with an RPC fault value (see below). Clients should not show the response of a successful request to the user.

The request may do whatever the server desires to do with it. Recommended behaviour is:

How does the XML-RPC request look like

The request normally is a plain simple XML-RPC request:

?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
 <methodName>pingback.ping</methodName>
 <params>
  <param>
   <value>
    <string>http://source/url/here</string>
   </value>
  </param>
  <param>
   <value>
    <string>http://target/url/here</string>
   </value>
  </param>
 </params>
</methodCall>

The response can be either a successful response or a fault code. In case of an error:

<?xml version="1.0"?>
<methodResponse>
 <fault>
  <value>
   <struct>
    <member>
     <name>faultCode</name>
     <value><int>17</int></value>
    </member>
    <member>
     <name>faultString</name>
     <value><string>No link from source to target found</string></value>
    </member>
   </struct>
  </value>
 </fault>
</methodResponse>

In case everything went well:

<?xml version="1.0"?>
<methodResponse>
 <params>
  <param>
   <value>
    <string>Pingback successful</string>
   </value>
  </param>
 </params>
</methodResponse>

Spam

Note that pingbacks can - of course - originate from everywhere. Since many pages decide to show pingback sources after checking that the link is present the pingback might be used to distribute spam. One can use different countermeasures for that:

Amplification attack

An naively implemented pingback module can be used to amplify an DDoS attack because it allows for easy redirection of requests - and requests are usually smaller than responses. To counter that keep track of which resources have been queried after requests and employ rate limiting (do that on a per domain basis if possible). It’s also a good idea to implement blacklisting of domains in case you are using an affilate partner or similar services which you really don’t want to ping.

This article is tagged: Web, Programming


Dipl.-Ing. Thomas Spielauer, Wien (webcomplains389t48957@tspi.at)

This webpage is also available via TOR at http://jugujbrirx3irwyx.onion/

Valid HTML 4.01 Strict Powered by FreeBSD IPv6 support