Can ads on a page read my password?

  • Disclaimer: I have minimal web-dev/security knowledge so please answer as if talking to a "layman."

    I've heard that web-advertisements need to be able to run their own JavaScript so that they can verify they're being viewed by "real users." As this incident on StackOverflow shows, they're basically given free reign.

    I also know that JavaScript can be used to capture keystrokes on a webpage.

    So in a case like goodreads, where they have ads on the page and user/pass textboxes on the header, is there something in place to prevent the ad from reading keystrokes to record my credentials? Is reading keystrokes simply not possible from an ad?

    If I see ads on a login page should I assume that the page is not safe to enter my credentials?

    It's worse than that. Web performance tools and similar not only read your credentials but they read the credentials you type and then delete. Very nasty. You might be able to get away with not typing, always pasting your credentials. But the javascript has access to your DOM so it can just read every element. The only way to stop that is not to use credentials but to use oAuth and hand you life over to Google. What could go wrong.

    I'm surprised the W3 didn't revise the DOM spec to prohibit *any* script access to `` - or least offer a flag attribute to block script access like they have for `` etc.

    BTW, most reputable websites don't have any ads on login pages.

    @TheD That would mean you couldn't use client-side validation (e.g. "the two passwords you entered aren't the same) and you could only ever use a form POST to handle credentials. Both would mean that all the major browsers would simply ignore the spec anyway :)

    @TheD Many sites now have a password strength indicator as you type the password. That wouldn't work. (OTOH if the script server gets hacked, it could still remove the whole form and put another one that sends data elsewhere!)

    You could turn off Javascript. some browser extensions make this possible on a per page basis.

    @DmitryGrigoryev Unfortunately, many reputable websites these days have a login option either in the header bar or as a popup rather than as its own dedicated page.

    For non-technical users who are worried about malicious ads, there are plenty of ad blocking extensions to all major browsers, as well as Privacy Badger, which will actively learn and block 3rd party tracking and advertising scripts as you browse. While not entirely bulletproof, this will prevent the vast majority of adverts and generally improve your web browsing experience.

    re goodreads: most sites have dedicated login page without ads, that is safer to use. If there's no direct link anywhere, usually entering fake credentials lands you on dedicated login page, along with "invalid username/password" message.

    @el.pescado that sounds like the start of a good answer for what us Users can do to protect ourselves. "Yes, ads can read your password, so beware of headers and make sure you find the dedicated login page"

    @DmitryGrigoryev: Even reputable websites have trackers running on their login page. I don't see what's the point of focusing on ads if silent trackers are far worse.

    Note that StackExchange uses some well-known trackers including Google Analytics, QuantServe and ScoreCardResearch, even on the login page. In general, trackers are far more shady than advertisements, and use far more insidious scripts, because their intended purpose is to track you rather than to sell something to you.

    Another good option is the Brave browser. It blocks ads and trackers by default, and gives you quite a bit of data about how many and which ones, if you're interested. It's built on Chrome so it renders sites exactly as you're used to seeing them, has the same devtools, etc.

  • Nothing prevents ads from reading your passwords.

    Ads (or any other script like analytics or JavaScript libraries) have access to the main JavaScript scope, and are able to read a lot of sensitive stuff: financial information, passwords, CSRF tokens, etc.

    Well, unless they're being loaded in a sandboxed iframe.

    Loading an ad in a sandboxed iframe will add security restrictions to the JavaScript scope it has access to, so it won't be able to do nasty stuff.

    Unfortunately, most of the third-party scripts are not sandboxed. This is because some of them require access to the main scope to work properly, so they're almost never sandboxed.

    As a developer, what can I do?

    Since any third-party script could compromise the security of all you personal data, all sensitive pages (like login forms or checkout pages) should be loaded on their own origin (a subdomain is fine).

    Using another origin allows us to profit from the Same-Origin Policy: scripts running on the main origin can't access anything on the protected origin.

    Note: Content Security Policy and Subresource Integrity could also be used if the third-party can be easily reviewed, but most ad networks couldn't work anymore if you used them.

    Is there some way a layman like me could tell the difference between a sandbox'ed ad vs. a non-sandbox'ed ad?

    @scohe001: Do you know how to use the "Inspect element" tool in your browser? A sandboxed iframe has a "sandbox" attribute. I don't know any easy way to check this without any HTML knowledge unfortunately. :(

    @scohe001 This Stylus usersheet will put a super-annoying border around unsandboxed iframes and sandboxed iframes that can run scripts: `iframe:not([sandbox]),iframe[sandbox~=allow-scripts]{border:10px solid red !important;border-image:repeating-linear-gradient(45deg,red,red 5%,#ff0 5%,#ff0 10%)10 !important;}`

    Same-origin policy protects the external resource from being read by your scripts. If the malicious script is running on your page, it won't care you did load it from an other origin, it will just run and be able to **send** data anywhere it likes.

    @Kaiido: the point is that if you're using ads on the main origin, it won't be able to load anything on the protected origin thanks to the same-origin policy. I'll edit my answer to reflect that idea in a better way.

    Well in that case, that's just an other form of a sandboxed iframe.

    It is best practice to not have ads on login screens. If a site does not follow that, you can at least complain to them.

    @AuxTaco That will show you unsafe iframes, but not scripts running in the context of the parent page itself. Unfortunately, I suspect those are just as common as iframes.

    Wouldn't a sanboxed frame prevent the ad provider from reading the contents of the page to figure out which ad to deliver? (e.g., the ad might want to show motor oil ads on a car blog or something).

    it is also best practice to not load arbitrary code from arbitrary third parties and run it on your customers' computers, yet here we are

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM