61–70 of 121 posts
Earlier quoted context omitted.
Betfair is finally using all https. Their security was terrible because once you logged in, the site went back to http again. This meant that anyone on the same network could grab your cookies and take over your account...
That's not the half of it - if you knew what that cookie contained…
I don't understand the distinction between the login form and every other page of the site. If someone is logged in and then back to normal http, someone can just grab the cookie and pretend to be that person already-logged-in. I suppose if one uses the same password for every account they have then knowing their password is more harmful than just having access to 1 site... but other than that it seems like a distinc…
Prominent? A crossed over lock icon in the address bar? Try again. A prominent warning would be something ridiculous, like a full page cover saying "THIS PLACE IS NOT SECURE – HERE BE DRAGONS!" or something. Browser vendors should do more of this for egregious errors on the publisher's side. Unless users complain loudly that stuff is uncomfortable and broken and scary and what not, you can write articles like this ev…
Would be an interesting thing to do as a network operator - doing MITM to alert people about the dangers of HTTP.
there have been reports of replaced adds on unrelated pages with banners from the ISP and similar things
I have recently deployed Content Security Policy (CSP) on a website. When I first looked at violation reports, my jaw dropped. The amount of malware (rouge extensions, toolbars, viruses, ...) that is blocked is staggering. If you really want to help your (clueless) users, never ever serve a login, registration or credit card form without CSP. It really helps - at least until the malware catches on (I already see "Kas…
Is there a pre-built tool to capture and manage CSP violation reports? I believe its mainly just a POST request with some JSON right?
> If you’re submitting your login form over HTTPS, that’s good, but it’s not enough. You have to deliver* the form over HTTPS too.* I'm glad they mentioned it. Too many people think their sites are secure if logged in sessions use https and everything else is http. Their example is that an attacker could insert JavaScript to steal the password, however they could just as well change the form target from https to http…
I have recently deployed Content Security Policy (CSP) on a website. When I first looked at violation reports, my jaw dropped. The amount of malware (rouge extensions, toolbars, viruses, ...) that is blocked is staggering. If you really want to help your (clueless) users, never ever serve a login, registration or credit card form without CSP. It really helps - at least until the malware catches on (I already see "Kas…
>rouge extensions Man, World Of Warcraft flashbacks can be intense sometimes...
On sites that allow users to embed things like images (forums, comments, etc), in order to avoid mixed content warnings or interstitial confirmation dialogs, you either have to pipe everything through an SSL proxy, or severely limit the types of things users can embed.
Earlier quoted context omitted.
> If someone is logged in and then back to normal http, someone can just grab the cookie and pretend to be that person already-logged-in. If the cookie is set through HTTPS, the browser won't send it when loading HTTP resources. So the cookie won't be exposed that way. We should still be using HTTPS for all traffic in 2016.
If a website only uses HTTPS for login, then it has to set a cookie for HTTP as well, otherwise how will the user navigate the site after login? From top of my head, you can implement this by associating the randomly generated session ID that you assign to all visitors, with the login ID. Regardless, what jordanlev said still applies. The session can be hijacked.
> If you’re submitting your login form over HTTPS, that’s good, but it’s not enough. You have to deliver* the form over HTTPS too.* I'm glad they mentioned it. Too many people think their sites are secure if logged in sessions use https and everything else is http. Their example is that an attacker could insert JavaScript to steal the password, however they could just as well change the form target from https to http…
Is there a caching story to tell, here? In other words, is it possible that most web infrastructure is set up in such a way that caching is used to mitigate much of the load on the servers, and moving too many things to HTTPS too quickly would result in a MUCH greater content generation load?
The times I've implemented full-page caching (generally using Varnish) I've set it up so nginx runs in front of Varnish handling SSL termination, which means that I still have SSL support even though I'm serving through a cache.