I agree, this scourge of http rpc endpoints are vendors trying to sidestep the NPAPI deprecation.... it was deprecated for a reason!
https://twitter.com/drewml/status/1148704362811801602 …
-
-
Has anyone produced a best-practices guide for this cursed use case? I'd think you'd also want to ensure a whitelisted value for the "Host" header as well for rebinding attacks, etc.
-
I did, e.g. in https://palant.de/2019/04/11/bogus-security-mechanisms-encrypting-localhost-traffic/ …. Just don't use web servers for communication between browser extensions and applications - use native messaging API which has built-in security mechanisms.
End of conversation
New conversation -
-
-
i am just posting this so i can act cool when i disclose
End of conversation
New conversation -
-
I really really wish the browsers would, upon discovering a resource access of any sort is destined to an on-host IP target, require that the page origin _also be_ an on-host IP. The browser shouldn't be modifying [ or communicating with] desktop software.
-
There have been quite a few application which relied on websites accessing localhost servers, Google Desktop Search comes to mind in particular (thanks to various vulnerabilities). This should be fine as long as the local server does Origin checks. But too often they don't...
End of conversation
New conversation -
-
-
I've seen several variations of this myself. Origin whitelisting is hard to get right cross-browser, which is why vendors prefer other solutions. One used a shared secret that they would get via native messaging. And of course they leaked the secret to websites.
-
Of course they could have avoided the whole issue by just using native messaging for everything. But - hey, IE compatibility is sooooo important...
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.