Hacker News Reader

Comment by dotBen | Hacker News Reader

Side note - proliferating the use of other top-level domains for official use (as they have done here for their tech blog) certainly doesn't help Dropbox's security envelope when it comes to phishing.

"Access your new employee bonus plan here at HR's portal: dropbox.hr/phishinglink" etc...

I don't know why big companies, especially, allow other domains to be used for official business.

View on HN

Microsoft is the worst about this. So many official domains containing at least one of "windows", "microsoft", "azure".

I also regularly get XSS warning from the myriad login domains that they pass credentials through in their web portals.

Sometimes I wonder how their services are set up to talk to each other, I'm sure it's a terrifying Gordian knot.

The domains mess at Microsoft is truly hilarious. MS Edge browser fetches some updates from something.skype.com IIRC.

And the crazy part are all the redirects that happen, and with delays (often evident) you can watch them happen in real time. Why is this a problem? Because it completely confuses password managers and whitelisting in uBlock Origin, et al.

A complete shitshow.

And then, after 30 seconds of watching the redirects, you finally reach a page that says... "your tenant ${uuid} cannot access resource ${uuid} on realm ${uuid}, sorry".

Microsoft and naming issues. That's one iconic duo.

Sometimes their services don't talk to each other, but you can step in and fill the gap!

https://www.ghacks.net/2019/04/17/microsoft-lost-control-ove...

US banks are training their customers to get phished.

Many large US banks bounce the customer through several totally different and unrecognizable top level domains as part of routine web access.

Yes this drives me nuts! I was waved off when I tried to report it to the bank's security team.

You really don't want to give some random SaaS tool full permission on your production web origin.

If I'm Example Ltd. and my customers are trusting me to keep their data on example.com safe, and I use example.blog for my blog hosted by Jimbo's Blogging Service, I don't need to worry about Jimbo or his employees or hackers targeting my blog getting access to example.com's cookies, local storage, etc.

Cf. It's really hard—in some cases impossible, without use of the Public Suffix List[0]—to completely wall off blog.example.com from example.com.

[0] https://publicsuffix.org/

Why not just use a subdomain? This is, arguably, what subdomains are for.

Subdomains usually get all the cookies from the main domain (or at least they used to, didn't follow up on that issue for some years).

It's the opposite. Set-Cookie takes the optional Domain attribute and "If omitted, this attribute defaults to the host of the current document URL, not including subdomains." However, perhaps you're remembering "Multiple host/domain values are not allowed, but if a domain is specified, then subdomains are always included." [0]

[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...

Can you give an example of what it means for a subdomain to not be walled off?

One thing you'd really want to do in particular is stop blog.example.com from either setting or reading any cookies from example.com

Isn't that why we have subdomains?

Yes, that's a big problem at my employer. So many functions have been contracted out that I have to deal with official functions via sites belonging to at least 15 outside companies, many for sensitive HR-related functions, expense reports, and purchasing. It's hard to keep track of all that, and makes it more likely that some employee will make a mistake.

But it's just as easy to point a DNS record from hr.internal.dropbox.com or techblog.dropbox.com to trusted third party vendors as it is to set up a new domain, but the use of subdomains maintains the security model.

In the standard way of configuring cookies, allowing third parties to use a subdomain of your domain lets them collect your HTTP_ONLY SECURE cookies and impersonate your users.

The security policy at the FAANG I used to work at required third party vendor code to run on other domains for this reason.

A much better approach IMO is redirect links when browsing on company network. The company network is configured to make drl/... redirect to a url - I think google also does this with g/...

Dropbox already had this when I joined in 2015 drl/X "dropbox redirect link" would direct you to various internal sites and documentation.

Reply on news.ycombinator.com