Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Safari Stores Previous Browsing Session Data Unencrypted

Soulskill posted about 7 months ago | from the security-through-obscurity dept.

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

cancel ×

135 comments

Local file (5, Informative)

Anonymous Coward | about 7 months ago | (#45683811)

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

Re:Local file (5, Insightful)

Anonymous Coward | about 7 months ago | (#45683843)

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 (2, Informative)

Anonymous Coward | about 7 months ago | (#45684103)

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:Local file (2, Insightful)

Anonymous Coward | about 7 months ago | (#45684449)

Defense in depth. Is that really so hard for people to understand?

Re:Local file (2, Informative)

Anonymous Coward | about 7 months ago | (#45684725)

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 (1)

Anonymous Coward | about 7 months ago | (#45684817)

Yes, we should all have computer science phd and be aware of all of the files that thirdparty programs use on our machine and preemptively encrypt it. Each layman should be extremely smarter than most determined hacker. Is that too hard?

Re:Local file (1)

sl4shd0rk (755837) | about 7 months ago | (#45684761)

"if something is not completely perfect, it's completely useless".

You are trying to apply a paradigm reserved for baked goods to computer security; Half baked cookies aren't so bad. Half baked security (plaintext) is indeed useless.

Re:Local file (1)

multimediavt (965608) | about 7 months ago | (#45684875)

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.

True, but that "less" would be about 0.0001% less fucked. Fucked is fucked. There really isn't a partial to it when it comes to data security. That one pretty much is a "is" or "isn't". Local access to files is a lot more fucked than one unencrypted file. About 1,000,000% more fucked.

Re:Local file (1)

retroworks (652802) | about 7 months ago | (#45685087)

"Fucked is fucked. There really isn't a partial to it when it comes to data security."

Not really? The value of the data and the value of the target dictate the depth of the necessary encryption. I see the extent people go to in order to destroy a 1993 486X hard drive, as if someone is going to ever take the time to boot it up to retrieve their data. The article contributes necessary information, that I can browse news stories on my Safari browser, but I should hesitate to log into my bank account. Too many people are seeking complete invisibility of everything, when it's really only important to hide the juicy bits. We don't need to be afraid of every single spider, just the black widows and brown recluses.

Re:Local file (1)

Anonymous Coward | about 7 months ago | (#45686739)

In a word: cobblers.

Encryption might not prevent a determined hacker from stealing someone's session cookies, but it would ward off an opportunistic "Say, that person forgot to lock their workstation when they stepped away for coffee" type attack.

I assume you don't lock your home's door either. After all, a determined housebreaker can just break the window and enter that way so it's not perfect security, and imperfect security is no security. Indeed, given that, it might be better to just leave all those doors and windows open, less damage that way. ;-)

Re:Local file (3, Insightful)

Bert64 (520050) | about 7 months ago | (#45685011)

Which means you need to enter your key every time you start the browser...
If the browser has a way of automatically knowing the decryption key, then so does a hacker.

Also, previous session data should be useless - the sessions should have expired, or been closed when you logged out. Most sites that offer the option to stay logged in warn you against doing so on a system you don't trust.

And i'm pretty sure other browsers don't store persistent cookies very securely either, they used to be in a plain text file and they can certainly be viewed/user from within most browsers without having to ever supply a decryption key.

Re:Local file (1)

daveime (1253762) | about 7 months ago | (#45686569)

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

Which is total bollocks if the encryption key is on the same machine. A computer that is rooted is no longer secure, any data that can be decrypted locally is the same as if it was plaintext anyway.

Re:Local file (1)

gagol (583737) | about 7 months ago | (#45686891)

I am much more concerned with my tax reports than browser history. I dont care fuck all if someone knows that I had slashdot, arstechnica and newscientist opened last session. If you browse porn sites in a non anonymous session, you do it wrong.

Re:Local file (2, Insightful)

Anonymous Coward | about 7 months ago | (#45683859)

Physical access = surfing history is the least of your problems.

Re:Local file (0)

Anonymous Coward | about 7 months ago | (#45684845)

I give my computer to guests for few min here and there. I can check physically that he/she is not putting usb drive and doing mass copy etc. But certainly cannot check if he/she opens a file for few sec. If it only takes a casual physical access for few sec to get your bank passwd, then you are screwed and if you don't understand this simple thing, you are better off AC. Oh, wait. you are AC.

Re:Local file (0)

Anonymous Coward | about 7 months ago | (#45685283)

Why can the guest account on your computer access your own user files?

Re:Local file (0)

Anonymous Coward | about 7 months ago | (#45685753)

Because hate for Apple is nearly unlimited.

Re:Local file (0)

Anonymous Coward | about 7 months ago | (#45686229)

I'm the AC you're replying to. I'm also a Mac developer so I know you need Dev Tools installed to get the Property List Editor, and in Mac OS X 10.4 and later, plist files are often in binary format (this includes Safari) so any old text editor isn't going to get the job done.

So let me explain a few "simple things you don't understand": security starts with YOU. You are responsible for the security of your systems. Period. No excuses.
- saving your bank username and password in ANY browser is just lazy and stupid.
- in general, saving passwords in your browser isn't a good idea (Firefox stores them in plain text FFS!)
- giving anyone physical access to your system while you are logged in is as insecure as you can be.
- if you think you can always spot a USB drive then you've never learned 'slight of hand'.
- if you think that the person you are willingly and knowingly handing your computer to - while you are logged AND logged into your bank no less - can quit Safari, find this plist file, figure out which entry is your banking session, memorize all of the auth token information, and close the file so fast that you with your eagle eyes and superior intellect can't see it happen, then maybe, just maybe you shouldn't be handing them your computer.

Don't take your security training wheels off just yet. We don't want you to hurt yourself.

Re:Local file (0)

Anonymous Coward | about 7 months ago | (#45686725)

I'm the AC you're replying to. I'm also a Mac developer so I know you need Dev Tools installed to get the Property List Editor, and in Mac OS X 10.4 and later, plist files are often in binary format (this includes Safari) so any old text editor isn't going to get the job done.

Terminal and /usr/bin/defaults are included in a standard install

Re:Local file (1)

viperidaenz (2515578) | about 7 months ago | (#45687073)

So when someone "just needs to send an email" there is no possibility they attach your plist file to the email they're sending, it's not like it is always stored in the same folder with the same name they can just type in to the file browser dialog... oh wait...

Re:Local file (1)

Anonymous Coward | about 7 months ago | (#45683875)

Ahem. What about when you're "shopping for presents" on a shared computer, and you don't want the other users to know about which "presents" you were looking at?

First-world problems strike again! (0, Funny)

Anonymous Coward | about 7 months ago | (#45684019)

What a tragic first-world problem. Do we need to hold candlelight vigils to share in this tragedy?

Re:First-world problems strike again! (0)

Anonymous Coward | about 7 months ago | (#45684105)

If you're not in the "first world", you don't have much incentive to read slashdot...

Re:First-world problems strike again! (3, Funny)

NoNonAlphaCharsHere (2201864) | about 7 months ago | (#45684117)

We're talking about Macs. It's a first-world problem by definition.

Re:First-world problems strike again! (0)

Anonymous Coward | about 7 months ago | (#45684565)

It's true: Macs are a first-world problem.

Re:First-world problems strike again! (0)

Anonymous Coward | about 7 months ago | (#45684689)

Not true. They are also problems for the third-world slaves who make them.

Re:Local file (0)

Anonymous Coward | about 7 months ago | (#45683897)

No if someone else is writing and executing files on your computer your screwed (especially with root access) having read access, while undesirable, shouldn't reveal any of your passwords.

Re:Local file (1)

g0bshiTe (596213) | about 7 months ago | (#45684139)

From the link submitted with the summary

You can just imagine what would happen if cybercriminals or a malicious program got access to the LastSession.plist file on a system where the user logs in to Facebook, Twitter, LinkedIn or their online bank account.

I'd consider that to be a goatse sized hole.

Re:Local file (0)

Anonymous Coward | about 7 months ago | (#45684353)

Sigh, this is what happens when you give Unix to Mac users.

Unix is a multi-user system. If someone else is reading files on your computer then that'll be because the files have group/world read permission set. And if software is setting that bit for private user data, the software is at fault.

Re:Local file (1)

arth1 (260657) | about 7 months ago | (#45684393)

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

Many of us here grew up with multiuser systems, and don't see what the problem is with that.

Re:Local file (2)

BasilBrush (643681) | about 7 months ago | (#45684629)

Right, and the multi-user element of OSX will prevent other users from reading this file.

Re:Local file (1)

LordLimecat (1103839) | about 7 months ago | (#45684859)

Presumably said plist file is stored in the user's profile, where on any current OS that would mean that noone other than a superuser or the user themselves could access it.

Re:Local file (1)

rsborg (111459) | about 7 months ago | (#45684675)

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

This has issues for backups as well - you may have been very good at prevent physical/console access to your computer, but if someone gets an old backup that happens to be unencrypted, your secure browsing history is now exposed.

Your entire premise is an argument against defense-in-depth multilayered security policy. I'd go with the expert-guided policy against your pithy analysis.

Re:Local file (1)

LordLimecat (1103839) | about 7 months ago | (#45684873)

If you include the encryption key with the backup, it doesnt matter either way. If you dont, its not a terribly useful backup.

Re:Local file (0)

Anonymous Coward | about 7 months ago | (#45686941)

My god, talk to your local psychiatrist, you ARE paranoiac, in the clinical sense. Get help now and god bless you.

Re:Local file (5, Informative)

Anubis IV (1279820) | about 7 months ago | (#45684799)

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.

Re:Local file (0)

Anonymous Coward | about 7 months ago | (#45685139)

The original article *does* say it applies to 6.0.5 on OS X 10.8 and 10.7, and how they "informed Apple about the issue"

My guess would be they wrote it on Oct 13 and put it in the blog's queue to publish after 3 months to give Apple time to react, and then forgot to edit or delete it, as it sounds pretty silly to "inform Apple" about the problem that's explicitly fixed in a long since released security update.

Re:Local file (1)

Anubis IV (1279820) | about 7 months ago | (#45687021)

The original article *does* say it applies to 6.0.5 on OS X 10.8 and 10.7, and how they "informed Apple about the issue"

Mentioning it's a problem with 6.0.5 is fine (and I never said that they didn't). My problem with the reporting in both articles and the summary is that it's not made clear that 6.0.5 is an outdated version (all of the verbiage paints it as an issue affecting the latest version), nor is it made clear to users that they can solve this issue by simply applying a software update that's been available for nearly two months. That's a disservice to their readers, who may be affected by the issue, since they're not telling them how to fix it, and it's a disservice to Apple, since they're implying that the issue hasn't been fixed, when it has.

Your idea about setting a future publication date and then forgetting not to publish it makes a lot of sense, but they've had plenty of time to take it down, retract it, or post an update/edit to it to point users towards the fix or inform people that the information in their report may be outdated, yet they've done none of those. Even worse, the second article is now linking to Slashdot's coverage of the topic in order to reinforce that this is a serious issue.

Re:Local file (0)

Anonymous Coward | about 7 months ago | (#45686187)

Except for all of those people for whom 10.6 is the last OS X release that's permitted to be installed on their hardware. I have a Core 1 Duo stuffed with RAM that's perfectly usable still; it may end up running Linux before too long (and gaining an additional 7-10 years of life over the Apple-supported software).

Re:Local file (1)

Anubis IV (1279820) | about 7 months ago | (#45686927)

Safari 6 is not and has never been available for OS X 10.6, so those users don't face this issue. That's why I restricted my comments to 10.7-10.9.

Re:Local file (1)

vlueboy (1799360) | about 7 months ago | (#45687133)

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.

Here is a little known technicalities about version-itis: Back in the days of IE6 on Windows, the powers that be decided that IE5 would be the last version of the browser on Macs. Likely they didn't feel like supporting [and putting up with APIs from] the competition. *

Safari 5 for Windows is following in the same steps. It's two years out of date, behind Safari 7. Yet iTunes bugs Windows users with the latest revenue-increasing upgrades despite the platform gap. The official Safari 5 for Windows binaries were relegated to cumbersome search item out of dozens of others in the support subdomain with no apologies or even footnotes.
I have little sympathy for Apple's short support cycles starting with their iMac-era financial rebirth. iOS OTA updates seem to be the exception rather than norm.

* At some point around 2005 or so, the IE5-for mac download site at Microsoft stopped linking the software, actually encouraging users to get alternative browsers. Moment of silence for the likes of iCab, Netscape and Camino, whose names we used to respect but have forgotten in the wake of Webkit^W safari, Opera, Firefox and eventually Chrome.

Perhaps... (0)

Anonymous Coward | about 7 months ago | (#45683827)

Perhaps they should fire a darkness ray at it...

Hey (5, Funny)

NoNonAlphaCharsHere (2201864) | about 7 months ago | (#45683839)

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

Hmmm .... (5, Interesting)

gstoddart (321705) | about 7 months ago | (#45683849)

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.

Re:Hmmm .... (1)

JustOK (667959) | about 7 months ago | (#45683945)

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

Works fine under wine in a vm running in the cloud.

Re:Hmmm .... (3, Informative)

XxtraLarGe (551297) | about 7 months ago | (#45684283)

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:Hmmm .... (2)

BasilBrush (643681) | about 7 months ago | (#45684655)

So, as far as I can tell, Safari doesn't actually block 3rd party cookies despite saying it does

Any evidence for you claim?

Chrome sucks, Safari sucks, IE sucks. FF FTW. (1)

rsborg (111459) | about 7 months ago | (#45684699)

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.

Re:Chrome sucks, Safari sucks, IE sucks. FF FTW. (1)

mlts (1038732) | about 7 months ago | (#45684785)

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.

Re:Hmmm .... (0)

Anonymous Coward | about 7 months ago | (#45686111)

So, as far as I can tell, Safari doesn't actually block 3rd party cookies despite saying it does

If only Google had known what you know... They could have avoided that multimillion dollar settlement for privacy violation for the workaround they ("inadvertently") used.

Why the surprise? (5, Insightful)

QuietLagoon (813062) | about 7 months ago | (#45683869)

...'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? (0)

Anonymous Coward | about 7 months ago | (#45683953)

It's surprising that sensitive information (password) being stored on a computer isn't being encrypted first, but instead is visible for all to see. Your right this is no fault of HTTPS this is a flaw in safari.

Re: Why the surprise? (1)

xelah (176252) | about 7 months ago | (#45684037)

We're you asked for a password for accessing the data? If not, then you really shouldn't be surprised. What did you think it was doing? It can't meaningfully encrypt it without a key.

Re: Why the surprise? (1)

Havokmon (89874) | about 7 months ago | (#45684209)

We're you asked for a password for accessing the data? If not, then you really shouldn't be surprised. What did you think it was doing? It can't meaningfully encrypt it without a key.

A session ID would tell the server you were already, or previously, authenticated. It's up to the server to determine if you are still authenticated between browser sessions.

Saving the password, encrypted or not, is not necessary.

Of course, we're assuming the researcher didn't check the "save password' box, and then go 'OMG! My password is in clear text but the site is HTTPS!'. If that were true, then he's a moron. I hope they peer review their releases.

Re:Why the surprise? (5, Informative)

yincrash (854885) | about 7 months ago | (#45684083)

Pidgin (formerly gaim) also keeps unencrypted creds. This is their reasoning. [pidgin.im] .

Re:Why the surprise? (0)

Anonymous Coward | about 7 months ago | (#45684239)

As does filezilla - people have been using that little hole to get root for a while now

Re:Why the surprise? (0)

Anonymous Coward | about 7 months ago | (#45684749)

Pidgin (formerly gaim) also keeps unencrypted creds. This is their reasoning. [pidgin.im] .

I understand their logic, and it makes sense I guess because they don't want to roll their own keyring system, but they really should make every attempt to integrate with any available system keyring out there.

A centralized backup system could easily hoover up these files in a corporate environment and expose the information to an additional set of access controls and people.
It's just an unnecessary additional attack vector that can allow people to impersonate other people in a complex environment. Your Kerberos stuff will expire somewhat quickly, but your password is sensitive for much longer.

Re:Why the surprise? (2)

robmv (855035) | about 7 months ago | (#45684801)

Wrong, use the OS provided keyring (OS X Keychain, GNOME keyring, Windows Credentials API, etc.) that protect your passwords with your local user credentials and only allow direct reading by the application that stored them. It is true that if your computer is compromised passwords are not safe either, but not all compromises have the same kind of access to a decrypt a keyring, but most if not all can read plain text files.

Re:Why the surprise? (1)

AHuxley (892839) | about 7 months ago | (#45685571)

Yes it provides one final task for malware to decrypt vs a plain text file for any gov/gov trained staff or skilled person to just 'find' as needed.

Re:Why the surprise? (1)

jones_supa (887896) | about 7 months ago | (#45685003)

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

Of course not, and no one is claiming that. What the article tries to say with "despite the use of https", is that the browser should do the right thing and continue the chain of safety when it has dealt with HTTPS material.

Re:Why the surprise? (0)

Anonymous Coward | about 7 months ago | (#45686777)

It is security on communication not on data! HTTPS is secure protocol to communicate between the server and the client(browser). It does not enforce what to do with session information so saying "despite the use of https" is moot. Encrypting session data is good but use of HTTPS to talk to the server has nothing to do with IT! Get it? They are separate things!

Really, Slashdot? (4, Informative)

RedBear (207369) | about 7 months ago | (#45683915)

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:Really, Slashdot? (1)

Geoffrey.landis (926948) | about 7 months ago | (#45684025)

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

Re:Really, Slashdot? (5, Informative)

RedBear (207369) | about 7 months ago | (#45684243)

...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:Really, Slashdot? (1)

Maestro485 (1166937) | about 7 months ago | (#45684371)

The LastSession.plist file stores way, way more data than just URL's.

When I log into my bank account, my username and password are not in the URL and certainly not passed unencrypted over the wire. They are happily stored in the LastSession.plist file though.

I'm using Safari 7 on Mavericks, so it clearly isn't fixed in the latest version.

Re:Really, Slashdot? (1)

RedBear (207369) | about 7 months ago | (#45684695)

The LastSession.plist file stores way, way more data than just URL's.

When I log into my bank account, my username and password are not in the URL and certainly not passed unencrypted over the wire. They are happily stored in the LastSession.plist file though.

I'm using Safari 7 on Mavericks, so it clearly isn't fixed in the latest version.

So you're saying you found your banking website login credentials stored in plain text in your LastSession.plist file while you were using Safari 7, and that information is absolutely not in the URL of the web page?

I can't replicate this using my banking site with Safari 7.0 on Mavericks. Nothing shows up when I grep my LastSession.plist file after logging in to my bank's website. Not my username or my password. By all means report it if true. I can't imagine how Apple would really be dumb enough to store secure login data that belongs in the keychain in a simple plain text plist file, but if you have evidence that they are that dumb, reveal it. They should by all means be slapped if so.

The only evidence that I've so far seen is a screenshot of login credentials revealed in a URL, which they just didn't encrypt in exactly the same way that bookmarks aren't encrypted. What you're claiming you've seen would be a far worse security screw up than just storing URLs unencrypted.

Re:Really, Slashdot? (1)

BasilBrush (643681) | about 7 months ago | (#45684735)

The LastSession.plist file stores way, way more data than just URL's.

Yeah, it stores window sizes and stuff like whether toolbars and tabs are hidden. Big deal.

http://www.appleexaminer.com/MacsAndOS/Analysis/HowTo/SafariBrowserAnalysis/files/multiple-lastsession.png [appleexaminer.com]

When I log into my bank account, my username and password are not in the URL and certainly not passed unencrypted over the wire. They are happily stored in the LastSession.plist file though.

Feel free to supply a suitably masked copy of the lines from your own LastSession.plist that you believe is doing that.

Re:Really, Slashdot? (0)

Anonymous Coward | about 7 months ago | (#45684593)

Look closer. It's not the part of a URL - it's a part of form data.

If you track back, you'll see that URL is just "http://gmail.com/", and then follows "application/x-www-form-urlencoded", which contains that login and password.

It doesn't show up on the screen like that - it's sent as a POST request, and "restoring the session" this way in this specific case sounds weird - there's that thing called "cookie", which keeps your session open between browser shutdowns, is not replayable and doesn't contain the auth info to steal...

Re:Really, Slashdot? (1)

RedBear (207369) | about 7 months ago | (#45685001)

Look closer. It's not the part of a URL - it's a part of form data.

If you track back, you'll see that URL is just "http://gmail.com/", and then follows "application/x-www-form-urlencoded", which contains that login and password.

It doesn't show up on the screen like that - it's sent as a POST request, and "restoring the session" this way in this specific case sounds weird - there's that thing called "cookie", which keeps your session open between browser shutdowns, is not replayable and doesn't contain the auth info to steal...

If this is true (and it certainly appears to be), then I guess that implies that the user credential data was in fact constructed by Safari and not included in a URL by the website, and I'm a moron and most of my previous posts should be modded down to oblivion. Also, Apple should be slapped for bad security practices and revealing user passwords and logins in plain text outside of the keychain. Unfortunately I am at my limit of knowing how to parse the information from the screenshot and know where it really came from. So, I'll shut up now.

I can at least confirm that passwords are not revealed in this way with Safari 7.0 on Mavericks. When I log in to Gmail and grep for my password in LastSession.plist I get no match.

Re:Really, Slashdot? (0)

Anonymous Coward | about 7 months ago | (#45685061)

Actually, some other comment on this page claims it's fixed in 6.1, available for older OS X versions since October, and the article speaks about 6.0.5.

Still, article says how they "informed Apple about the problem" - may be they had that post hidden after disclosure to Apple to give them time to fix it, and now it auto-published or something...

Re:Really, Slashdot? (1)

viperidaenz (2515578) | about 7 months ago | (#45687101)

It doesn't appear the login and password are stored in the URL.
It appears they're the body of a POST request, hence the url-encode/www-forms shit that precedes it.
So what really happened, was there was a form being submitted to an HTTPS url. That data was never sent anywhere in plain text. Safari then stored the entire request in plain text and saved it to the hard drive.

Re:Really, Slashdot? (1)

Anonymous Coward | about 7 months ago | (#45684119)

SSL (https) only sends the HOST as part of the request header unencrypted, the /GET (i.e. path and variables) are transmitted encrypted. Therefore the full URL with paths and variables exposes more than what would normally be visible "over the wire".

Re:Really, Slashdot? (1)

RedBear (207369) | about 7 months ago | (#45684361)

SSL (https) only sends the HOST as part of the request header unencrypted, the /GET (i.e. path and variables) are transmitted encrypted. Therefore the full URL with paths and variables exposes more than what would normally be visible "over the wire".

Thanks, I didn't know that.

Nevertheless the practice of putting login credentials in the URL is extremely bad and the session file with saved URLs is just one of several places where someone accessing your computer can see URLs, like in the address bar itself and in saved bookmarks. Encrypting the session file is sort of like putting a bandaid on a severed femoral artery. Another bandaid would be encrypting HTTPS bookmarks and obscuring the text in the address bar on HTTPS sites unless you enter a master password to reveal it. But that would be kind of ridiculous, wouldn't it?

The websites that are still putting your username and password in their URLs are the ones who should be named and shamed. Whether they are using SSL or not, it's a terrible practice, for precisely the reason that you have no idea how the URLs may be stored or revealed by the end user's computer.

Re:Really, Slashdot? (1)

kwark (512736) | about 7 months ago | (#45684479)

"Thanks, I didn't know that."

You didn't know that because it is not true. SSL encrypts everything before anything is send. That is why (before SNI) it is impossible to have multiple certificates for multiple virtualhosts on 1 ip adress: the host that is being queried and has to match a certificate CN isn't known at the time of the SSL handshake.

Re:Really, Slashdot? (0)

Anonymous Coward | about 7 months ago | (#45686809)

Apache has supported "multiple certificates for multiple virtual hosts on 1 ip address" for quite some years already. You probably haven't checked almost for a decade!

Re:Really, Slashdot? (1)

pegr (46683) | about 7 months ago | (#45684703)

Almost right. The host header is encrypted. The target IP address is in-the-clear for obvious reasons. Your IP stack does not connect to DNS names. It connects to IP addresses. DNS resolves the DNS name, then the stack connects to the address.

Now the DNS name might be unencrypted during the SSL negotiation, but that's not the HTTP header, as your browser has to decide if it likes the SSL cert before it negotiates. Part of that check is "does the host name match the cert?". I'd look up SSL negotiation details, but I'm lazy.

Re:Really, Slashdot? (1)

viperidaenz (2515578) | about 7 months ago | (#45687139)

Unless you're connecting through a proxy, then the CONNECT command sends the hostname, not the IP, since your machine may not have access to a DNS server that can resolve hostnames outside the local network.

Re: Really, Slashdot? (0)

Anonymous Coward | about 7 months ago | (#45684615)

Forth, the entire flash storage is encrypted with the unlock keypad or pin.

Comparison? (1)

Anonymous Coward | about 7 months ago | (#45683941)

What do other browsers do?

Re:Comparison? (1)

unixisc (2429386) | about 7 months ago | (#45684043)

Particularly Camino?

Re:Comparison? (1)

thedbp (443047) | about 7 months ago | (#45684533)

I'd mod this Funny if I had points, but I don't, so I'll just say thanks for the laugh.

Not in current version (0)

Anonymous Coward | about 7 months ago | (#45683943)

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

Re:Not in current version (5, Informative)

Anonymous Coward | about 7 months ago | (#45684007)

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

HEY !! IT IS APPLE !! CUT THEM SOME SLACK !! (-1)

Anonymous Coward | about 7 months ago | (#45683959)

Apple Knows How to Do Bling !!
Apple Knows How to Do NOTHING Else !!

only if window is still open at quit (1)

hyperorbiter (876833) | about 7 months ago | (#45683983)

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

Massively overblown issue? (4, Insightful)

Alsee (515537) | about 7 months ago | (#45683985)

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?

-

Re:Massively overblown issue? (1)

tlhIngan (30335) | about 7 months ago | (#45684049)

Perhaps secure sessions shouldn't be restorable?

Which is great, if there aren't sites that use HTTPS because they can, thus making session restore completely useless.

It's fine if it's only stuff that needs to be secure like your banking and such, but when they start securing web forums and other things....

Re:Massively overblown issue? (0)

Anonymous Coward | about 7 months ago | (#45684297)

Better fix. Everyone stop being lazy and requiring that their web browser re open all pages that you had open previously? It would take less time, processing power, and bandwidth to only open the one page you need than to restore all 500 tabs at once (even if they don't "load the page" until you click on them).

Secret side effect: Everyone would start to notice their memory improving slowly over time due to having to actually remember things.

Re:Massively overblown issue? (1)

chuckugly (2030942) | about 7 months ago | (#45684073)

Or they should require the user to re-enter the credentials during the restoration.

Re:Massively overblown issue? (1)

Dynedain (141758) | about 7 months ago | (#45684307)

If the browser prompted for a password every time it was launched, you'd quickly find that most people would disable the feature.

The need for security like this has to be weighed against the desire for convenience.

Re:Massively overblown issue? (1)

kwark (512736) | about 7 months ago | (#45684527)

OSX appears to have something called a keychain, store the password to crypt there and keep the store encrypted.

Re:Massively overblown issue? (1)

keytoe (91531) | about 7 months ago | (#45684563)

Or they should require the user to re-enter the credentials during the restoration.

Technically, that's what happens. Safari doesn't store any credentials itself, they're stored in the system keychain and Safari asks the keychain whenever it needs a key. The keychain itself has a master password and its contents are encrypted.

On the other hand, by default the keychain password is set to the login password and is automatically unlocked when the user logs in. Further, most users choose to have their computers automatically log in at boot - so there is no effective protection if someone gets ahold of their computer.

You can change those defaults to be more secure. Apple chose not to make that the default as most people simply don't care.

Personally, my keychain password is different, my computer doesn't automatically log me in, and the keychain locks itself after 15 minutes or system sleep. This is annoying as I have to authenticate myself every time an application needs something from the keychain - something a regular user wouldn't put up with.

Re:Massively overblown issue? (0)

Anonymous Coward | about 7 months ago | (#45687151)

Absolutely key point here. There's another aspect that no one seems to be considering..so okay, the malware or hacker is local on my system, what is to stop them from overwriting a shared library or similar that my browser uses? So.. the credentials are stored encrypted-- right next to the key used to decrypt it. And great, okay, lets prompt the user for a password to decrypt the encrypted key to decrypt the encrypted session data.. and we're going to protect the libraries from the attacker and make sure that password prompt isn't actually just a trojaned version of the prompt how exactly?

Oh I know, we could sign all of the libraries and executables and then require a password to load unsigned ones.. wait thats called UAC and no one likes that, besides, then Iran will just hack a registrar and get signed binaries and the NSA will just FISA their way into it. HRM.

Okay, well fuck it, store the data unencrypted because there is no sane way to secure it that doesnt recursively make the users life a pain in the ass for an attack scenario that in essence truly doesnt matter. You don't even know youre actually executing safari at that point and we're blathering about a .plist file.

The missing store nothing option (0)

Anonymous Coward | about 7 months ago | (#45684011)

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.

Information Loss? (2)

craighansen (744648) | about 7 months ago | (#45684123)

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?

More bad testing from Apple (-1)

Anonymous Coward | about 7 months ago | (#45684279)

And to think that Apple couldn't top the bug in which they released in (an early version of) Safari for Windows that only allowed one mouse button to be used for browsing.

My new plugin idea (1)

InlawBiker (1124825) | about 7 months ago | (#45685023)

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.

What browser doesn't? (1)

FuzzNugget (2840687) | about 7 months ago | (#45686235)

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.

Re:What browser doesn't? (0)

Anonymous Coward | about 7 months ago | (#45686341)

The point is, if you missed it, that those versions of Safari basically restore some of opened tabs on launch _by storing and re-sending authentication forms on those web pages_. It's not about cookies or form auto-fill and I don't think other browsers do that.

Exasperated sigh (2)

xfurious (832436) | about 7 months ago | (#45686465)

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 don't trust the programs running on your user account, or you are not correctly using the multi-user capabilities of your operating system, you can't really trust anything you do on it, and you can't really complain either. Because the industry already gave you the tools to protect yourself and you just didn't use them because you were lazy.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...