243

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?

  • 42
    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. – Unicorn Tears Aug 6 at 16:01
  • 25
    I'm surprised the W3 didn't revise the DOM spec to prohibit any script access to <input type="password"> - or least offer a flag attribute to block script access like they have for <iframe> etc. – The D Aug 7 at 5:54
  • 65
    BTW, most reputable websites don't have any ads on login pages. – Dmitry Grigoryev Aug 7 at 7:40
  • 18
    @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 :) – Luaan Aug 7 at 7:43
  • 14
    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. – DBS Aug 7 at 15:24
222

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.

  • 13
    Is there some way a layman like me could tell the difference between a sandbox'ed ad vs. a non-sandbox'ed ad? – scohe001 Aug 6 at 16:06
  • 2
    @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. :( – Benoit Esnard Aug 6 at 16:12
  • 19
    @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;} – AuxTaco Aug 7 at 1:18
  • 5
    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 Aug 7 at 6:43
  • 15
    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. – eckes Aug 7 at 11:40
30

That depends on how the website loads the ads.

In the case of goodreads, their HTML contains javascript from the ad provider. Specifically, lines 81-145 of the HTML document returned by https://www.goodreads.com/ read:

<script>
  //<![CDATA[
    var gptAdSlots = gptAdSlots || [];
    var googletag = googletag || {};
    googletag.cmd = googletag.cmd || [];
    (function() {
      var gads = document.createElement("script");
      gads.async = true;
      gads.type = "text/javascript";
      var useSSL = "https:" == document.location.protocol;
      gads.src = (useSSL ? "https:" : "http:") +
      "//securepubads.g.doubleclick.net/tag/js/gpt.js";
      var node = document.getElementsByTagName("script")[0];
      node.parentNode.insertBefore(gads, node);
    })();
    // page settings
  //]]>
</script>
<script>
  //<![CDATA[
    googletag.cmd.push(function() {
      googletag.pubads().setTargeting("sid", "osid.bd63050e605ccee9f21515a2dedfdaea");
    googletag.pubads().setTargeting("grsession", "osid.bd63050e605ccee9f21515a2dedfdaea");
    googletag.pubads().setTargeting("surface", "desktop");
    googletag.pubads().setTargeting("signedin", "false");
    googletag.pubads().setTargeting("gr_author", "false");
    googletag.pubads().setTargeting("author", []);
      googletag.pubads().enableAsyncRendering();
      googletag.pubads().enableSingleRequest();
      googletag.pubads().collapseEmptyDivs(true);
      googletag.pubads().disableInitialLoad();
      googletag.enableServices();
    });
  //]]>
</script>
<script>
  //<![CDATA[
    ! function(a9, a, p, s, t, A, g) {
      if (a[a9]) return;

      function q(c, r) {
        a[a9]._Q.push([c, r])
      }
      a[a9] = {
      init: function() {
        q("i", arguments)
      },
      fetchBids: function() {
        q("f", arguments)
      },
      setDisplayBids: function() {},
        _Q: []
      };
      A = p.createElement(s);
      A.async = !0;
      A.src = t;
      g = p.getElementsByTagName(s)[0];
      g.parentNode.insertBefore(A, g)
    }("apstag", window, document, "script", "//c.amazon-adsystem.com/aax2/apstag.js");

    apstag.init({
      pubID: '3211', adServer: 'googletag', bidTimeout: 4e3
    });
  //]]>
</script>

As a consequence, the advertizer's javascript code runs in the same execution context as the website itself, and can do everything the website can, including observing all your interactions with the website.

If they had instead loaded the ads by embedding an iframe from a different origin, the advertizer's code would have run in its own execution context, and the browser would have blocked access to the surrounding website as a violation of the same origin policy.

In general, the only way to tell whether the website has isolated the advertizer's code is to inspect the code of the website.

  • 17
    Most advertisers these days don't allow you to load them in iframes. But they "promise" to load the third-party advertisements that they provide in iframes of their own. – Barmar Aug 7 at 17:01

protected by Luc Aug 7 at 21:33

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.