12 ms·

The gigantic image: https://i.imgur.com/kN2rMhK.jpg https://i.imgur.com/kN2rMhK.jpg (source: http://comcastsupport.i.lithium.com/t5/image/serverpage/image-id/34

The gigantic image: https://i.imgur.com/kN2rMhK.jpg https://i.imgur.com/kN2rMhK.jpg (source: http://comcastsupport.i.lithium.com/t5/image/serverpage/image-id/34982i05D20DB4C25229CF/image-dimensions/200000?v=1.0&px=-1h http://comcastsupport.i.lithium.com/t5/image/serverpage/imag... - URL manually edited to display largest possible size) I paged through the JS curiously, and found the URL bnpsa.g.comcast.net/images/mydevicealert/browser/. I wondered what would happen if I hit that from my ISP in Australia. I was surprised: I got an NXDOMAIN back. But I discovered that googling the above URL as a quoted string finds a bunch of copies of the JS scattered around the Internet. Might be useful. So then I tried hitting bnp-service-alerts.gslb2.comcast.com/images/. This actually resolved, and Chrome hung at "Connecting...". After rechecking the URLs I noticed this one was referenced in the JS as HTTPS, so I added that, and promptly got 403 Forbidden. Question to anyone on Comcast [edit: which has been answered]: does http://bnpsa.g.comcast.net/images/mydevicealert/browser/ http://bnpsa.g.comcast.net/images/mydevicealert/browser/ resolve for you?

mehrdadn 9y ago
> Question to anyone on Comcast: does http://bnpsa.g.comcast.net/images/mydevicealert/browser/ http://bnpsa.g.comcast.net/images/mydevicealert/browser/ resolve for you? Nope, it does not for me. Non-existent domain.
- exikyut 9y ago
  Thanks!
- pdpi 9y ago
  That's the sort of domain I could very well see only resolving from comcast DNS, and them not propagating it anywhere else.
  - deleted 9y ago
    [deleted]
deusum 9y ago
Server not found.
- exikyut 9y ago
  Ah, okay then.
snowpanda 9y ago
Here it is in code: https://gist.github.com/thoroc/f4d043ead762392561256e20dea813b1 https://gist.github.com/thoroc/f4d043ead762392561256e20dea81...
- RKearney 9y ago
  Doesn’t look like much has changed over the last 5 years. https://gist.github.com/ryankearney/4146814/42d9ca5ec42fe43c5f7af69a60ae4c60c9bb567f https://gist.github.com/ryankearney/4146814/42d9ca5ec42fe43c...
octalmage 9y ago
When you run code on a website you don’t own you have to be extremely careful. You’ll learn this quick building WordPress themes and plugins. They’re pretty careful not to directly affect the website by running their JavaScript in a scoped context and using IDs in the CSS selectors, but there is nothing to prevent the website front modifying their pop up. For example if my website had the .closebn class with display: none !important, a visitor would not be able to close the pop up. That’s a pretty common class name. To prevent this you should use dynamically generated class names that get swapped out at build time, or in this case even inline styles. Something like the close button of an injected pop up is pretty critical and inline styles would guarantee that it wouldn’t be messed with. (I haven’t tested any of this, this is based on a quick glance at the code)
- exikyut 9y ago
  This is indeed true, and IIUC using Shadow DOM would be a workable mitigation. Btw, ignore caniuse etc - Firefox _technically_ does support Shadow DOM, just version 0, which it has apparently supported for a little while now. It's better than nothing in a pinch. Chrome et al are at Shadow DOM v1, which is what caniuse tests its support/no-support metrics against.

mehrdadn 9y ago

> Question to anyone on Comcast: does http://bnpsa.g.comcast.net/images/mydevicealert/browser/ http://bnpsa.g.comcast.net/images/mydevicealert/browser/ resolve for you? Nope, it does not for me. Non-existent domain.

exikyut 9y ago
Thanks!
pdpi 9y ago
That's the sort of domain I could very well see only resolving from comcast DNS, and them not propagating it anywhere else.
- deleted 9y ago
  [deleted]

deusum 9y ago

Server not found.

exikyut 9y ago
Ah, okay then.

snowpanda 9y ago

Here it is in code: https://gist.github.com/thoroc/f4d043ead762392561256e20dea813b1 https://gist.github.com/thoroc/f4d043ead762392561256e20dea81...

RKearney 9y ago
Doesn’t look like much has changed over the last 5 years. https://gist.github.com/ryankearney/4146814/42d9ca5ec42fe43c5f7af69a60ae4c60c9bb567f https://gist.github.com/ryankearney/4146814/42d9ca5ec42fe43c...

octalmage 9y ago

When you run code on a website you don’t own you have to be extremely careful. You’ll learn this quick building WordPress themes and plugins. They’re pretty careful not to directly affect the website by running their JavaScript in a scoped context and using IDs in the CSS selectors, but there is nothing to prevent the website front modifying their pop up. For example if my website had the .closebn class with display: none !important, a visitor would not be able to close the pop up. That’s a pretty common class name. To prevent this you should use dynamically generated class names that get swapped out at build time, or in this case even inline styles. Something like the close button of an injected pop up is pretty critical and inline styles would guarantee that it wouldn’t be messed with. (I haven’t tested any of this, this is based on a quick glance at the code)

exikyut 9y ago
This is indeed true, and IIUC using Shadow DOM would be a workable mitigation. Btw, ignore caniuse etc - Firefox _technically_ does support Shadow DOM, just version 0, which it has apparently supported for a little while now. It's better than nothing in a pinch. Chrome et al are at Shadow DOM v1, which is what caniuse tests its support/no-support metrics against.