Safari Stores Previous Browsing Session Data Unencrypted

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.'"

Comments

Local file

[Anonymous Coward]

If someone else is reading files on your computer, you're already screwed!

Re:Local file

[Anonymous Coward]

And here we go again: someone claims that "if something is not completely perfect, it's completely useless".

Look, even if someone gets local access to your files, you are still less fucked if some of them are encrypted.

Re:Local file

[Anubis IV]

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.

Hey

[NoNonAlphaCharsHere]

When Apple says "easier to use", they mean for EVERYBODY.

Hmmm ....

[gstoddart]

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.

Sounds like Apple have some issues on their hands.

Hell, in my experience with Safari on Windows, deleting a cookie causes WebKit2WebProcess to crash.

Why the surprise?

[QuietLagoon]

...'The complete authorized session on the site is saved in the plist file in full view despite the use of https...

HTTPS only ensures security between the browser and the web server. HTTPS is not designed to ensure security of what the browser decides to store locally.

Re:Why the surprise?

[yincrash]

Pidgin (formerly gaim) also keeps unencrypted creds. This is their reasoning..

Re:Not in current version

[Anonymous Coward]

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/

So the news is basically, "Older version of software has bug which is patched in current version."

Re:Really, Slashdot?

[RedBear]

...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.