Tag Archives: webmention

Posted on
by

In this post I’m going to discuss a potential attack, using a common method of implementing webmention comments on a site, that can allow an attacker to obtain visitor information from a third party site, and to possibly launch drive-by attacks.

This came about from a discussion related to retrieving non-TLS protected resources from a TLS protected site, and it got me thinking that the problem went a little deeper.

The Attack

A common way of handling webmentions on an Indieweb site, such as those powered by Known, is as follows:

  1. Alice writes an comment on her site, and references Bob’s post
  2. Alice sends a webmention to Bob’s site referencing the URL of her comment, and the post she’s referring to.
  3. Bob’s site retrieves Alice’s comment & parses it for Microformats markup
  4. If all things check out, Bob’s site then renders the comment using text, profile url and profile icon information obtained from Alice’s site.

It is step 4 that’s the problem here.

Typically, when the webmention is parsed and rendered by Bob, the site software will attempt to construct a nice looking comment. To do this, the site software will typically render an avatar icon, together with a user name, next to the comment. This information is obtained by parsing MF2 data from Alice’s site, and while the Webmention spec says that content should be sanitised for XSS etc, profile icons are often overlooked – a URL is fairly innocuous, so it’s generally just dropped into an img tag.

Now, if Alice was evil, she could, for example, configure her server to send “in the past” cache headers when her server served her avatar. This would mean that her server logs would then start collecting some detailed traffic information about the visitors of the page she webmentioned, since every visitor’s browser would retrieve a new copy of her profile icon.

She could, if she was very smart (or was a well funded government agency sitting on a whole bunch of zero day browser exploits) serve specially crafted content designed to trigger a buffer overflow in a specific visitor’s browser at this point.

Worse, she could do this even if the entire site was protected by TLS.

Mitigation

The simplest way to prevent this kind of exploit is not to render profile icons from webmentions. This is, however, a sub-optimal solution.

My current thinking is that Bob’s site (the site receiving and rendering the webmention) should, when receiving the webmention, fetch and cache the profile icon and serve it locally from his server.

This would prevent Alice from performing much in the way of traffic analysis since her server would only be hit for the original request. If you server re-samples the image as well (to enforce a specific size, for example) then the process would likely do much to strip any potential hidden nasties embedded in the file.

There is a DoS potential to this, but techniques for mitigating DoS for webmention/MF2 parsing have already been discussed in the Webmention spec.

Anyway… thoughts?

Posted on
by

Just a quick update to point you good folk over to a couple of Idno plugins I’ve put up on github.

The first, LoginSyslog, is a simple plugin that outputs login events (success and failure) to the Auth.log, in much the same way as my Elgg fail2ban plugin. This allows you to audit login attempts on your Idno site, as well as use a tool like fail2ban to protect your site from brute force attacks.

The second, Pingback, adds support for incoming Pingback. Idno primarily supports webmention as a notification mechanism, and while legacy support for outgoing pingbacks, however incoming pingback support was missing. This plugin adds the missing functionality, meaning your Idno site will play nicely with WordPress and similar.

Happy hacking!

Posted on
by

WebHookWebmention, as well as the legacy Pingback, provide a way of notifying a third party site that you have made some reference to something on their site. So, for example if I reference somebody elses blogpost in mine, that blog will be notified and my reference may appear as a comment on the post (unless they’re blogging on a passive aggressive silo like Google+ or Facebook, or their blog uses Disqus, which is, in many ways I won’t go into now, the suck).

Pingbacks, and increasingly Webmention, are supported by most major web frameworks and blogging platforms, but adding them to a home rolled platform can be a little bit of a faff, especially if these platforms are build on static HTML.

So, inspired by Pingback.me written by Aaron Parecki, I wrote a bit of middleware that can be installed on a web server with minimal fuss, and can provide pingback/webmention services to other sites.

The reason I didn’t use Pingback.me was that I needed something quickly, I had reasons why I didn’t want to install an entire Ruby stack, and I needed the webhook functionality for a couple of projects (including some funky node.js dataset regeneration to tackle some scalability challenges, but that’s a different story).

Setup

One of the main requirements for pingback2hook was ease of setup, which I hope I’ve achieved.

  1. Start by checking out the source code from the github repo here, and place this on your web server.
  2. You’ll need to have PHP 5.3 running with mod-rewrite, and also CouchDB (to store pings), which on Debian systems, should be a fairly straightforward setup.

    apt-get install apache2 libapache2-mod-php5 couchdb; a2enmod rewrite

  3. If you’re running pingback2hook on its own subdomain, you should be up and running, but if you’re installing to a subdirectory of your site you’ll need to modify the RewriteBase in .htaccess.

Enabling pingback and webmentions on your site

Once you’ve got the software up and running somewhere, you can then start enabling pingback support in your sites. This is a two step process:

  1. On the pingback2hook server, define an endpoint for your site in a .ini file. This file will define the endpoint label, a secret key for communicating with the API, and zero or more webhook endpoints to ping. E.g.

    [mysite]
    secret = "flkjlskjefsliduji4es4iutsiud"

    ; Zero or more webhook endpoints
    webhooks[] = "http://updates.mysite.com"
    webhooks[] = "http://data.mysite.com"

  2. On your website, declare the necessary hooks in your metadata, either by headers:

    // Webmention
    header('Link: <http://pingback2hook.myserver.com/webmention/myendpoint/>; rel="http://webmention.org/"');

    // Pingback
    header('X-Pingback: http://pingback2hook.myserver.com/pingback/myendpoint/xmlrpc');

    And/or in the header metadata…

    <html>
    <head>
        <link href="http://pingback2hook.myserver.com/webmention/myendpoint/" rel="http://webmention.org/" />
        <link rel="pingback" href="http://pingback2hook.myserver.com/pingback/myendpoint/xmlrpc" />

        ...

    </head>

    ...

</html>

Once set up, you will get an entry in the database for every pingback or webmention a given permalink receives. If you’ve defined some webhooks, these will be pinged in turn with the JSON content of the ping.

Viewing your pingbacks

To view your pingbacks you can either make a direct query of the couch database (default: pingback2hook), or make use of the API.

Currently, you can query the API via its endpoint at https://pingback2hook.myserver.com/api/myendpoint/command.format, passing any required parameters on the GET line.

At the time of writing only one command is supported, but I’ll add more as I have need to:

Command Parameters Details
latest.json|jsonp target_url, limit (optional), offset (optional) Retrieve the latest pings or webmentions for a given permalink url.

To make the query, you need to authenticate yourself. This is done very simply by passing the ‘secret’ for the endpoint in your request header as X-PINGBACK2HOOK-SECRET: mysecret. This is very basic security, and your code is being sent in the clear, so it goes without saying that you should ONLY make queries to the API via HTTPS!

Have a play, and let me know what you think!

» Visit the project on Github…