XSS is fun!

Pretending innocence, I ask why all these high profile websites have their homepages covered in spinning images?

Okay, obviously enough, I’m messing with them. But how can I do that?

The answer is cross site scripting (“XSS”).

XSS is surprisingly common, and nigh-universally is caused by poorly escaped user inputs. Even user inputs which, as in this case, they obviously don’t think of as user inputs. It happens when content is injected into a page, which results in the loading of arbitrary JavaScript onto that page.

As such, I own your interaction with those sites. If I was malicious I could be harvesting your cookies from them, redirecting you to phishing sites, recording everything you type, or just snooping on everything you view. As an example of why someone might want to do this… in the case of these particular sites, stealing your cookies (document.cookie) would let me post comments as you. I could thus spam those sites using legitimate accounts that I don’t have to go through the hassle of creating myself.

I’m not doing this, because that wouldn’t be nice. All I’m doing is reversing links and spinning images, because I think that’s cute.

In this case, all these sites have screwed up by including a little bit of HTML from an ad network (EyeWonder) on their site. This HTML accepts an arbitrary URL as a parameter, and loads it in a <script> tag. This is quite a common way for ad networks to ruin your day, often in the name of “frame busting”.

If you’re wondering who might be vulnerable to this exact hole from this exact ad network, Google can help you with that. Hint: it’s a lot of sites. I just grabbed the first three big names to demonstrate with.

Here’s the offending HTML:

This would actually be pretty easy to fix, note. A little bit of checking of the input, to restrict it to scripts hosted only on known-trusted domains would be enough to make exploiting it almost impossible. (I say “almost” because someone sufficiently resourceful might find one of these “trusted” domains isn’t as secure as they hoped and slip a script onto it. But it at least raises the bar.)

If you’re curious what I’m doing to make these pages spin, check out this gist which includes the spinner script. Essentially it’s just making an iframe which shows the root of the domain, and then manipulates the contents of that iframe, which it’s allowed to do because the script is running on the same domain.

In short: never trust user input. Also, don’t trust your ad networks to know/care about security.

This post brought to you by my coworker Paul Banks pointing out the existence of this fun little hole on CNN. I then added the spinning myself, because it looks nice and spectacular.

A shadow is upon us

Other people contributing to my projects is often the cause of my improving them. This is because people tend to contribute something that works for the case they care about, without necessarily testing how it combines with the rest of the product. There’s nothing wrong with this. They did some work and wanted to give it back; that’s how open source should work.

A case in point here is how shadows just got added to maphilight. A pull request was submitted for a commit that added shadow support for rectangles in canvas only. I accepted the request because, hey, that’s a nice improvement, and it seemed to work. But I wasn’t really happy with rectangles-only.

So, I started fiddling with it. I had, for whatever reason, never touched shadows in canvas before. In fact, it’s been quite a while since I did the research into canvas that was involved in writing maphilight in the first place.

Looking at the commit I see that the shadows have been implemented with a combination of clipping regions and redrawing the shape with some shadow options on the path.

Now, I’m confused by the clipping being done, since I’ve never seen it work quite like that before. It’s drawing a rectangle around the whole canvas, then another around the rectangle we’re shadowing, and telling it to clip. So I do a bit of testing, and I find that this isn’t doing what I think the submitter meant it to.

I think they wanted it to set up a clip region only outside the shape, so that the shadows they drew wouldn’t appear inside it. However, in practice it seems that it’s just adding the two rectangles together and leaving us with a clip region the size of the whole canvas. It’s possible that this did work in another browser, but not in Chrome where I was testing…

Since subtractive clipping obviously wasn’t the answer, I looked into globalCompositeOperation to clean up after the fill. It turned out that destination-out was the operation I needed to empty my shape. Also, because the shadow-drawing had been added after the regular shape, I had to move it to be before that, otherwise the shadow was being drawn on top of the stroke and cleaning it up would wipe out the fill.

Okay! Now we have outline shadows.

But, another issue with this method: it’d fill and stroke on the shape, regardless of the settings you were using. If you had no fill / stroke it’d use the default (flat black) settings, which are ugly. Also, it harmed your opacity settings — the stroke and fill were being done twice. So when I added a shadow to a strokeless mostly-transparent rectangle I noticed that it gained a thin black outline, and was darker than it should have been.

I messed around a little bit with trying to erase the fill or stroke, but eventually decided that this was more hassle than it was worth. What wound up being the simplest option was drawing the shape massively off the edge of the canvas, and using shadow offsets to cast the shadow into the right spot.

Now we had a shadow that didn’t involve drawing anything stroking or filling onto the canvas near our existing shape. At this point I had completely rewritten the code I’d merged in. About the only thing remaining was the option names Raven24 had chosen.

I went ahead and added some options for whether the shadow was cast inside or outside the shape, since I could see reasons for both, and added some overrides for whether it’d be casting from the fill or the stroke, since the varying possible configurations made it difficult to reliably guess which would look better.

I still didn’t add it to non-canvas. Largely because now that IE has finally given in and implemented canvas I view that as being a dead branch. Needs to keep working, and any major changes have to be ported over… but minor display differences are somewhat acceptable. Also, I don’t have access to IE right now, since I’m away from home. If I ever have reason to look into shadows in VML I’m sure I’ll add it in then, for the heck of it.

You can see all this in action on the demo page if you’re interested.

And that’s how community involvement improves things. 😀

Maphilight 1.3

I released maphilight 1.3 just now. (Though really I consider github the more authoritative source.)

So, IE9 broke maphilight because it was finally exposing the has_canvas codepath to IE. Turns out all the canvas stuff worked beautifully, but one call to setTimeout was relying on a non-IE feature. So that’s fixed!

Also changed since the 1.2 release (one year ago, gosh):

  • New option groupBy lets you bundle several areas together
  • New option wrapClass lets you set a classname for the wrapper div created to hold the canvas elements used by maphilight. If it’s set to true it’ll use the classname from the image.
  • .data(‘maphilight’) is checked for areas, as well as the metadata plugin. With jQuery > 1.4.3 this means that you can use JSON in an HTML5 data- attribute to pass this in. See the API docs for details.
  • Performance on image maps containing a lot of areas was terrible because I was stupid about where I triggered an event.
  • Opera compatibility was harmed by jQuery bug #6708 (fixed in 1.6), so work around that.

Feel free to submit issues / pull requests on the github project.

Detecting failure

I warn you in advance that this post does not end with a resolution of my problems.

For reasons relating to dynamic loading of javascript dependencies, I wanted to find a way to tell:

  1. When a script tag finishes loading a file
  2. Whether that file was successfully loaded

For various reasons, I didn’t want to add cruft into the files being loaded — no appending a function call to the end of every file, or anything.

Now, the finishes-loading case turns out to be pretty easy, albeit with some quirky cross-browser ramifications:

It’s a horrible mish-mash of events, obviously, but it works. Insofar as it goes.

Working out whether the load was successful turns out to be the hard part.

In Firefox it’s very easy. The load event doesn’t fire if there are problems loading the JS file, and a error event fires instead. This is lovely.

In Safari the load event doesn’t fire if there are problems, but there’s no other sign given. So I could probably fake this with a setTimeout set to a reasonable length — not perfect, but good enough for most cases.

In IE the readystatechange event fires away regardless. It’s here that I’m stuck — I can’t see any way to tell, in the readystatechange handler whether the script tag was really loaded without problems.

Since IE represents an unfortunately large component of deviantART’s users, half-working failure detection isn’t going to cut it. Especially since all the developers mainly use Firefox/Safari, and wouldn’t expect IE to behave differently.

So for now I’m going with verifying that the script tag loaded something, and says it’s complete. I’ll keep my eyes out for a way to work around IE…

Topsy turvy

A bug report for maphilight lead to me becoming aware of a fascinating quirk in IE. A quirk in which IE holds to published standards with fanatical zeal, contrary to everything one might have come to expect, and far in excess of Firefox/Opera/Safari.

When you use the .innerHTML property to add an element to the DOM, IE will fire an “unknown runtime error” if that element is incorrectly nested. So trying to place a

inside a

(as was the case in the bug report) will error very unhelpfully.

Surprising behavior.

Anyway, this led to the release of maphilight 1.1.1. (Which also includes an official minified version of the file, for convenience’s sake.)

del.icio.us widget

I couldn’t find a WordPress widget that produced output similar to del.icio.us’s linkrolls script. (You can just put their script into a Text widget, but its output doesn’t always mesh well with WordPress themes – it hardcodes h2s, and so forth.)

The Automattic example widget came close, but was a bit lacking on the customization front.

del.icio.us for WordPress also came close, but I disagree with having your server fetch the RSS feed, instead of using the perfectly good JSON API.

So I took the Automattic widget, hacked some extra features into it, made it configurable, and you can now see it in my sidebar. Well, footer currently. It’s a theme thing.

If you want it yourself, here’s the link: del.icio.us plus

Edit on 2008-03-27: This is now in the wordpress.org plugins repository.
Edit on 2008-04-16: Version 1.1 released, granting multiple widget instances.

maphilight: image map mouseover highlighting

UPDATE 2011-05-04: Version 1.3 released. Works in IE9. (There’s a pattern here.)

UPDATE 2010-05-22: Version 1.2 released. Works in IE8.

I just released maphilight, a jQuery plugin that turns image maps into wonderful graphical masterpieces.

Image maps aren’t so popular any more, for some strange reason. So a quick definition: an imagemap is an <img> with the usemap attribute, pointing to a <map> that describes polygons that link places within that image.

This sprung from me wanting to display pretty highlighting of countries on a map, but not wanting to mess with flash for it. It involves enough annoying fiddling with <canvas> (and VML, because IE is in the stone age) that I feel I’m saving other people a decent amount of work by releasing it.

Simple demo
Pretty demo using a world map
Documentation
Download (requires jQuery)

(Tools like “HTML-Image map Creator WYSIWYG” might be handy if you want to make image maps yourself.)

Fixing sortForce in jQuery’s tablesorter

jQuery has a table-sorting plugin, part of their official UI project. It’s quite a nice table-sorting library, handling the common cases, with options making it configurable to suit many people’s needs.

However, I ran into a problem when using it in a project. The documentation and the functionality don’t quite line up.

It has an option, sortForce, which its documentation says you can use to “add an additional forced sort that will be appended to the dynamic selections by the user”. This is a handy concept – it lets you, say, keep records ordered by name, regardless of which other criteria the user chooses to sort by.

The problem is that it actually prepends the sort to the user’s selection, which means that the user is restricted to sorting within the forced sort. (This is also a potentially useful tool; it’s just not what the documentation indicates.)

So I wrote up a patch that fixes this, along with a few other niggling issues with sortForce. (Its interaction with the user sorting by multiple columns, and it locking the forced-sort column in one sort direction.) To preserve backwards-compatibility I added a new option, sortAppend, to provide the documented behavior.

I also submitted the patch to the maintainer, so hopefully it can get incorporated.

2008-08-27: My patch was incorporated as of version 2.0.2, so it’s all good.
2009-03-17: But bits of it weren’t applied, so it can’t be said to have been fixed. Oh well. I’ll resubmit.