Safari Stores Previous Browsing Session Data Unencrypted 135
msm1267 writes "Users of Apple's Safari browser are at risk for information loss because of a feature common to most browsers that restores previous sessions. The problem with Safari is that it stores session information including authentication credentials used in previous HTTPS sessions in a plaintext XML file called a Property list, or plist, file. The plist files, a researcher with Kaspersky Lab's Global Research and Analysis Team said, are stored in a hidden folder, but hiding them in plain sight isn't much of a hurdle for a determined attacker. 'The complete authorized session on the site is saved in the plist file in full view despite the use of https,' said researcher Vyacheslav Zakorzhevsky on the Securelist blog. 'The file itself is located in a hidden folder, but is available for anyone to read.'"
Local file (Score:5, Informative)
If someone else is reading files on your computer, you're already screwed!
Really, Slashdot? (Score:5, Informative)
Again?
First, it's previous versions of Safari that are affected. Interesting how that isn't even mentioned.
Second, as already pointed out on the MacRumors forums, the stored "session" data is merely the URLs of the web pages you have open, which is passed over the wire in plain text anyway when you open or reopen the URL.
If you're encrypting your drive with FileVault and have a decent password on your user account, this becomes entirely an issue with the piss-poor security practices of the STUPID WEBSITES that are revealing your login information in plain text right in the URL. Any bookmark of such a URL with also "reveal" your "unencrypted" login credentials. Which is entirely the fault of the website.
Also, it's fixed in latest Safari.
So... yeah. End of the world, apparently.
Re:Not in current version (Score:5, Informative)
Summary is in present tense, but per the article, this applies only to older versions of Safari (6.0.5 on Lion and Mountain Lion.) The current version of Safari is 7 (on Mavericks) and 6.1 (on Lion and Mountain Lion.)
And to be perfectly clear...the current versions, 6.1 and 7, do NOT have this issue.
http://www.zdnet.com/safari-on-mac-os-exposes-web-login-credentials-7000024287/ [zdnet.com]
So the news is basically, "Older version of software has bug which is patched in current version."
Re:Why the surprise? (Score:5, Informative)
Re:Local file (Score:2, Informative)
If that's the threat you're concerned with, why not encrypt your sensitive files yourself instead of expecting your browser to encrypt one of your sensitive things?
Re:Really, Slashdot? (Score:5, Informative)
...Second, as already pointed out on the MacRumors forums, the stored "session" data is merely the URLs of the web pages you have open, which is passed over the wire in plain text anyway when you open or reopen the URL.
along with the password and login.
from the article: "the login and password are not encrypted (see the red oval in the screenshot).
Yes, I know. The login and password credentials in the red oval are encoded in the stored URL of a web page that was open in a tab in a Safari browsing session. Those URLs are created by the websites you visit, not by Safari. Safari just stores the URLs so that your tabs can be reloaded when you reopen the browser. Safari isn't secretly copying your login data in plain text and then failing to encrypt it, it's just storing the URLs you currently have open in your browsing session. There's nothing sinister or incompetent going on here.
It's good that they are now encrypting the stored browser session file. It certainly doesn't hurt anything to have another layer of protection. But that same URL information will be stored, unencrypted, in any bookmark that you make when visiting such a website while you are logged in. If someone sits at your computer and examines your bookmarks or looks at the URL in your open tabs they will see your login credentials in such URLs. Unless you want to be forced to enter a master password every time you try to edit a bookmark, use a bookmark, or examine the URL in the address bar, there is no solution to this. The solution for protecting the saved session file is FileVault, and locking your computer when you aren't sitting in front of it, which is exactly the same way you protect all the other vulnerable data in your user account.
The root cause of the login credentials being revealed in plain text in bookmarks, the session file and the address bar is the deplorable practice of websites putting your login and password in the URL in plain text. The solution to this is to smack the websites upside the head until they modify their security practices.
Re:Hmmm .... (Score:4, Informative)
So, as far as I can tell, Safari doesn't actually block 3rd party cookies despite saying it does, and stores your credentials in plain text.
Yes it does. I know this because I had to disable the feature to access my banking site's eDeposit feature before it would work. Just go to Safari -> Preferences -> Privacy -> Block cookies from 3rd party sites.
Re:Local file (Score:2, Informative)
I don't expect a browser to litter my filesystem with unencrypted sensitive data for no good reason. And if they are hidden, there should be no expectation that users manage them.
Re:Local file (Score:5, Informative)
Quite true, but it's worth pointing out that the summary (and articles) conveniently left out the fact that this information has been encrypted for months; the issue was addressed by a Safari update that came out with Mavericks and was made available for older versions of the OS.
In fact, the issue is specific to an outdated version of Safari (v6.0.5) that only runs on outdated versions of OS X (10.7 Lion and 10.8 Mountain Lion). Anyone who installed the free OS X 10.9 Mavericks update that came out back in October is fine, since it came with Safari 6.1, which fixed the issue. For those users who stuck with 10.7 or 10.8, OS X's built-in Software Update feature runs once a week by default, so most of them have been getting prompts since October to do a one-click upgrade that would address this issue, since Safari 6.1 is available to all of them as well.
Long story short, this is a non-issue that affects a trivial portion of the Mac user base, since updates were issued months ago and the systems are configured such that the fix would be widely applied by default. Even so, we can agree that if you compromise physical access, you've compromised the system.