Saturday, July 12, 2008

Some Random Safari Notes

I got to take a quick look at some Safari stuff at work a few days ago, and came away with a few notes that I thought might interest people about Safari:

Cross-Site Cooking works the same way as it does in Firefox 2.0, namely it works just as the RFC describes and we can set cookies for .co.uk, .com.au, etc.

HttpOnly is not supported.

Safari parses Set-Cookie headers like the RFC says, which means that cookies are comma separated (no other browsers seem to do this), which means that in ASP.NET and JSP, when you use the framework's method of setting cookies and you let the user control the value, they can inject arbitrary cookies by specifying something like ", arbitrary_name=arbitrary_value" as the cookie value.

Referers are not leaked from https to http, but are leaked from one https site to another https site.

The safari cache (at lest on windows) is an SQLite database where all the data is double hex encoded; it looks something like X'aabbccddeeff, etc, and when you strip the first two chars and decode it you get another blob which looks identical to the first one, which you then need to decode the same way and you get an XML document with the data, I wrote this dodgy PHP function to do the conversion for me: (you need to call it twice on the blob you extract from the database)

function decode_blob ($blob) {
$ret = "";
for ($i=2,$c=strlen($blob);$i<$c;$i+=2) {
$ret .= chr(hexdec ($blob[$i].$blob[$i+1]));
}
return $ret;
}


On the iPhone (emulator at least; I didn't get to use an actual iPhone), the last character of the password field is shown before you type the next one in (and untill the field loses focus); this makes sense since it's hard to type on iPhones, but it's still curious.

Safari on the iPhone (emulator, again) doesn't seem to actually close, so unless you close the emulator (I'm assuming this is equivalent to turning off your iPhone; if that's even possible), all session cookies persist.

Hope that helps someone.

5 comments:

Anonymous said...

Wow, security though obscurity with that SQLlite encoding! or is this normal behavior? I can't see any reason why they should do this other than preventing strange locales/entities being injected into that XML file, but even that sounds strange if I hear myself uttering that. :)

Any thoughts why they do this? it's a pretty interesting aka weird approach.

/rvdh 0x000000.com

kuza55 said...

It seemed a bit odd to me as well, and I have no idea why they did that, I doubt it was meant to be security through obscurity since it's usually the first thing you try when you see some random digits...

I doubt it's to stop injection attacks since the whole xml file is encoded, but other than that I'm just as confused as anyone.

P.S. I was using sqliteman to view the database, not sure if that makes any difference though.

P.P.S. I remember the URLAndExit stuff (though I didn't know what it was) from way back when Kazaa was the shit (for me at least); you always got random media files which opened websites to try and get you to install malware, or just to do advertising. :)

Anonymous said...

Your php function is a bit too long. I would write the same this way :
function decode_blob ($blob) {
return pack('H*', substr($blob, 2));
}

Hope it helps ;)

Anonymous said...

What do you mean?

Anonymous said...

what he meant to say is your a amature kid. Dont take that from him. I recommend: a .exe=killbill code Hclass=null*/