Active XSS filters don't like the buttons.

[Moonchild]

There's a problem with the way the buttons are implemented in that active XSS filters (that compare requests and results) will trip over the buttons -- specifically because the iframe contents include a base tag which has a URL exactly equal to the URL passed (URLEncoded) in the iframe's src.

From a filter's perspective this would be a reflected XSS attack by having a base statement injected (a common redirection tactic). You may be able to easily work around this by:

• using absolute paths and dropping the base tag, or
• changing the way the iframe content is constructed so it no longer includes the base URL in the src of it

[Juliette]

Presuming these commits have all gone live, the issue is still not fixed or is back again:

[なつき]

I believe that is a false alert. Following is how javascript filtering works currently:

1. The button renders on the same origin to calculate its size.
   1. In this time, <base> is not used. No href attribute is written.
2. Then, the button reloads in different origin (buttons.github.io).
   1. Set <base> attribute href to button link.
      1. If a javascript protocol is detected, reset href to #.
   2. Set button href.
      1. If a javascript protocol is detected, reset href to #.
   3. Set count href.
      1. If a javascript protocol is detected, reset href to #.
      2. Use <base href> and a.cloneNode().href to get an absolute url for count.
   4. Remove attribute href on <base>

I think the false alert is triggered in step 2.i., which is required for step 2.iii.b.. The reason to filter javascript after set href is that href normalizes url (remove whitespace, etc.), so javascript protocol can be detected reliably.

<base href> or any href won't be executed without clicking a link, and javascript should have been removed before a user can interact with the page.

For example, the following code will result in a link with href="#".

<a class="github-button" href="javascript:alert('hi');" ></a>

Please correct me, if I am wrong.

[Juliette]

It really doesn't matter whether this is a false positive or not. No-one in their right mind will choose to use a script which triggers this warning as it will reflect badly on the perception of their website and brand... which is of course why I'm informing you of it.

[なつき]

I just committed a workaround that does not use <base>. It uses URL API (WhatWG, MDN), which is currently supported by Chrome, Firefox, and Safari. On other browsers that lack of URL API support, it will fallback to current solution.

Unfortunately, this workaround won't suppress the warning until Pale Moon implements URL API. Considering Pale Moon has only about 0.02% of market share, I'd wait its developer for implementing the URL API, rather than ship a polyfill that may increase the script size by 5x.

[Moonchild]

For the record, implementing the constructor method for the URL API is on our roadmap (likely for the next major update). If you're looking to use the API for the current location, then the data is already available via URLUtils' window.URL which is supported by all browsers.