5 ms·

The quote about DNS seems wrong to me ""Consider a situation where I can view DNS traffic (e.g. company network), and I send a link to the company health porta

The quote about DNS seems wrong to me ""Consider a situation where I can view DNS traffic (e.g. company network), and I send a link to the company health portal, with #:~:text=cancer," he wrote. "On certain page layouts, I might be able [to] tell if the employee has cancer by looking for lower-on-the-page resources being requested."" I thought DNS requests just get the domain, not the hash and not even the page requested. But lets play along. How would sending a link tell you anything apart from if a user clicked said link? How would links to existing anchors example.com#h3-subtitle be any different?

liveoneggs 7y ago
also #fragments aren't sent to the server at all, unless this changes that (a major major change if so)
- tln 7y ago
  Right on. This article is bull
- deleted 7y ago
  [deleted]
- amsully 7y ago
  The google document being used talks about crossing an origin-boundary. So website with bad script injected is loaded by the user and is able to make requests to a logged-in banking website with time-based/scrolling attacks.
- falcolas 7y ago
  Does this matter when the server (well, multiple servers when you throw in ads as well) are running their custom Javascript on the client, which has access to not only the viewport coordinates, but the URL itself?
  - liveoneggs 7y ago
    does this add an additional vector to that case?
GranPC 7y ago
The idea of that quote is that using the anchor would only scroll to that part of the page if the word "cancer" is present, and if the page uses lazy-loading then it would fire off more requests than it would if the word wasn't present. It's a bit of a stretch though.
- deleted 7y ago
  [deleted]
netsharc 7y ago
Kind of an edge case privacy issue, IMO. Imagine if the page has 10 parts. Part 1 has an image reference hosted on part1.imagehost.xyz, but loaded lazily. Each part has something analogous, an image hosted on a different domain, but loaded lazily (so, no requests before that part of the page is visible). If you open the page and read from the top, the browser will open with part 1, Javascript will fire and tell the browser to load part1.imagehost.xyz/image1.jpg, causing a DNS lookup, HTTP(S) connection, and a request. And so on for each part (interestingly this way you can do a timing to see how fast the user is scrolling past each part). But if the browser directly loads part 8 (the part with cancer in the example), and the Javascript only asks to load part8.imagehost.xyz/image8.jpg, the fact that the browser only asks the DNS for this hostname will reveal to the DNS admin that the reader followed a link straight there. But if it's some health portal under the evil company's control, it seems like it'd be easier to write Javascript to fire an event to do server-side logging/send an email alert to HR if someone spends a lot of time reading the cancer section...
- ghostpepper 7y ago
  I read it as the opposite, where the evil party doesn't control the browser but they can sniff traffic on the network and now they can see which part of a page you requested instead of merely which page. I am not a web dev so I'd love to hear someone with more knowledge spell out some other privacy concerns.
  - squeaky-clean 7y ago
    That's also how I understand it. It requires a very specific and uncommon set of circumstances, but it could leak info to someone observing. But also I think the main issue "pes10k" has is that it is adding a new attack vector in a backwards-incompatible way. So a sensitive website which is doing these JS lazy-loading things was "safe" last week, but now can potentially leak information in a way it couldn't have with earlier chrome versions. In practice though it's hard (for me) to think of a website working this way. I understand the idea of a network admin sending the CEO a link with the text-fragment "cancer" in it. And if that fires off related requests unusually, I can assume it auto-scrolled to "cancer", and the CEO has cancer and sell all my shares. But what sort of website will dynamically contain the word "cancer" for patients that have cancer and is also doing fancy lazy-loading stuff? I'm not a security expert though and I know people can are much cleverer than me when it comes to exploits.
tedunangst 7y ago
It seems more plausible that I could send you a link to portal.site.example/you-have-cancer-what-now and if you don't have cancer it redirects to portal.site.example/home, if we're willing to consider the infiniverse of possible health care portal designs.
deathanatos 7y ago
A sibling/top-level comment has a link to the security doc: https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj2gkwCq8_5xwIae7PVik/edit#heading=h.uoiwg23pt0tx https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj... I think what that is saying is that, say evil.com starts embedding some sensitive site. It can't normally see the contents of that site, b/c it would be cross origin. (Or any other context where I can load a resource, but not see the content.) If I want to know whether some content is or is not in that sensitive site, I use the scroll-to-fragment to scroll to that text: either it will find the text, and scroll to it, or it won't; evil.com won't know the result of that directly, but it might be able to measure timing/CPU work done, and from that, infer the result: whether that text was or was not in the page. From there, repeat the attack to start brute forcing the content of the page. W.r.t. DNS, if the scrolling or lack of scrolling initiate two separate sets of DNS requests that I can observe, then that's one possible way to leak the information on the page. At least, that's how I'm reading that security doc; this is fairly different from how other responses to your remark are interpreting it, but I wonder if they were only looking at TFA, which really was not very clearly explaining anything. The security doc also mentions "Restrict feature to user-gesture initiated navigations", which would completely stop the iframe attack I've outlined above.
squeaky-clean 7y ago
The github issue has more actual examples. The important bit is the "looking for lower-on-the-page resources being requested." bit. You can't necessarily tell anything from that lone DNS request. But after loading the page, the user's browser will go on to send requests for elements on the page, and anything JS wants to grab based on position, which can be a channel for information. Example: 99% of your employees' DNS requests to the company health portal are followed by DNS requests to the image CDN a few milliseconds later. However 1 specific request to FakeCompanyHealth.com is immediately followed by a DNS request to MayoClinic.com, because it turns out the web page dynamically loads an iframe to contact the Mayo Clinic once you scroll to the Cancer subsection. You could then assume based on timing that this user clicked a cancer-specific anchor link. A more realistic example IMO is the twitter friend leak one provided in the Github thread. Send an anchor like "twitter.com#:~:text=@handle" and see if their page-load matches the standard twitter homepage load, or did their browser scroll them halfway down the page and load additional stuff? If so, you can assume these 2 users are friends., https://github.com/WICG/ScrollToTextFragment/issues/76 https://github.com/WICG/ScrollToTextFragment/issues/76
- ghostpepper 7y ago
  Does this require you to intercept their traffic on the network? If not, how do you know what their page load looks like?
- tootie 7y ago
  You don't send URLs or query parameters to a DNS server. Only a hostname. Also, it's usually cached after the first lookup. Sniffing the network will only requests to that IP. Hostnames, URLs, params and responses are all fully encrypted if they're on https.
  - bradyd 7y ago
    Hostnames are not encrypted in HTTPS requests. They are sent in plain text via SNI (Server Name Indication). There is a new way of handling this called ESNI that does encrypt it, but I'm not sure how widely that is supported. Edit: Cloudflare has a page to check if ESNI is supported by your browser. I tested it in the latest version of Firefox, Chrome, and Safari and it failed the test in all three. https://www.cloudflare.com/ssl/encrypted-sni/ https://www.cloudflare.com/ssl/encrypted-sni/
x0x0 7y ago
It just seems to me like not that big a concern. eg on a company network, it would be common to install an SSL cert on all devices on the private network for things like web proxies, CASBs, or other security policy enforcement measures.
alerighi 7y ago
And aren't most browsers (and for sure Chrome) loading the entire page anyway? I mean maybe if you have a slow connection, but for most people with a fast connection it should load everything to avoid that when scrolling down you have something missing. I really don't see the issue, to me is a useless argument.
- SahAssar 7y ago
  A lot of sites do lazy-loading (but even then it's good practice to preconnect to third-party domains) and chrome even implemented native lazy-loading for images and iframes recently.

liveoneggs 7y ago

also #fragments aren't sent to the server at all, unless this changes that (a major major change if so)

tln 7y ago
Right on. This article is bull
deleted 7y ago
[deleted]
amsully 7y ago
The google document being used talks about crossing an origin-boundary. So website with bad script injected is loaded by the user and is able to make requests to a logged-in banking website with time-based/scrolling attacks.
falcolas 7y ago
Does this matter when the server (well, multiple servers when you throw in ads as well) are running their custom Javascript on the client, which has access to not only the viewport coordinates, but the URL itself?
- liveoneggs 7y ago
  does this add an additional vector to that case?

GranPC 7y ago

The idea of that quote is that using the anchor would only scroll to that part of the page if the word "cancer" is present, and if the page uses lazy-loading then it would fire off more requests than it would if the word wasn't present. It's a bit of a stretch though.

deleted 7y ago
[deleted]

netsharc 7y ago

Kind of an edge case privacy issue, IMO. Imagine if the page has 10 parts. Part 1 has an image reference hosted on part1.imagehost.xyz, but loaded lazily. Each part has something analogous, an image hosted on a different domain, but loaded lazily (so, no requests before that part of the page is visible). If you open the page and read from the top, the browser will open with part 1, Javascript will fire and tell the browser to load part1.imagehost.xyz/image1.jpg, causing a DNS lookup, HTTP(S) connection, and a request. And so on for each part (interestingly this way you can do a timing to see how fast the user is scrolling past each part). But if the browser directly loads part 8 (the part with cancer in the example), and the Javascript only asks to load part8.imagehost.xyz/image8.jpg, the fact that the browser only asks the DNS for this hostname will reveal to the DNS admin that the reader followed a link straight there. But if it's some health portal under the evil company's control, it seems like it'd be easier to write Javascript to fire an event to do server-side logging/send an email alert to HR if someone spends a lot of time reading the cancer section...

ghostpepper 7y ago
I read it as the opposite, where the evil party doesn't control the browser but they can sniff traffic on the network and now they can see which part of a page you requested instead of merely which page. I am not a web dev so I'd love to hear someone with more knowledge spell out some other privacy concerns.
- squeaky-clean 7y ago
  That's also how I understand it. It requires a very specific and uncommon set of circumstances, but it could leak info to someone observing. But also I think the main issue "pes10k" has is that it is adding a new attack vector in a backwards-incompatible way. So a sensitive website which is doing these JS lazy-loading things was "safe" last week, but now can potentially leak information in a way it couldn't have with earlier chrome versions. In practice though it's hard (for me) to think of a website working this way. I understand the idea of a network admin sending the CEO a link with the text-fragment "cancer" in it. And if that fires off related requests unusually, I can assume it auto-scrolled to "cancer", and the CEO has cancer and sell all my shares. But what sort of website will dynamically contain the word "cancer" for patients that have cancer and is also doing fancy lazy-loading stuff? I'm not a security expert though and I know people can are much cleverer than me when it comes to exploits.

tedunangst 7y ago

It seems more plausible that I could send you a link to portal.site.example/you-have-cancer-what-now and if you don't have cancer it redirects to portal.site.example/home, if we're willing to consider the infiniverse of possible health care portal designs.

deathanatos 7y ago

A sibling/top-level comment has a link to the security doc: https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj2gkwCq8_5xwIae7PVik/edit#heading=h.uoiwg23pt0tx https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj... I think what that is saying is that, say evil.com starts embedding some sensitive site. It can't normally see the contents of that site, b/c it would be cross origin. (Or any other context where I can load a resource, but not see the content.) If I want to know whether some content is or is not in that sensitive site, I use the scroll-to-fragment to scroll to that text: either it will find the text, and scroll to it, or it won't; evil.com won't know the result of that directly, but it might be able to measure timing/CPU work done, and from that, infer the result: whether that text was or was not in the page. From there, repeat the attack to start brute forcing the content of the page. W.r.t. DNS, if the scrolling or lack of scrolling initiate two separate sets of DNS requests that I can observe, then that's one possible way to leak the information on the page. At least, that's how I'm reading that security doc; this is fairly different from how other responses to your remark are interpreting it, but I wonder if they were only looking at TFA, which really was not very clearly explaining anything. The security doc also mentions "Restrict feature to user-gesture initiated navigations", which would completely stop the iframe attack I've outlined above.

squeaky-clean 7y ago

The github issue has more actual examples. The important bit is the "looking for lower-on-the-page resources being requested." bit. You can't necessarily tell anything from that lone DNS request. But after loading the page, the user's browser will go on to send requests for elements on the page, and anything JS wants to grab based on position, which can be a channel for information. Example: 99% of your employees' DNS requests to the company health portal are followed by DNS requests to the image CDN a few milliseconds later. However 1 specific request to FakeCompanyHealth.com is immediately followed by a DNS request to MayoClinic.com, because it turns out the web page dynamically loads an iframe to contact the Mayo Clinic once you scroll to the Cancer subsection. You could then assume based on timing that this user clicked a cancer-specific anchor link. A more realistic example IMO is the twitter friend leak one provided in the Github thread. Send an anchor like "twitter.com#:~:text=@handle" and see if their page-load matches the standard twitter homepage load, or did their browser scroll them halfway down the page and load additional stuff? If so, you can assume these 2 users are friends., https://github.com/WICG/ScrollToTextFragment/issues/76 https://github.com/WICG/ScrollToTextFragment/issues/76

ghostpepper 7y ago
Does this require you to intercept their traffic on the network? If not, how do you know what their page load looks like?
tootie 7y ago
You don't send URLs or query parameters to a DNS server. Only a hostname. Also, it's usually cached after the first lookup. Sniffing the network will only requests to that IP. Hostnames, URLs, params and responses are all fully encrypted if they're on https.
- bradyd 7y ago
  Hostnames are not encrypted in HTTPS requests. They are sent in plain text via SNI (Server Name Indication). There is a new way of handling this called ESNI that does encrypt it, but I'm not sure how widely that is supported. Edit: Cloudflare has a page to check if ESNI is supported by your browser. I tested it in the latest version of Firefox, Chrome, and Safari and it failed the test in all three. https://www.cloudflare.com/ssl/encrypted-sni/ https://www.cloudflare.com/ssl/encrypted-sni/

x0x0 7y ago

It just seems to me like not that big a concern. eg on a company network, it would be common to install an SSL cert on all devices on the private network for things like web proxies, CASBs, or other security policy enforcement measures.

alerighi 7y ago

And aren't most browsers (and for sure Chrome) loading the entire page anyway? I mean maybe if you have a slow connection, but for most people with a fast connection it should load everything to avoid that when scrolling down you have something missing. I really don't see the issue, to me is a useless argument.

SahAssar 7y ago
A lot of sites do lazy-loading (but even then it's good practice to preconnect to third-party domains) and chrome even implemented native lazy-loading for images and iframes recently.