Possible security problem with Tiger Dashboard widgets

When Dashboard widgets hit the web, they do so using all the same access information available to Safari. So if a website is using cookie-based access control, if you’re logged into that website, so is Dashboard.

I was playing with Dashflix — it checks your Netflix Queue, and displays the ship dates for any movies you have coming. Handy.

It does this by using XMLHttpRequest to download the Netflix queue page. Netflix, like many websites, uses a persistent cookie to keep you logged in: if that cookie is set, a hit to netflix.com/Queue will give you your list of movies; if it isn’t, you get a login page.

Dashflix doesn’t need to ask you to log in to Netflix: its XMLHttpRequest calls apparently have full access to any Safari cookies you have lying around. (The only reason I noticed this is that I use FireFox as my primary browser, not Safari, so the first time I ran Dashflix it got the login page, and asked me to log in through Safari… if I’d already had the login cookie set in safari, it would’ve Just Worked and I wouldn’t have thought anything more about it.)

I haven’t played with it much yet, so I don’t know if Dashboard widgets are able to read data from the cookie file directly, or if they’re just able to implictly use those cookies when accessing pages from the web. Either way, though, it’s pretty easy to see how a malicious Widget could check for common cookies you might have set by browsing using Safari — Amazon, GMail, anything that involves a persistent login — and then broadcast information gathered using it back somewhere on the web (by just making another XMLHttpRequest call). How vulnerable any given website would be to this would depend on its access mechanics — but just for example, if a user has Amazon’s “one-click purchase” enabled in safari, then a malicious Dashboard widget could make a purchase on your behalf, without you knowing about it.

Dashboard files are plaintext javascript and HTML, so it’d be pretty easy to check the source code of any given widget to see if it’s up to these sorts of tricks. But how many users are in the habit of reading the source code of every Dashboard widget they download? And it’s got me wondering: is the same cookie data shared by every application that uses WebKit? If so, then these same tricks could be hidden in a compiled application, where they’d be much harder to spot.

That said, I’m going to continue using Dashflix; it’s pretty handy, and isn’t up to anything sneaky. But just to be on the paranoid side, I’m clearing out all my other Safari cookies, and I’ll continue using FireFox for everything else. Interconnected applications make me nervous.

Bonus Code Tweak, While I’m On The Subject

There’s one major flaw in DashFlix’s UI — whenever you activate Dashboard, the widget uses that event as a signal to go check for updates to the queue. So right at the moment you want to see the information, it’s hidden by a “loading” animation. Stupid. Here’s how to fix it:

In DashFlix/src/events.js, in the connect() function, remove this code:

var child; 
while(child = document.getElementById("output").firstChild){
 document.getElementById("output").removeChild(child);
}
while(child = document.getElementById("outputBack").firstChild){
 document.getElementById("outputBack").removeChild(child);
}

Then in the handleResponse() function, add that same chunk of code right after this line:

if(req.readyState == 4){

Then you can either edit the CSS file to move the “spinner” graphic out of the way, or remove it altogether by deleting this line from the connect() function:

document.getElementById("spinner").style.display = "block";

All this does is cause the widget to not hide any information it’s already gathered while it goes looking for more current data. Since your Netflix queue changes at most once a day, this slightly-out-of-date information is still pretty useful — more so than a blank pane with a spinner graphic, anyway.