Linkback

From Wikipedia, the free encyclopedia
Jump to: navigation, search

A linkback is a method for Web authors to obtain notifications when other authors link to one of their documents. This enables authors to keep track of who is linking to, or referring to, their articles. The four methods (Refback, Trackback, Pingback and Webmention) differ in how they accomplish this task.

"LinkBack" is the generalized term used to reference three methods of communication between websites.

Any of the four terms—Linkback, Trackback, Pingback, or (rarely) Refback—might also refer colloquially to items within a section upon the linked page that display the received notifications, usually along with a reciprocal link; Trackback is used most often for this purpose. Also, the word Trackback is often used colloquially to mean any kind of Linkback.

Dan Magarino, Morgan Stanley Equity Research, is credited with popularizing the term "linkback" and also contributed to its widespread adoption by RiXML.org.

Refback Trackback Pingback Webmention
Trigger mechanism Visitor to linking site clicks on the link, and his browser takes him to the linked site Code on linking server examines added or updated documents, extracts links, and sends notification to linked server for each link found Code on linking server examines added or updated documents, extracts links, and sends notification to linked server for each link found Code on linking server examines added or updated documents, extracts links, and sends notification to linked server for each link found
Notification medium HTTP referrer value HTTP POST[1] XML-RPC call HTTP POST with source and target parameters[2]
Capture mechanism Examination of incoming HTTP referrer values Trackback capture script XML-RPC function Webmention capture script
Information sent by linking server None
  • Linking site name (Optional)
  • Linking post title (Optional)
  • Linking post excerpt (Optional)
  • Linking post URL
  • Linked post URL
  • Linking post URL
  • Linked post URL (target)
  • Linking post URL (source)
Additional information presented to linked server HTTP referrer sent by a visitor's browser upon clicking the link IP address of linking server IP address of linking server IP address of linking server
Autodiscovery mechanism (how the linking server finds out how and where to send the notification) None LINK tag in the header of the linked page or Trackback RDF Documents Special HTTP header or LINK tag on the linked page HTTP Link header or link element on the linked page
Action required when notification is received
  • Extract referrer value from incoming HTTP headers
  • Retrieve referring page
  • Parse retrieved page for desired information
  • Gather desired information from
    • Given parameters
    • or retrieving and parsing the given URL
  • Retrieve page at "linking post URL"
  • Parse retrieved page for desired information
Verifying that linking page does indeed link to linked page is recommended, not explicitly required
Advantages Requires no special code on linking server (the link itself becomes the notification when someone clicks on it) All the information desired by the linked server (Linking site name, post title, excerpt) is present in the notification itself
  • Notification mechanism has a complete technical specification
  • Less susceptible to spamming
  • Uses well-known parts of HTTP wherever possible (autodiscovery, encoding of data, response status)
  • Reuses Pingback’s existing semantics
  • Minimum amount of data transferred on-the-wire
Disadvantages
  • No notification unless someone actually clicks on the link
  • Relies upon visitors' browsers sending proper HTTP referrer information
  • Linked site must retrieve and parse linking site's page to extract the information it wants
  • Notification requires positive action by linking server
  • Notification mechanism has only a partial technical specification
  • Autodiscovery information may prevent XHTML validation
  • Notification requires positive action by linking server
  • Linked site must retrieve and parse linking site's page to extract the information it wants
  • Can be abused for DDOS attacks [3][4][5][6][7][8]
  • Relatively new, so less widely implemented.

See also[edit]

References[edit]

  1. ^ "Trackback specification draft". 
  2. ^ "Webmention Specification". 
  3. ^ Daniel Cid (February 17, 2016). "WordPress Sites Leveraged in Layer 7 DDoS Campaigns". Sucuri. Retrieved 2 February 2017. Despite the potential reduction in value with the IP logging, attackers are still using this technique. Likely because website owners rarely check the user agent logs to derive the real IP address of visitors. [...] Although it is great that WordPress is logging the attacker IP address on newer releases, we still recommend that you disable pingbacks on your site. It won’t protect you from being attacked, but will stop your site from attacking others. 
  4. ^ Tim Butler (25 Nov 2016). "Analysis of a WordPress Pingback DDOS Attack". Conetix. Retrieved 2 February 2017. Unless the attacker is very, very naive however, this IP will simply trace back to another infected machine or site. Generally these requesting systems are part of a botnet to mask and distribute the requests. [...] The pingback tool within WordPress still remains an exploitable system for any WordPress site which hasn’t explicitly stopped it. From a web host’s perspective, this is quite frustrating. 
  5. ^ Brenner, Bill. "Anatomy of Wordpress XML-RPC Pingback Attacks". The Akamai Blog, March 31, 2014 5:42 AM. Retrieved July 7, 2014. 
  6. ^ Cid, Daniel. "More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack". Sucuri Blog, March 10, 2014. Retrieved July 7, 2014. 
  7. ^ Calin, Bogdan. "WordPress Pingback Vulnerability". Accunetix, December 17, 2012 - 01:17pm. Retrieved July 7, 2014. 
  8. ^ Krassi Tzvetanov (May 4, 2016). "WordPress pingback attack". A10 Networks. Retrieved 2 February 2017. This issue arises from the fact that it is possible for an attacker A to impersonate T's blog by connecting to R's blog and sending a link notification that specifies T's blog as the origination of the notification. At that point, K will automatically attempt to connect to T to download the blog post. This is called reflection. If the attacker were careful to select a URL that has a lot of information in it, this would cause amplification. In other words, for a relatively small request from the attacker (A) to the reflector, the reflector (R) will connect to the target (T) and cause a large amount of traffic. [...] On the reflector side for the 200-byte request, the response can easily be thousands of bytes – resulting in a multiplication that starts in the 10x, 20x and more. [...] To avoid overloading the reflector, multiple reflectors can be employed to scale up. Thus, the target will have their outgoing bandwidth, and possibly compute resources, exhausted. [...] Another point to consider is the compute resources tied to the target side. If considering a page that is computationally expensive to produce, it may be more efficient for the attacker to overload the CPU of a system versus the bandwidth of the connection. [...] This is not the first time a CMS, and in particular WordPress, has been used for DDoS or other malicious activity. To a very large extent, this is because WordPress appeals to users that do not have the resources to manage their websites and they often use WordPress to make their job easier. As a result, many users do not have an adequate patch management program or proper monitoring to observe irregularities in their traffic.