Tag Archives: microformats

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

Microformats are an easy way to semantically mark up a web page so that it can be easily parsed and understood by a computer.

This allows you to write code to easily do many funky things, not least of which extract author information from a page with minimal effort. This is how Idno’s distributed friending functionality works, btw.

Idno/Known supports MF2 natively, but support was sadly lacking in Elgg, so I wrote a quick plugin to add it.

Overview

The plugin, once installed and activated, adds some hidden markup to certain core views and does some basic post processing to add MF2 markup.

It is designed to be as light weight as possible, while still providing useful functionality.

As I mentioned above, and in the readme, this was primarily written to scratch an itch – namely, to provide the base functionality for Idno<->Elgg distributed friending functionality. Cross login functionality will come, hopefully, when I have time (although if you’re in a hurry you could always provide an incentive!).

» Visit the project on Github...

Posted on
by

Over on my Idno development fork, I’ve pushed some functionality that I think is rather neat (and I hope will be adopted by upstream Update: it was.).

In a nutshell, I’ve started fleshing out the ability to Friend/Follow other users (based on some stuff I’ve previously kicked about).

The ability to add friends (and create posts only visible to them) is what puts the social in social network, and was functionality previously missing to idno core. An added complexity is that, since Idno is designed to be a distributed network, this needs to work across multiple installations.

Idno references users by URL, so this much was fairly straightforward, however I absolutely didn’t want people to be typing URLs into boxes to add a friend…

MF2 to the rescue!

Since everything in Idno is marked up and parse-able by it’s built in Microformats parser, Idno can easily harvest the required information when parsed a page, so all I really needed to do was pass an endpoint a URL.

So, I created a simple bookmarklet:

following

Once dragged into your toolbar, you can click on any page and your Idno installation will find any users present and allow you to add them in a couple of button clicks.

addfriend

Monocultures are considered harmful

What makes this approach especially cool is, so long as the page is marked up using simple Microformats, your friend does not need to be running Idno in order for you to add them.

Your friends could be running Elgg, WordPress, Fizzbuzz, whatever, and you can still follow them, and allow them to see private posts (using some form of authentication – more on that to come).

Have fun!