Can ads on a page read my password?What is wrong with a confirmation page displaying my password?“Forgot my password page” best practiceCan a webpage read another page's cookies?What is wrong with a confirmation page displaying my password?Secure forgot password page: Is a server-stateless implementation viable?How to read password from Windows credentials?Can you exploit an XSS vulnerability on one page to run code on another page?Read all git cached passwordUsers can change their password with the same passwordIs problem with string length in token (read password) randomization a security flaw? Is there any impact for the same?

When does The Truman Show take place?

Installing the original OS X version onto a Mac?

Why is su world executable?

What is "super" in superphosphate?

Check disk usage of files returned with spaces

iPad or iPhone doesn't charge until unlocked?

Can sulfuric acid itself be electrolysed?

Gofer work in exchange for Letter of Recommendation

Is recepted a word?

What is the evidence on the danger of feeding whole blueberries and grapes to infants and toddlers?

Are unaudited server logs admissible in a court of law?

Radix2 Fast Fourier Transform implemented in C++

Polar contour plot in Mathematica?

Expand def in write18

Why don't politicians push for fossil fuel reduction by pointing out their scarcity?

Where is this New York City Broadway location from Fall 1958?

How do we test and determine if a USB cable+connector is version 2, 3.0 or 3.1?

Tabularx with hline and overrightarrow vertical spacing

Repurpose telephone line to ethernet

My father gets angry every time I pass Salam. Does that mean I should stop saying Salam when he's around?

How best to join tables, which have different lengths on the same column values which exist in both tables?

How do you call it when two celestial bodies come as close to each other as they will in their current orbits?

From France west coast to Portugal via ship?

Did Wernher von Braun really have a "Saturn V painted as the V2"?



Can ads on a page read my password?


What is wrong with a confirmation page displaying my password?“Forgot my password page” best practiceCan a webpage read another page's cookies?What is wrong with a confirmation page displaying my password?Secure forgot password page: Is a server-stateless implementation viable?How to read password from Windows credentials?Can you exploit an XSS vulnerability on one page to run code on another page?Read all git cached passwordUsers can change their password with the same passwordIs problem with string length in token (read password) randomization a security flaw? Is there any impact for the same?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








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?










share|improve this question





















  • 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


















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?










share|improve this question





















  • 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














243












243








243


59






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?










share|improve this question
















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?







passwords web-application






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 12 at 14:47







scohe001

















asked Aug 6 at 15:54









scohe001scohe001

7942 gold badges4 silver badges11 bronze badges




7942 gold badges4 silver badges11 bronze badges










  • 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













  • 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








42




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





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




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





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




65





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

– Dmitry Grigoryev
Aug 7 at 7:40





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

– Dmitry Grigoryev
Aug 7 at 7:40




18




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





@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




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






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











2 Answers
2






active

oldest

votes


















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.






share|improve this answer






















  • 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.






share|improve this answer






















  • 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?














2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









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.






share|improve this answer






















  • 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
















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.






share|improve this answer






















  • 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














222












222








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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








edited Aug 7 at 7:38









Dmitry Grigoryev

8,37122 silver badges48 bronze badges




8,37122 silver badges48 bronze badges










answered Aug 6 at 16:05









Benoit EsnardBenoit Esnard

11.2k7 gold badges56 silver badges58 bronze badges




11.2k7 gold badges56 silver badges58 bronze badges










  • 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













  • 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








13




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





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




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





@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




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





@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




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






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




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






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.






share|improve this answer






















  • 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















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.






share|improve this answer






















  • 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













30












30








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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








edited Aug 8 at 18:44









Ashley Coolman

1033 bronze badges




1033 bronze badges










answered Aug 7 at 16:17









meritonmeriton

1,2691 gold badge8 silver badges10 bronze badges




1,2691 gold badge8 silver badges10 bronze badges










  • 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












  • 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







17




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





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?



Popular posts from this blog

Get product attribute by attribute group code in magento 2get product attribute by product attribute group in magento 2Magento 2 Log Bundle Product Data in List Page?How to get all product attribute of a attribute group of Default attribute set?Magento 2.1 Create a filter in the product grid by new attributeMagento 2 : Get Product Attribute values By GroupMagento 2 How to get all existing values for one attributeMagento 2 get custom attribute of a single product inside a pluginMagento 2.3 How to get all the Multi Source Inventory (MSI) locations collection in custom module?Magento2: how to develop rest API to get new productsGet product attribute by attribute group code ( [attribute_group_code] ) in magento 2

Category:9 (number) SubcategoriesMedia in category "9 (number)"Navigation menuUpload mediaGND ID: 4485639-8Library of Congress authority ID: sh85091979ReasonatorScholiaStatistics

Magento 2.3: How do i solve this, Not registered handle, on custom form?How can i rewrite TierPrice Block in Magento2magento 2 captcha not rendering if I override layout xmlmain.CRITICAL: Plugin class doesn't existMagento 2 : Problem while adding custom button order view page?Magento 2.2.5: Overriding Admin Controller sales/orderMagento 2.2.5: Add, Update and Delete existing products Custom OptionsMagento 2.3 : File Upload issue in UI Component FormMagento2 Not registered handleHow to configured Form Builder Js in my custom magento 2.3.0 module?Magento 2.3. How to create image upload field in an admin form