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!
Perhaps they should fire a darkness ray at it...
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.
What do other browsers do?
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.)
as far as i can tell, if you close the tab before you quit, it won't store the data. not ideal, but something worth telling users about until a fix comes...
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.
I just wish there were an option to store nothing or keep shit in ram which dies with the browser process except for sites you want to keep long term sessions with. All the browsers constantly write all kinds of shit to disk in the form of cookies, histories, cached files. Information used against you constantly to track your every move and potentially accessible by prosecutors normally incentivized by prosecution rates rather than search for truth to twist all traffic and search terms into grand criminal conspiracies.
What a tragic first-world problem. Do we need to hold candlelight vigils to share in this tragedy?
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?
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.
Looks like the only major browser that really your needs seriously is Firefox. Given thats the sole purpose of the organization that produces it, that is a lot more re-assuring to me. Go FF.
Make sure everyone's vote counts: Verified Voting
I respect that FF has its own authentication/encryption mechanism in place and can be set to require a password before access to passwords or other local data is granted. I wish more Web browsers did this, as opposed to relying on the OS for security.
Encrypt the local disc cache with a hash, just in case somebody gets into my file system later and pokes around in my history. To pull back from cache it automatically brute-forces it for you. Hope you weren't going to use your browser for anything over the next thousand years.
Am I to believe that other browsers -- Firefox, Chrome, Opera, IE -- store their session and save data in an encrypted file or container? And even if they don't, so what? If someone has access to your browser's data folder, they can access your session data by, y'know, opening the browser with it pointed to the folder. Not to mention, that they have access to your files, which is a bigger problem in itself.
And please do explain to me how browsers' saved credentials should be stored in an encrypted manner without prompting the user for a master key.
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
That the data is stored at all is the issue. Even if encrypted, the key would be readily available from analyzing the application or tracing its calls.
Software people still do not get security at all. This is pathetic.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
So, out of curiosity, since I am on a Mac and using Safari as my main browser, I thought I'd see what was in the offending file. I have a in excess of 20 tabs open at the moment, a good deal of them to authenticated sites via https.
A quick test in Terminal like so:
$ strings LastSession.plist | grep -i pass
Produced 8 lines that matched, of which 6 matched on the word "passive" and the last two were urls that contained the word "ChangePassword". A more thorough search through the file did not produce any login credentials or passwords.
I should point out this is with the latest release version of Safari 7.0 (9537.71)
David de Groot Snr Systems Engineer