Re: Is third party javascript on a login page considered dangerous?

[Brandon Perry <bperry.volatile () gmail com>]

It depends.

You can prevent some classes of JS running such as inline JS so only trusted JS is executed. If you design your site to 
expect to pull from a specific CDN all the time, disabling inline JS (third party or otherwise) would prevent any 
attacker-controlled JS (say from XSS) from executing on the login page while letting you use any “safe” or trusted js.

If you perform SHA sum checking on resources with resource integrity from third party sites, you can be sure you won’t 
load a backdoor or otherwise-modified version after deployment.

If you are loading third party JS from a trusted source, but not performing resource integrity checks over plaintext 
HTTP, you obviously still can’t trust the final JS delivered.

Using third-party JS on a login page isn’t inherently dangerous. Having no control or ability to know when that JS 
changes is the dangerous part.

> On Oct 31, 2022, at 4:16 AM, Georgi Guninski <gguninski () gmail com> wrote:
>
> In short, is third party javascript on a login page considered dangerous?
>
> The JS has full access to the DOM of the page and can steal
> the username and password, which might be reused on other services,
> making it yet another cross site cookie, lol.
>
> In general, the JS persists after login, potentially giving
> access to sensitive information.
>
> I believe static analysis can't catch all JS, since one script
> may load another script.
>
> Also, the JS might be dynamic, depending on the user.
>
> Experience suggests the main 3rd party JS comes from google
> and google do [k]no[w] evil [1]
>
> Examples:
> bugzilla.mozilla.org loads from googleanalytics
> *.stackexchange.com loads from google and cloudfare.
>
> [1] https://en.wikipedia.org/w/index.php?title=Don%27t_be_evil&oldid=1109436328

Attachment: signature.asc
Description: Message signed with OpenPGP