danielstjules / blankshield Goto Github PK

What is the best place to invoke e.g. blankshield($('a[target=_blank]')); ?
To have all html parsed / DOM created by then I guess it should be done in document.onready.
But I wonder if its possible a user would click the unsafe link before its fixed (before the whole document is loaded and js run)?

Also at the moment the library doesn't support custom "target" attributes, e.g.target="MyNewWindow" - it'll open a new tab that will be vulnerable to the attack - I'm going to work on a patch for this issue.

Use selenium + sauce labs

The latest version on npm is 0.5.2. Can 0.6.0 please be added?

Hi,

I have event.preventDefault on links that open a new tab so the user has to fill in a form before they can see the content. It works fine in Chrome but in Firefox and Edge it still opens the new tab when they click the download links.

It works fine on my local version that has iTheme security disabled, but when I move it to my server an extra event handler is added which seems to be causing the problem.

https://seerene.harte.online/download-center - click the download links.

$('body').on('click', '.file-download', function (event) {
      if ($('.download-overlay').length !== 1) {
        return;
      }
      // Stop default action and bubbling
      event.preventDefault();
      event.stopPropagation();

      $('.download-overlay').find('.download-title').text($(this).attr('title'));
      $('.download-overlay').attr('data-file', $(this).attr('href'));

      $('.download-overlay').fadeIn(200);
      $('body').addClass('overlay-open');
    });

Hello, I am getting a null reference error when doing something like this:
urls.forEach(url => { blankshield.open(url, '_blank'); });
Looks like this is caused by the child.opener = null in iframeOpen function, preventing to execute this line for the second time and onwards.

When using blankshield to open a url in new Tab, the url is being blocked in chrome browser. It works fine in all other browser.

In Chrome 65 (at least for Mac), blankshield will open a new tab/window (for unsafe targets) to the URL, but the new tab/window will not have some cookies/session information sent to the URL for that domain (as it did previous). This is because Chrome has added support for the cookie same-site flag and enforces the value. When the URL is opened via a blank page (the generated iframe), it will not send the same-site strict cookies.
This only really is an issue when opening a URL to a blank page which has the same domain as the opener (and the same-site flag is set on some cookies).
I can see the different between using blankshield and not using it (via clicking a link) and using the patched window.open vs native), as well as when it is being used and I right-click to open in a new tab. Every time blankshield is used.

FYI @danielstjules

In a recent WHATWG spec change, all target="_blank" links should now imply rel="noopener". And the opener link relation was added.

Additionally, the rel attribute is now supported on <form> elements as well.

https://bugs.chromium.org/p/chromium/issues/detail?id=898942
https://bugzilla.mozilla.org/show_bug.cgi?id=1503681
https://bugs.webkit.org/show_bug.cgi?id=190481

Neither the rel=noreferrer nor the window.open techniques appear to prevent tab-nabbing in Safari 8. Screencast of your demo page is attached.