Slashdot Mirror
Safari Security Hole Allows Cookie Theft
An anonymous reader writes "MacSlash posted a story about a vulnerability in Safari. The exploit allows someone to steal any of your domain-based cookies (passwords, private info, etc.) from any website. Mozilla and Internet Explorer had the same bug in the past."
to make a symlink from your cookies file to /dev/null. Who needs persistent cookies anyway?
Just goes to show that companies should closely monitor security holes in competing products.
One should not theorize before one has data. -Sherlock Holmes-
Apple: Who me?
Marc Slemko: Yes, you.
Apple: Couldn't be.
Marc Slemko: Then who?
Potentially, but I doubt it. The two browsers share a rendering engine, not much else. Cookies are purely a protocol issue, they add extra data when doing a GET/POST request on a web page. Nothing whatsoever to do with HTML rendering.
Potentially a bug could exist in the Javascript engine, and since Javascript can access cookies, and they could be stolen this way. However this particular bug doesn't appear to be JS-related, rather it's something more fundamental (but easily fixed by Apple, hopefully).
Since Konqueror uses KDE/QT's socket classes, whilst Safari uses the Carbon/Darwin sockets interface, it's unlikely the bug would rear it's head in Konqueror IMHO.
I am trying the "test" and all I get is:
:)
Please wait while loading the script
You are stuck on this page ?
It means that your browser is not vulnerable, sorry, or maybe, not so
sorry, it's how the things should be !!!.
You can press the back button now
I am running Safari 1.1.1 (v100.1). Could it be because
of This Hint?
The exploit allows someone to steal any of your domain-based cookies (passwords, private info, etc.) from any website.
Any security hole should be fixed, but this is not as serious as they make it sound.
Passwords? Private info? What serious web developer would be keeps these in a cookie? Cookies are not secure. They are stored unencrypted on the user's hard drive (where they are easily rifled through), and (as mentioned) there have been plenty of bugs in the past that have made their data accessible to John Q. Hacker.
Cookies are mostly used for storing session ids, or another meaningless number that links back to the real info stored in a database on the server (yes, you don't want a hacker reading your session id, but this is a much lower risk).
This is not just for security reasons -- it's because cookies are not reliable. Cookies get wiped out all the time (all browsers that I know of let you delete them, and I see lots of ads for software that offers to manage, delete, filter, or "clean them up" for me.
Also, cookie size is limited (and does this differ on the diff browsers? I know GET request size does), so you could screw yourself over if you were storing a user's personal info and their address was really long.
Why would you store username/password data in a cookie anyway? Most browsers do this for you now, *and* they are more secure about it. Hm.
These are the best practices I was taught, at any rate. I didn't checked slashcode before posting this... and I suppose it is true that best practices are not always followed.
Does anyone have a real sense of how often sensitive data is stored unencrypted in a cookie?
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
This isn't a Safari bug, this is how your OS deals with virtual memory.
/var/vm
Look in
And you will see... swapfile1, swapfile2... etc. The OS creates these as needed.
Now for the OS to recover swap space, there has no be no pages addressed to a swap file. When you run Safari what gets paged out to disk? Not safari, but all the other applications you are running. Therefore, quitting Safari does nothing. The OS won't page in the swap unless you need access to that page of memory.
Safari 1.1.1 (v100.1)
Still see my ebay cookies.
Maybe you cleared your cookie cache or have accepting them turned off?
You're just jealous because the voices only talk to me.
First of all note that OmniWeb is not affected by this bug. Outside of a lack of tabs, it's a very good Web Browser that should satisfy you until Apple patches this bug. Of course, I'm sure the Slashdot readership is aware of other options as well.
.amazon.com for the purpose of cookie security. This seems to be a bug in the code around KHTML, not KHTML itself, since vulnerable OmniWeb uses the same WebCore framework that is used by Safari without being vulnerable.
As for the discussion as to whether this is a bug in KHTML in general, it is not. The bug is in the way browsers parse the hostname out of a URL differently for cookies and the connection itself. So in Safari the url:
http://www.EvilSite.com%00.amazon.com/
will connect to www.EvilSite.com, but be considered in the domain of
http://hetima.com/soft/cookiemonsterfix.html Scroll down for the english explanations. But you also can proceed to download the DMG file itself, as substancial english documentation is included there. G
I was bit dubious at first, but the patch includes source code. I did install the supplied binary, though...
What I'm really surprised about however is the fact that a) a third-party developer can fix a problem like this at all, and how easily the fix can be hooked into Safari. It appears that this OpenStep/Cocoa framework stuff is really flexible...
Oh and yes, it does work!