Slashdot Mirror
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.'"
If someone else is reading files on your computer, you're already screwed!
When Apple says "easier to use", they mean for EVERYBODY.
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.
Lost at C:>. Found at C.
...'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.
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.
Encrypting the data certainly isn't a bad idea, but unless I'm missing something here, encrypting the data is nothing more than a lame case of security through obscurity. If the browser stores the data encrypted, then the browser also needs to store the KEY to re-open the file. If someone can get a hold of the file, then they can also get a hold of the key to decrypt that file.
If there's a security problem here, it's the Restore Session functionality itself. Perhaps secure sessions shouldn't be restorable?
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
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."
We're talking about Macs. It's a first-world problem by definition.
The rest of the summary would be consistent with labelling this as an "Information Leak" rather than "Information Loss." ...or perhaps the author meant a loss of security or privacy. Can I beg for summary writers and editors to try harder to get at least the first sentence clear and correct?
All this article means is that Google has a bug to fix with regards to the post back response on the GMail login page.
Some in this discussion say things like:
along with the password and login.
from the article: "the login and password are not encrypted (see the red oval in the screenshot).
Let's be clear here. The only time that any browser's session restore feature would store your username and password is because it's part of the HTTP request itself. An HTTP request can be a GET or a POST. Good web developers never send sensitive information in a GET, nor should a GET actually _do_ anything other than get a resource. POST requests should be used for this instead, which do not convey the private information in the URL bar. Now, POST requests are not inherently more secure than GETs, and the data they pass is actually in the same format as the data in URL-based GET requests, and just as visible to observers on the network. I'm just getting some of the technical background set for all of the (clearly *very*) technical people who read Slashdot these days.
The "problem" is that older versions of Safari stores the details of POST requests "unencrypted". Which is fine because any encryption is meaningless if decryption can be done without user intervention. You would not encrypt some file and then place the key next to it and then store it that way would you? Nonetheless, this is exactly what happens when the encryption key is stored on the same volume as the encrypted file. If it can be found by software then it can be found by an attacker.
The really funny part is that this looks like the page Safari saved was a GMail login attempt which was unsuccessful (duh? the credentials are clearly not real). Google is doing authentication (almost) the right way here fellas, the only time that using GMail involves having your plaintext credentials in a POST request is during login and login alone. From there on out it's just record keeping (valid session list on the server, and a known session ID in the hands of each client).
You can see this for yourself by opening up an Incognito session and going to gmail.com, and typing fake credentials (i don't know, "kaspersky_user" and "kaspersky_pass" come to mind for some reason), then on the "Invalid login" page, hit refresh. You will be prompted by your browser to resend the login credentials. There! You see that the browser _still has_ your login credentials from before! AMAZING! Did you know that if you leave that tab untouched for three days your creds will still be resent again when you finally refresh??
Safari like any other browser with a restore session feature, saves that POST data. Because it's just POST data to the browser. And if you are sitting on a page that is itself the result of a POST request, the browser MUST save that data if it intends to give you the same page when you return... by both specification and convention. Google can fix this particular issue by redirecting their invalid logins back to GET requests like the rest of the civilized world. That protects their users account credentials from inadvertent storage on disk.
The more interesting part is how someone would think that this would be immediately dangerous, because had the user successfully logged in, they would not have been sitting on that POST request would they! That's right the credentials would have long vanished and would never have made their way to disk. The only time this would happen in practicality is when the credentials were NOT correct. Don't get me wrong, that can still be valuable to an attacker, but its a Google bug not a Safari one anyway. Nonetheless in GMail's situation, this is a rare and definitely not reliably exploitable issue from the perspective of potential attackers.
I cannot stress enough that credential leaks within a session backing file on a hard disk is only a problem when the site itself messes up or is written improperly and/or insecurely. And on the local side: If you d