5 ms·
There has got to be a sensible way around this. It seems overkill to require every pageview to be over HTTPS, even for otherwise public sites. For example, shou
by al_james 16y ago
There has got to be a sensible way around this. It seems overkill to require every pageview to be over HTTPS, even for otherwise public sites. For example, should these public discussion pages be over HTTPS on hacker news?
On my site I am planning the following: operate the login page over HTTPS and issue two cookies. One is HTTPS only and other other is for all pages. The public (non HTTPS) cookie is only used for identification (e.g. welcome messages and personalisation). However, all requests that change the database in any way are handled over HTTPS and we check to make sure the user has the secret HTTPS cookie as well. Often forms submit to a HTTPS backend and then redirects back to the public page over HTTP. Also, all account information pages (sensitive pages) will be over HTTPS.
This way, the worst that can happen via cookie sniffing is that someone can see pages as though they were someone else. In your case, this is not much of a risk.
- mike-cardwell 16y agoThis is just dangerous. Example. If news.ycombinator.com implemented this dual cookie method. A man in the middle could intercept the page I'm looking at now, where I'm entering this comment in a textarea. They could modify the underlying form to post to the same page as the update form on the profile page, and set a hidden email field. Then when I hit the "reply" button, even though I'm posting to a HTTPS page, I'm not posting to the one I think I am, because the page containing the form it's self wasn't protected by HTTP. I hope I explained that well enough. Mixed content is hard to do right. Forcing every page over SSL prevents anyone making any modifications to any page, and is just inherently safer.
- mapgrep 16y agoWait, if you've got the capability to intercept and rewrite arbitrary http forms, couldn't you just rewrite the homepage of Google.com the same way? The "action" attribute on the form gets changed to https -mybank- dot com slash profile, hidden fields are inserted, etc, and when the user clicks "Search" he's actually updating aforementioned profile page. If this is possible, then the dual cookie method would seem to make sense.
- mike-cardwell 16y agoTrue, as long as the site isn't doing referer checks, which most of them probably aren't. This is yet another argument for why the entire web should be secured with SSL.
- rimantas 16y agoThis is all true but it is somehow different from the topic: one cannot do this kind of attack easily just using Firesheep kind of tool. I think sometimes these discussions are carried away to far.
- al_james 16y agoWell, I would say its not 'just as dangerous' as a man in the middle attack is harder to set up. Good point though. Maybe this could be solved by including a unique access code with the form that is a hashed value of the user'id and the url that you are submitting to (with salting to make this unguessable). Simply check this value upon submission to make sure it matches the URL seen by the controller. That would prevent anyone rewriting a form to submit to a new endpoint.
- iampims 16y agoIsn't it why we need to implement xsrf protection on every form?
- mike-cardwell 16y agoCSRF protection should be implemented even if your entire site is protected by SSL. Also, I didn't say "just as dangerous", I said "just dangerous"
- al_james 16y agoSorry for misquoting you. However, with proper CSRF protection your man in the middle argument is not the case is it?
- brown9-2 16y agoIs all this extra effort really worth the alternative of just using HTTPS for everything? Have you really examined the extra cost of 100% https compared with the scheme you've outlined? Sounds like this idea would require a decent amount of effort to identify where to use https, to ensure that each privileged request is using https, etc. I can see that for some cases it is advantageous to stick to regular http for unimportant requests and use https for the important stuff, but I have a strong feeling that this is only applicable for the minority of use cases and websites.
- al_james 16y agoWe cant serve ads over HTTPS and we make most of our money from ads. So that would be very expensive!
- piotrSikora 16y agoYou're think about right solution, but you're overdoing it and in the end you're unnecessary complicating very simple thing. The simplest (and IMHO the best) solution is to have everything served over HTTP for unauthenticated users and everything served over HTTPS for authenticated users (this requires authentication cookie marked as "secure" and regular cookie "authenticated=true" that would redirect authenticated user to HTTPS version of the site in case that he/she would go to the HTTP site).
- al_james 16y agoBut then we can't server ads to signed in users which would be a large revenue cut for us.
- piotrSikora 16y agoOf course you can... unless you want to serve ads over HTTP, then indeed, you can't really do that.
- al_james 16y agoAll the advertising networks we deal with only offer HTTPS. Hardly any advertising networks support HTTPS.
- piotrSikora 16y ago...and if noone will complain about that then it won't change.