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

Gmail is opening and caching URLs within emails without user intervention (2019)

support.google.com

Post reply on HN
Print view View original

241–250 of 271 posts

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#241

Post by weird-eye-issue »

bawolff wrote: post #209
weird-eye-issue wrote: post #199

Earlier quoted context omitted.

Obviously you need to make sure your API is not susceptible to CSRF but that goes without saying... Should I also tell him to password protect his database? :P

If you follow what the parent is suggesting (open a page with a get request that has js which does a post request automatically with no user interaction), its probably impossible to not be susceptible to csrf

I'm really not sure why you think that, but that's just not true at all. For starters, if it is a JSON API then a CORS request will be done for all cross-domain API requests. Even a missing CORS configuration would then block the CORS request from third-party domains.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#242

Post by Silhouette »

skybrian wrote: post #238
Silhouette wrote: post #237

Earlier quoted context omitted.

Yes, I understand the reason for the standards, and other things being equal I am all for following them. I just think it's strange that an organisation spying on someone's communications and then doing anything it otherwise couldn't and breaking anything as a result should be getting such a free ride. There is no law that says any web application you write has to follow those standards, and the only reason not doing…

There are other reasons but you're ignoring them.

What, specifically?

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#243

Post by skybrian »

Silhouette wrote: post #242
skybrian wrote: post #238

Earlier quoted context omitted.

There are other reasons but you're ignoring them.

What, specifically?

Some other software, other than Google, might follow the link automatically. Because the standard allows that.

(Also, consider mistaken clicks, which happen all the time on touch screens.)

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#244

Post by kevin_thibedeau »

input_sh wrote: post #90
kevin_thibedeau wrote: post #80

Earlier quoted context omitted.

That presumes everyone executes random JS or has a browser that supports it.

Create a "click here" button, hide it by adding it a class or a style with JS.

There is this thing called an HTML form. Every browser supports it.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#245

Post by pwdisswordfish0 »

geofft wrote: post #235
pwdisswordfish0 wrote: post #156

Earlier quoted context omitted.

You're doing some subtle jiu jitsu and extracting a lot of benefit from responding to the previous message as if it said "if the names are not known to the public, then[...]". It does not. Resource identifiers, on the web[1], are not private names—not even by virtue of the fact they were communicated over a private channel—and they need to be treated as public, full stop. URLs are not private names, simply because of…

I'm not following your argument. What is this thing that URLs are which makes them public? For instance, I could argue "Fingerprints are not passwords, and they need to be treated as public, because of what they are" - because I can finish that sentence with "and what they are is a pattern that's left on every single random thing you touch, and is also immutable and impossible to rotate." What's the analogous thing f…

> I'm not following your argument.

It's almost certainly true that you do, you're just being dishonest. (The alternative is worse.)

> What is this thing that URLs are which makes them public?

You mean other than being identifiers (universal identifiers, at that)? It's like you've never used or encountered someone else articulating an argument that incorporates (or would be appropriate to incorporate) the phrase "by definition" before.

If your security protocols are compromised by the card catalog or the Rolodex being invented—compromised not by knowing the contents of a given resource, but by knowing the correct way to refer to or otherwise describe the identity of that resource—then you don't really have very good security in your protocols (particularly in a world where those things have already been invented).

> What's the analogous thing for URLs?

What? What a bizarre request.

The next time someone asks you to make your case in terms of bad analogies just because they can't get away from using them themselves, you can go ahead and say, "No, thanks. I'll pass."

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#246

Post by pwdisswordfish0 »

geofft wrote: post #236
pwdisswordfish0 wrote: post #162

Earlier quoted context omitted.

> But that's hardly a reason to say that logging into a website with a password or presenting a cookie doesn't count as an authentication system! That's fine. No one is saying that. They're saying that URLs aren't an authentication (or authorization) system.

I agree no one is saying that. I think they are being unsound in refusing to say that but also saying that URLs don't count as an authentication system. Is the argument "Information in an email should be treated as public"? Then how do you validate users on signup in the first place? How do you ensure that someone owns an email address that they claim to own? Is the argument "Information sent over HTTPS should be tre…

"Is the argument [...]? Is the argument [...]? If the argument is something else, what is it?"

This not difficult at all. Playing dumb isn't clever, it's just obnoxious.

The argument, stated amply before, is that URLs are not private.

Email being a private medium or not is orthogonal.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#247

Post by pwdisswordfish0 »

Silhouette wrote: post #225
pwdisswordfish0 wrote: post #162

Earlier quoted context omitted.

> But that's hardly a reason to say that logging into a website with a password or presenting a cookie doesn't count as an authentication system! That's fine. No one is saying that. They're saying that URLs aren't an authentication (or authorization) system.

They're saying that URLs aren't an authentication (or authorization) system. I'm curious to know how those advocating a position similar to this think something like a password reset facility on a website should work. We all know security-sensitive systems should rely on alternative methods of authentication anyway, but for those of us living in the real world where billions of people access millions of systems via w…

What relation does your question have to the statement you're quoting?

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#248

Post by bawolff »

weird-eye-issue wrote: post #241
bawolff wrote: post #209

Earlier quoted context omitted.

If you follow what the parent is suggesting (open a page with a get request that has js which does a post request automatically with no user interaction), its probably impossible to not be susceptible to csrf

I'm really not sure why you think that, but that's just not true at all. For starters, if it is a JSON API then a CORS request will be done for all cross-domain API requests. Even a missing CORS configuration would then block the CORS request from third-party domains.

So the situation is: there is some url you open (with a normal get request. Typically but not neccesarily from an email), then that url does the non-idempotent POST request without any futher user interaction.

A malicious page that knows the url used in the email could open the url from the email in a popup. The js will execute in the popup, and do the POST request. It doesn't matter how much csrf protection you have on the POST step, if anyone can trigger it with no user interaction just by opening some page with a GET request.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#249

Post by weird-eye-issue »

bawolff wrote: post #248
weird-eye-issue wrote: post #241

Earlier quoted context omitted.

I'm really not sure why you think that, but that's just not true at all. For starters, if it is a JSON API then a CORS request will be done for all cross-domain API requests. Even a missing CORS configuration would then block the CORS request from third-party domains.

So the situation is: there is some url you open (with a normal get request. Typically but not neccesarily from an email), then that url does the non-idempotent POST request without any futher user interaction. A malicious page that knows the url used in the email could open the url from the email in a popup. The js will execute in the popup, and do the POST request. It doesn't matter how much csrf protection you have…

> A malicious page that knows the url used in the email could open the url from the email in a popup

Sorry but this whole scenario is just ridiculous. If somebody can access your email it is already game over. It doesn't matter what web technology you are using at the that point, user interaction or not.

If a "malicious page" knows the URL it doesn't matter at all because it means it is capable of arbitrary code execution and that point it could just exfiltrate the URL to somebody or a Chromium instance to perform the user interaction. Actually if the page can open a popup I think it could also execute JavaScript within the context of the page and perform the user interaction right there.

Re: Gmail is opening and caching URLs within emails without user intervention (2019)

#250

Post by eyelidlessness »

obuda wrote: post #205
eyelidlessness wrote: post #201

Earlier quoted context omitted.

It’s likely faster for the noscript case.

Yeah, I don't know about that. Wouldn't it be that the query strings differentiate the two links? I assume so, because of an old trick where query strings are used for ad-hoc cache control as in /style.css?1629472765

You’re right, I wasn’t paying close enough attention. That’s what I get for reading HN mostly on my phone!
Post reply on HN