Improving privacy and security on the web • Hacker News Board

Re: Improving privacy and security on the web

#61

Post by tptacek » Wed, May 08, 2019, 5:45 PM UTC

progval wrote: post #54

olliej wrote: post #50

Earlier quoted context omitted.

Can a user meaningfully determine the correct answer to that question? The experience is “I clicked no and nothing worked” vs “I clicked yes and the site worked”. I get that you don’t like it, but the reality is that the web is a platform that includes JS as a core technology. The reason for limiting java and activex was because they had catastrophically terrible security properties more or less by design. Even flash…

> Can a user meaningfully determine the correct answer to that question? > The experience is “I clicked no and nothing worked” vs “I clicked yes and the site worked”. I agree; but the extra click may be an insentive for web developpers to try not to use JS. > Which is why you weren't asked about running flash on every website you went to. Firefox did ask about running Flash, because "attackers can also use the securi…

Just as long as we're all clear that this is not a real debate, and a serious programming language connected to the DOM is not going anywhere; you are stuck with that design.

Re: Improving privacy and security on the web

#62

Post by Ajedi32 » Wed, May 08, 2019, 7:29 PM UTC

akersten wrote: post #25

This is great - the `SameSite=lax` attribute is arguably how cookies should have worked in the first place, and I'm quite pleased that it's an existing RFC and not a proprietary change being done just in Chrome. Hopefully other browsers follow suit. What worries me is the vague commitment to stop browser fingerprinting - not a lot of detail there and I'm fearful that useful features might be getting crippled. I don't…

The reason this is related to browser fingerprinting is that cross-site cookies aren't _just_ used for CSRF, they're also a way to track users across sites.

With this change, developers will have to _explicitly_ declare when they're using cookies for that purpose (by setting SameSite=none) which makes it easier for browsers to identify cookies used for tracking and give users control over them.

Re: Improving privacy and security on the web

#63

Post by jedimastert » Thu, May 09, 2019, 1:27 AM UTC

incompatible wrote: post #24

34r45sdg wrote: post #5

Is this another way for Google to prevent you from clearing their cookies via the 'Clear Cookies' option? Its a step in the right direction with enforcing SameSite cookie scoping, but we must be cautious that Google doesn't use this to force you to always be logged in. Google has a long way to go to rebuild trust after that last browser login debacle. I don't trust em.

Does Chrome support automatically clearing cookies at shutdown yet? I seem to remember it didn't but I haven't used it recently. Edit: I searched for it, and it seems they have added the feature, but maybe not the related feature of clearing browsing history at shutdown.

Isn't that exactly what Incognito mode does?

Re: Improving privacy and security on the web

#64

Post by rob-olmos » Thu, May 09, 2019, 10:08 AM UTC

tptacek wrote: post #11

Wow, if this works, this is basically the end of CSRF. Essentially: CSRF relies on an HTTP POST to VICTIM.COM triggered by HTML on EVIL.COM, and that request carrying cookies. Today, even though SameSite exists, the default --- SameSite=None --- maintains that longstanding status quo. But after the change, the Chrome default will be SameSite=Lax, and while EVIL.COM will still be able to trigger POSTs to VICTIM.COM, t…

Is a SameSite=Strict cookie sent if VICTIM.COM does a redirect?

If so, it sounds like the next trick to follow would be a type of "redirect gadget" to get SameSite=Strict to be exploitable again. If so, maybe it's only the end of CSRFs without a gadget.

Eg of "redirect gadget", CSRF via VICTIM.COM/open-redirect?url=/update-password...