Pale Moon 26 debuts a new security feature: an active XSS (cross-site scripting) filter.
This thread is reserved for feedback given on the XSS filter only. Please keep your posts on-topic.
Please read this post fully before commenting on it. Your question/report may already have been addressed. Thank you!
What is this thing and how do I use it?
The XSS filter blocks pages from getting scripts and content inserted into it from external sources (injection). The focus lies mainly on preventing injection into vulnerable pages through specifically crafted URLs that users are tricked into clicking or using instead of normal URLs (e.g. through phishing e-mails, malicious posted links, etc.), but may also result from using e.g. iframes to load content from different sites.
The filter works in the background while you surf, and should have no noticeable impact on browsing performance.
When the filter finds a potential XSS attack, it will block the content on the page it found to be unsafe and will present you with a warning in a yellow infobar at the top of the page:
- xssfilter1.png (1.93 KiB) Viewed 16689 times
- xssfilter2.png (2.56 KiB) Viewed 16689 times
- View unsafe content: Clicking this button will pop up a small window showing you what the filter found as unsafe content. It's always recommended to check this before taking any further action.
- Add Domain Exception: This button may or may not be present, depending on if a domain is involved in the injection (e.g. external scripts, external objects). Clicking this button will add a permanent exception to the domain the unsafe content is loaded from for all websites, so please make sure the domain is legitimate by inspecting the unsafe content first! After adding the exception, the page will automatically reload.
- Close button (x): This simply dismisses the infobar and keeps blocked content blocked.
You can switch the filter off and on in Options:
- security.xssfilter.enable: default true -- completely enables or disables the filter. Other options will have no effect if the filter is not enabled (obviously). This is the same as the option shown above.
- security.xssfilter.blockDynamic: default true -- enables or disables applying the filter to DOM-inserted content (dynamic scripts). This is currently limited to controlling checking for external scripts only. Disabling this will prevent the filter from hitting some potentially benign iframe loads and similar, but also poses a greater risk of the filter not catching malicious injections into pages. It's strongly recommended to always keep this enabled and using the whitelist (see below) instead.
- security.xssfilter.displayWarning: default true -- enables or disables the display of the warning bar when a potential XSS attack has been found by the filter. If disabled, the offending content will be blocked but the user will not be presented with the warning. To see XSS filter messages in this case, you need to check the error console (listed as information) or the browser console.
- security.xssfilter.blockMode: default false -- if enabled, the filter will completely prevent the page from loading, and will present a network error instead, explaining why the page wasn't displayed. This blocking mode can also be enabled by the server by sending the appropriate X-Xss-Protection header if they want to strictly enforce XSS filtering.
Note that by default, the filter will only block the unsafe content found and will allow the page to load otherwise. - security.xssfilter.ignoreHeaders: default false -- if enabled, this will ignore X-Xss-Protection headers and always enforce the user's choice. This can be useful if you encounter too many false positives that are completely blocked by the server with their X-Xss-Protection header which would prevent you from viewing the page.
- security.xssfilter.whitelist: this preference contains a comma-separated list (without whitespace) of domains that are trusted and whose content may always be loaded into other pages. In normal operation, entries to this list are added by using the "Add Domain Exception" button on the infobar.
You can manually add or remove domains here, or completely clear the whitelist by resetting the preference, restoring the default setting of not allowing exceptions except for those preconfigured by us (based on user feedback when testing). Completely clearing the string and making it empty will refuse all exceptions, including from known trusted domains. - security.xssfilter.srcwhitelist: this preference contains a comma-separated list (without whitespace) of domains that are trusted to always load external content in a safe way but omit setting the proper X-Xss-Protection header to disable XSS filters. The difference with the normal whitelist is that this list controls the loading sites, not the loaded content.
- security.xssfilter.reportOnly: default false -- if enabled, the filter will not actually block anything, but just report potential attacks. This is mainly useful for testing.
Being in the core of the browser, this filter has access to a number of APIs that extensions will never have available. As a result, it can do more than just inspect requests and block potentially malicious URLs. In this respect it is closer to Chrome's "XSS Auditor" than NoScript and companions in that it can actively compare requests and resulting pages.
Of note also is that the filter does not change requests to servers, which is a main problem for request-filtering protections as they can result in (sometimes severe) web site interaction problems by changing the request to the server. Instead, it filters the resulting page content, blocking unsafe (injected) parts of the page.
What sites have known issues with the filter?
(this will be updated over time as more details become available)
- PayPal: The log-in page of PayPal will throw up an XSS warning. This is caused by a "pixel" image on that page which loads a JavaScript from an external site. PayPal has already been made aware of this issue but so far proven unresponsive to do anything about it. You can ignore this warning for now and keep the content blocked since it seems to be harmless to do so (and doesn't break logging in), but considering this is a financial institution, we did not want to whitelist the site and disable XSS protection on it; exactly on those kinds of sites it matters to have the filter!
Before you post a new issue, please:
- Check if someone else has already reported it in this thread. Please prevent duplicate posts, which make keeping things organized harder. Duplicate reports may be removed by moderators.
- Check if the issue found is specific to this XSS filter feature! If the problem can be reproduced without the filter active, then your report does not belong in this thread.
