Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving privacy and security on the web

blog.chromium.org

Post reply on HN
Print view View original

11–20 of 64 posts

Re: Improving privacy and security on the web

#11

Post by tptacek »

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, those requests will no longer carry cookies.

To get the cookies to work from EVIL.COM, VICTIM.COM's developers will have to explicitly set SameSite=None on their session cookies. Which nobody will do, because nobody sets SameSite at all today.

Better still: 99 out of 100 CSRF exploits (maybe 999 out of 1000) target endpoints for which SameSite=None isn't needed; they're cookies nobody ever uses cross-site to begin with. There are only limited cases where anyone needs the behavior to change, and those cases don't track the most sensitive cookies.

As a vulnerability researcher for whom exploitable bugs mostly exist to spark joy: good riddance to CSRF. It was a dumb bug class, and never, ever fun to exploit.

Re: Improving privacy and security on the web

#12

Post by tptacek »

Boulth wrote: post #4
mikewest wrote: post #3

Earlier quoted context omitted.

We're proposing treating cookies as `SameSite=Lax` by default ( https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03... ). Developers would be able to opt-into the status quo by explicitly asserting `SameSite=None`, but to do so, they'll also need to ensure that their cookies won't be delivered over non-secure transport by asserting the `Secure` attribute as well. https://tools.ietf.org/html/draft-west-cookie…

This is exactly the information I was looking for when I opened chromium blog post. Technical and to the point. Is there a reason why this couldn't be appended to the blog post?

Because you aren't really the audience for that post, and they can safely assume you'll dig deeper anyways?

Re: Improving privacy and security on the web

#13

Post by tedivm »

tptacek wrote: post #12
Boulth wrote: post #4

Earlier quoted context omitted.

This is exactly the information I was looking for when I opened chromium blog post. Technical and to the point. Is there a reason why this couldn't be appended to the blog post?

Because you aren't really the audience for that post, and they can safely assume you'll dig deeper anyways?

If we're not the audience then who is? This was made to the Chromium open source blog, which is typically a developer heavy blog (with previous topics like "Hint for low latency canvas contexts"). Throwing a few reference links at the bottom shouldn't harm their message with the less technically savvy.

Re: Improving privacy and security on the web

#14

Post by tptacek »

tedivm wrote: post #13
tptacek wrote: post #12

Earlier quoted context omitted.

Because you aren't really the audience for that post, and they can safely assume you'll dig deeper anyways?

If we're not the audience then who is? This was made to the Chromium open source blog, which is typically a developer heavy blog (with previous topics like "Hint for low latency canvas contexts"). Throwing a few reference links at the bottom shouldn't harm their message with the less technically savvy.

I'm just guessing. Something else that sparks joy for me: the fact that Google will never give any of their announcements the titles they're justifying, like, "OMG, WE KILLED CSRF!", and that I'll have to dig in a bit to see how big a deal what they just did is. It's like every "Improving privacy and security on the web" is a little gift I get to unwrap. It's like Justin Schuh and Mike West's version of "one more thing".

Re: Improving privacy and security on the web

#16

Post by techntoke »

tptacek wrote: post #10
techntoke wrote: post #9

Really disappointed in you Google for not addressing fingerprinting much sooner.

Be disappointed all you want, but they're not really "addressing" fingerprinting. It is exceptionally difficult --- computer-science Hard difficult --- to prevent fingerprinting; all you can really do is break popular libraries people use today. It's an arms race, and a much harder arms race than exploit-hardened runtimes are.

It's actually pretty easy overall... just don't use JavaScript and don't send user-agent string that shows browser/OS information.

Re: Improving privacy and security on the web

#17

Post by techntoke »

zzzzzzqzzzzzz wrote: post #15

Not that any step towards additional privacy protections isn't a good thing, same for security. But Google has got to be one of the major contributors to the erosion of privacy. How about chrome nagging to have you sign in? How about their very own ad networks?

You mean like Firefox sync and Pocket? The so called founder of JavaScript was the CEO of Mozilla, and that is the biggest cause of erosion of privacy on the web.

Re: Improving privacy and security on the web

#19

Post by jakub_g »

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.

It's a way to fix one of the biggest security mistakes of the web (being able to send an _authenticated_ request - i.e. with cookies - to any domain from any other domain, for example from evil.com to youremailprovider.com with the payload "delete all emails"), that was kept on by default for two decades due to backward compatibility.

For a long time it required annoying workarounds (CSRF tokens) to have this security hole mitigated, then just an opt-in flag on the cookies, but as usual, most companies don't know/care about it, so having protection by default is the natural solution (although it _will_ probably break quite a few legacy websites, but for a greater good).

Re: Improving privacy and security on the web

#20

Post by ayrx »

techntoke wrote: post #16
tptacek wrote: post #10

Earlier quoted context omitted.

Be disappointed all you want, but they're not really "addressing" fingerprinting. It is exceptionally difficult --- computer-science Hard difficult --- to prevent fingerprinting; all you can really do is break popular libraries people use today. It's an arms race, and a much harder arms race than exploit-hardened runtimes are.

It's actually pretty easy overall... just don't use JavaScript and don't send user-agent string that shows browser/OS information.

You will be part of the rare minority that uses that configuration which by itself is a fingerprint.
Post reply on HN