5 ms·

How is this bad? If the domain is only used to host the decoder, what bad stuff can a bad guy do by executing JS? I get how this would be a vulnerability on Fac

How is this bad? If the domain is only used to host the decoder, what bad stuff can a bad guy do by executing JS? I get how this would be a vulnerability on Facebook, but why is it bad here?

novaleaf 7y ago
just off the top of my head, but a bad guy could distribute a "bugged" version of the url that installs cookies and phones home. very hard for a normal person to tell the good link from a bad link, and removes the way most people determine if a link should be trusted (by looking at the domain)
zawerf 7y ago
One example would be if they can trick the user into installing a service worker, then they can hijack all fetch calls for all other pages (I think).
- stackola 7y ago
  That's not true, service workers still obey the cross-origin policy. The only thing I can think of is, that a service worker has it's own CSP, as opposed to obeying the CSP of the registering script, but this service doesn't use CSP anyways.
  - zawerf 7y ago
    I meant all the pages published using this tool which are all at the same scope of: https://jstrieb.github.io/urlpages/#blahblah https://jstrieb.github.io/urlpages/#blahblah That said I couldn't get it to work. You would need to be able to register a service worker file at something like https://jstrieb.github.io/urlpages/sw.js https://jstrieb.github.io/urlpages/sw.js but all the pages you have control over have proper html mime type and are rejected when you try to register them (and have too much actual html junk in them to run as js files anyway).
    - stackola 7y ago
      You don't even need a service worker for that. Just fetch it. fetch("https://jstrieb.github.io/") So yea, other sites on his github pages are compromised, that's true.
      - zawerf 7y ago
        The (malicious) goal I had in mind with service workers is to rewrite all other published pages: self.addEventListener('fetch', event => { event.respondWith( new Response('<h1>I murder kittens for fun</h1>', { headers: { 'Content-Type': 'text/html; charset=utf-8' } }) ); })
geekamongus 7y ago
Have someone who controls the domain and is logged in to their website admin area in another tab click a link you've crafted to steal and send you their delicious cookies. Or, any time this sort of thing comes up in a thread on a news website like this one, an opportunistic attacker could post a malicious payload in a link and watch as all the excited people blindly click away.
- deleted 7y ago
  [deleted]
xg15 7y ago
It's very bad, because cookies, permissions and lots of other presisted data will be shared by all scripts on the domain. Example: Alice makes a benign page that uses location data and shares the link with her friends. The friends know what's up and grant location permissions to get the page to work. What they actually did, however was grant location permissions to "https://jstrieb.github.io/urlpages" https://jstrieb.github.io/urlpages" and any script served by that origin. So when some of the friends later open Eve's URL that contains a location harvester, they don't get any prompt at all: Eve's link can just reuse the location permission given to Alice because, as far as the browser is concerned, both scripts belong to the same page.

How is this bad? If the domain is only used to host the decoder, what bad stuff can a bad guy do by executing JS? I get how this would be a vulnerability on Facebook, but why is it bad here?

novaleaf 7y ago

just off the top of my head, but a bad guy could distribute a "bugged" version of the url that installs cookies and phones home. very hard for a normal person to tell the good link from a bad link, and removes the way most people determine if a link should be trusted (by looking at the domain)

zawerf 7y ago

One example would be if they can trick the user into installing a service worker, then they can hijack all fetch calls for all other pages (I think).

stackola 7y ago
That's not true, service workers still obey the cross-origin policy. The only thing I can think of is, that a service worker has it's own CSP, as opposed to obeying the CSP of the registering script, but this service doesn't use CSP anyways.
- zawerf 7y ago
  I meant all the pages published using this tool which are all at the same scope of: https://jstrieb.github.io/urlpages/#blahblah https://jstrieb.github.io/urlpages/#blahblah That said I couldn't get it to work. You would need to be able to register a service worker file at something like https://jstrieb.github.io/urlpages/sw.js https://jstrieb.github.io/urlpages/sw.js but all the pages you have control over have proper html mime type and are rejected when you try to register them (and have too much actual html junk in them to run as js files anyway).
  - stackola 7y ago
    You don't even need a service worker for that. Just fetch it. fetch("https://jstrieb.github.io/") So yea, other sites on his github pages are compromised, that's true.
    - zawerf 7y ago
      The (malicious) goal I had in mind with service workers is to rewrite all other published pages: self.addEventListener('fetch', event => { event.respondWith( new Response('<h1>I murder kittens for fun</h1>', { headers: { 'Content-Type': 'text/html; charset=utf-8' } }) ); })

geekamongus 7y ago

Have someone who controls the domain and is logged in to their website admin area in another tab click a link you've crafted to steal and send you their delicious cookies. Or, any time this sort of thing comes up in a thread on a news website like this one, an opportunistic attacker could post a malicious payload in a link and watch as all the excited people blindly click away.

deleted 7y ago
[deleted]

xg15 7y ago

It's very bad, because cookies, permissions and lots of other presisted data will be shared by all scripts on the domain. Example: Alice makes a benign page that uses location data and shares the link with her friends. The friends know what's up and grant location permissions to get the page to work. What they actually did, however was grant location permissions to "https://jstrieb.github.io/urlpages" https://jstrieb.github.io/urlpages" and any script served by that origin. So when some of the friends later open Eve's URL that contains a location harvester, they don't get any prompt at all: Eve's link can just reuse the location permission given to Alice because, as far as the browser is concerned, both scripts belong to the same page.