Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Pingback
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{Short description|Type of linkback method for Web authors}} A '''pingback''' is one of four types of [[linkback]] methods for [[World Wide Web|Web]] authors to request notification when somebody [[hyperlink|link]]s 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 (software)|Serendipity]], and [[Telligent Community]], support automatic pingbacks where all the links in a published article can be [[Ping (blogging)|ping]]ed 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 (networking utility)|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 (electronic)|spam]] than [[trackback]]s. Pingback-enabled resources must either use an X-Pingback [[Header (computing)|header]] or contain a <code><link></code> element to the XML-RPC script. == History == The Pingback specification was developed in 2002 by [[Stuart Langridge]], Simon Willison, and [[Ian Hickson]].<ref>{{Cite web |last=Langridge |first=Stuart |date=7 July 2002 |title=Making TrackBack happen automatically |url=http://www.kryogenix.org/days/000138.cas |url-status=dead |archive-url=https://web.archive.org/web/20021222230146/http://www.kryogenix.org/days/000138.cas |archive-date=2002-12-22 |access-date=2022-05-31 }}</ref><ref>{{Cite web |last=Willison |first=Simon |date=2 September 2002 |title=Pingback implemented |url=http://simonwillison.net/2002/Sep/2/pingBackImplemented/ |access-date=2022-05-31 |website=simonwillison.net |language=en-gb}}</ref><ref>{{Cite web |last=Hickson |first=Ian |date=2002-09-23 |title=Hixie's Natural Log: Pingback 1.0 |url=http://ln.hixie.ch/?start=1032794857&count=1 |url-status=live |archive-url=https://web.archive.org/web/20021206184812/http://ln.hixie.ch/?start=1032794857&count=1 |archive-date=2002-12-06 |access-date=2022-05-31 |website=ln.hixie.ch}}</ref><ref>{{Cite web |date=2002-09-24 |title=Pingback 1.0 |url=http://simonwillison.net/2002/Sep/24/pingback10/ |url-status=live |archive-url=https://web.archive.org/web/20030826071601/http://simon.incutio.com/archive/2002/09/24/pingback10 |archive-date=2003-08-26 |access-date=2022-05-31 |website=simonwillison.net |language=en-gb}}</ref><ref>{{Cite web |title=Pingback 1.0 |url=http://www.hixie.ch/specs/pingback/pingback-1.0 |access-date=2022-05-31 |website=www.hixie.ch}}</ref> == Exploits == In March 2014, [[Akamai]] published a report about a widely seen exploit involving pingback that targets vulnerable [[WordPress]] sites.<ref>{{cite web|last1=Brenner|first1=Bill|title=Anatomy of Wordpress XML-RPC Pingback Attacks|url=https://blogs.akamai.com/2014/03/anatomy-of-wordpress-xml-rpc-pingback-attacks.html|website=The Akamai Blog, March 31, 2014 5:42 AM|access-date=July 7, 2014}}</ref> This exploit led to massive abuse of legitimate blogs and websites and turned them into unwilling participants in a [[DDoS]] attack.<ref>{{cite web|last1=Cid|first1=Daniel|title=More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack|url=http://blog.sucuri.net/2014/03/more-than-162000-wordpress-sites-used-for-distributed-denial-of-service-attack.html|website=Sucuri Blog, March 10, 2014|date=10 March 2014 | access-date=July 7, 2014}}</ref> Details about this vulnerability have been publicized since 2012,<ref>{{cite web|last1=Calin|first1=Bogdan|title=WordPress Pingback Vulnerability|url=http://www.acunetix.com/blog/web-security-zone/wordpress-pingback-vulnerability/|website=Accunetix, December 17, 2012 - 01:17pm|date=17 December 2012 |access-date=July 7, 2014}}</ref> with [[Akismet]] reporting in 2013 that "almost 100% of trackbacks and pingbacks are spam".<ref>{{Cite web |last=Susan Richards |date=2013-05-21 |title=Spammers use trackbacks, pingbacks, and reblogs |url=https://piedtype.com/2013/05/21/spammers-use-trackbacks-pingbacks-and-reblogs/ |access-date=2022-05-31 |website=PIED TYPE |language=en}}</ref> 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]]).<ref name="A10 2016" /> 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''.<ref name="A10 2016" /> 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.<ref name="A10 2016" /> This can lead to 10x, 20x, and even bigger amplifications ([[DoS]]).<ref name="A10 2016" /> 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]]).<ref name="A10 2016">{{cite web |url=https://www.a10networks.com/blog/wordpress-pingback-attack |title=WordPress pingback attack |author=Krassi Tzvetanov |date=May 4, 2016 |website=A10 Networks |access-date=2 February 2017 |quote=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.}}</ref> 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.<ref name="Sucuri 2016" /> 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.<ref name="Sucuri 2016" /><ref name="A10 2016" /> If the attacker is more than a [[script kiddie]], they will know how to prevent their 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.<ref name="Conetix 2016">{{cite web |url=https://www.conetix.com.au/blog/analysis-wordpress-pingback-ddos-attack |title=Analysis of a WordPress Pingback DDOS Attack |author=Tim Butler |date=25 Nov 2016 |website=Conetix |access-date=2 February 2017 |quote=One enhancement WordPress added to the pingbacks in 3.7, which at least tracked the originating IP of the request. While this doesn't solve the problem, it at least allows you to trace where the calls are coming from. 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.}}</ref> Thus, it's still recommended to disable the pingbacks, to prevent attacking other sites (although this does not prevent being target of attacks).<ref name="Sucuri 2016">{{cite web |url=https://blog.sucuri.net/2016/02/wordpress-sites-leveraged-in-ddos-campaigns.html |title=WordPress Sites Leveraged in Layer 7 DDoS Campaigns |website=Sucuri |author=Daniel Cid |date=February 17, 2016 |access-date=2 February 2017|quote=Starting in version 3.9, WordPress started to record the IP address of where the pingback request originated. That diminished the value of using WordPress as part of an attack; the platform would now record the attackers original IP address and it would show up in the log user agent. [...] 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.}}</ref> ==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== {{Reflist}}<!--added above external links by script-assisted edit--> == External Links == * http://www.hixie.ch/specs/pingback/pingback - Pingback specification {{Blog topics}} [[Category:Blogs]] [[Category:WordPress]] [[Category:Drupal]]
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)
Pages transcluded onto the current version of this page
(
help
)
:
Template:Blog topics
(
edit
)
Template:Cite web
(
edit
)
Template:Reflist
(
edit
)
Template:Short description
(
edit
)