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!
Re:Local file (Score:5, Insightful)
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: (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: (Score:2, Insightful)
Defense in depth. Is that really so hard for people to understand?
Re: (Score:2)
Re: (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: (Score:1)
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: (Score:2)
"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: (Score:2)
Re: (Score:2)
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: (Score:2)
"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. T
Re: (Score:1)
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 tho
Re:Local file (Score:4, Insightful)
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: (Score:2)
Firefox can require the key to be typed in when you start it. Most operating systems provide some kind of secure key storage tied yo the binary.
The main problem with the way Safari does it is that anyone else with admin rights can get access. Typically Mac and Windows users all know the admin password because it is required often and they don't really understand the security implications of sharing it. Malware could also steal the data, including secure sessions like accessing web mail.
Re: (Score:2)
Firefox can require the key to be typed in when you start it.
Yep, and that is exactly how Safari could do better. Although it is bad if a program can access your local files, it can't do anything with those files as long as a passphrase is needed to decrypt them. Neither the Kaspersky article nor anyone here has mentioned this explicitly so far.
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
I dont care fuck all if someone knows that I had slashdot, arstechnica and newscientist opened last session.
You're missing the point. It's not hard to allow the browser to store your login credentials for webmail pages, your amazon account, etc. And as we all (should) know, if someone can get your email, they can set up a bunch of "forgot my password" requests at all your pseudosecure (bank website) places, retrieve the password reset emails, and off your money goes.
Re: (Score:2, Insightful)
Physical access = surfing history is the least of your problems.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
wow, you have awful friends
Re: (Score:2)
Re: (Score:1)
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?
Re:First-world problems strike again! (Score:4, Funny)
Re: (Score:2)
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: (Score:2)
Right, and the multi-user element of OSX will prevent other users from reading this file.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
If you include the encryption key with the backup, it doesnt matter either way. If you dont, its not a terribly useful backup.
Re: (Score:2)
If you include the encryption key with the backup, it doesnt matter either way. If you dont, its not a terribly useful backup.
Apple's Time Machine [apple.com] can use full disk encryption [cultofmac.com]. You need a password/passphrase to be able to read from the disk later, which is rather useful. If someone steals my iMac and my onsite backup, they can not access any data - the system, as well as the backup, are both encrypted.
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.
Re: (Score:2)
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 w
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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 no
Re: (Score:2)
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.
Hey (Score:5, Funny)
Hmmm .... (Score:5, Interesting)
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: (Score:2)
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 .... (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: (Score:2)
It's not just banking web sites too. Disqus and many others. :(
Re: (Score:2)
So, as far as I can tell, Safari doesn't actually block 3rd party cookies despite saying it does
Any evidence for you claim?
Re: (Score:2)
Empirically, when I disable 3rd party cookies and visit a web site with Safari, I see a large amount of 3rd party cookies. Try something juice like the LA Times which has crap tons of advertising sites.
So, assuming my instance isn't singularly broken, I conclude Safari does a piss-poor job of blocking 3rd party cookies.
Google and others figured a way around it, and in my experience, it's essentially useless. Hell, Google paid a fine [zdnet.com] for having done so.
Chrome sucks, Safari sucks, IE sucks. FF FTW. (Score:2)
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: (Score:2)
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.
Why the surprise? (Score:5, Insightful)
...'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: (Score:2)
...'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: (Score:2)
Re: (Score:2)
Again, no one is claiming that they are the same thing.
Perhaps you should chat with the author of the article. He seems to make that equation.
.
Maybe he did it just to grab headlines, or maybe he did it for other reasons. Who knows his intent?
The bottom line is that page hits = $$
He got a lot of page hits from the story here on /.
Re: Why the surprise? (Score:2)
Re: (Score:2)
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? (Score:5, Informative)
Re: (Score:3)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
...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? (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: (Score:2)
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: (Score:2)
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 s
Re: (Score:1)
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: (Score:2)
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.
I suspect that someone doesn't know exactly where the autofill passwords come from (Keychain) and assumes that they're in the LastSession properties list.
Re: (Score:2)
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: (Score:2)
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 real
Re: (Score:1)
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: (Score:2)
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 pa
Re: (Score:1)
"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: (Score:1)
And that technique is called: SNI
And even though the servers supported it for a "long" time, some clients didn't, most notably the mobile browsers.
Re: (Score:2)
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
Re: (Score:2)
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.
Comparison? (Score:1)
What do other browsers do?
Re: (Score:2)
Re: (Score:2)
I'd mod this Funny if I had points, but I don't, so I'll just say thanks for the laugh.
only if window is still open at quit (Score:1)
Re: (Score:2)
something worth telling users about until they install the fix that came out a couple months ago.
Massively overblown issue? (Score:5, Insightful)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:1)
OSX appears to have something called a keychain, store the password to crypt there and keep the store encrypted.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
That's when you store the key in the OS's keystore, so it at least requires the correct user to be logged in.
Information Loss? (Score:3)
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?
Re: (Score:2)
You'll first have to get them to make sure the story as a whole is correct - this issue has been patched for a while and only affects old versions of Safari that are limited to 10.7 and 10.8 (and an update on those older systems fixed it there too). Safari on 10.9 has never been affected.
This issue was fixed at least 2 months ago.
My new plugin idea (Score:2)
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? (Score:2)
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
Re: (Score:2)
I don't believe any other browser stores the data in a POST request to an HTTPS site.
Exasperated sigh (Score:2)
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 sh
Re: (Score:2)
Data sent over a secure connection should not be stored on the hard drive in plain text. The only place it should ever be is in the private memory space of the browser.
That's why your browser doesn't cache files from an HTTPS url on your hard drive.
Storing the URL for the history, not so bad
Storing the post data so it can be resubmitted, bad. A user should also always be warned when a post request is being resubmitted, since the HTTP RFC's only says get, head, put and delete should be idempotent.
RFC2616:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
Re: (Score:1)
A user should also always be warned when a post request is being resubmitted, since the HTTP RFC's only says get, head, put and delete should be idempotent.
RFC2616:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
While I agree with your sentiment here (I would prefer my browser to just not save any POST data at all for tab recovery since its so extremely rare that doing so would actually be useful), the RFC section you quote does not specify anything about persistence of resources to backing storage. It simply indicates the way browsers should treat these resources in a general sense. And according to the verbiage you have provided, Safari, Chrome and Firefox are all working as expected, because that paragraph is ac
Re: (Score:1)
Also (not to double post but), while I could have tested the assertion that browsers do not cache HTTPS resources, I think I will just let StackOverflow handle that one.
By default web browsers should cache content over HTTPS the same as over HTTP, unless explicitly told otherwise via the HTTP Headers received
http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https [stackoverflow.com]
That's from the accepted answer with 79 up votes. The second answer which has 119 upvotes says:
As of 2010, all modern, current-ish browsers cache HTTPS content by default, unless explicitly told not to.
Lack of encryption is not the issue (Score:2)
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.
Unable to replicate (Score:1)
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 l
Re: (Score:2)
You can't replicate it because Apple fixed this 2 months ago with Safari 6.1 on Lion/ML and with Safari 7 on Mavericks.
It only affects Safari 6.
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."