Category Archives: Technology

Posted on
by

For many reasons, not least of which their decision to appoint a surveillance loving war criminal to their board of directors, I’ve been steadily migrating away from Dropbox.

Thankfully, there is a drop-in replacement for much of it, providing you run your own server. So, I’ve got a syncing file store/backup running across my devices, which can be accessed while I’m on the go as well.

However, one of the things I do use dropbox for (which is not terribly important in the grand scheme of things, but which I find quite useful) is, via the use of an IFTTT rule, to take a copy of any photos I’m tagged in on Facebook, so that I can see them (and to break them out of the silo) without actually having to go onto Facebook. This is possible using dropbox, owing to it being a centralised service, but obviously isn’t possible using your own server.

Webhooks to the rescue!

So a little while ago I put together a hack that used IFTTT’s wordpress channel to add a pluggable webhooks interface to IFTTT.

Since this tool supports plugins, I was therefore able to write a simple Facebook adapter which, when triggered would extract the image URL from the push message and then simply download it.

Since my owncloud install was on the same server, all I had to do was output this file to the appropriate owncloud data directory and any files retrieved are automatically synced to your client devices. You can of course opt to write to any directory, and not use owncloud at all, but since I wanted a like for like replacement for IFTTT+Dropbox I went for owncloud server storage!

Here’s the facebookphoto.php plugin code:

]*src *= *["\']?([^"\']*)/', $object->description, $matches))
                {
                        $url = $matches[1];

                        $parsed = parse_url($url);

                        if ($object->pass == $this->expected_password) {
                        
                                $filename = basename($parsed['path']);

                                file_put_contents($this->owncloud_path.$filename, file_get_contents($url));
                        }
                }
            
            return $object;
        }
    }

Simple, and obviously you could extend this to do other things with it.

Place the code in your plugins directory, and create a new recipe on ifttt triggering your plugin whenever you’re tagged on Facebook, remembering to pass plugin:FacebookPhoto as your category.

» Visit the Ifttt webhook project on github...

Posted on
by

Net neutrality, the principle that all data flowing over the internet is treated equally, sounds like a rather dry and technical subject. But, it is important.

Net neutrality is the reason why the internet is such fertile ground for innovation – anyone with a good idea can compete, on merit, and overturn an established player. It lets little news outlets go toe to toe with the big boys, which is important for our democracy.

Ending net neutrality would mean that big companies and media organisations would be able to pay a fee in order to secure their dominant position and to squeeze out competition – meaning fewer voices, higher prices and worse services for you.

While this is ostensibly a US problem, when the US sneezes the rest of the world gets a cold, and the internet is global.

Write to the FCC

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?