InformAction Forums

From NS 2.9.0.12 release notes:

[XSS] Disable JavaScript on FTP-served pages when a potential DOM XSS threat is detected (thanks Emanuel Bronshtein @e3amn2l for reporting)

Uh, so Javascript is enabled on (other) FTP-served pages? What is an example of this? I can't remember ever trying to FTP get an html file using Firefox. If I did, would Firefox process the html file and execute its Javascript instead of saving it to a local file?

PLD wrote:Uh, so Javascript is enabled on (other) FTP-served pages?

Yep, it should be enabled if you whitelisted or Temporarily allowed the site.

PLD wrote: I can't remember ever trying to FTP get an html file using Firefox. If I did, would Firefox process the html file and execute its Javascript instead of saving it to a local file?

Quick test indicates, yes that's exactly what happens.

Sample page: ftp://ftp.intel.com/.

I now see you can embed things (iframes, imgs, probably more) using ftp:// urls too. So what could go wrong?

+ Browser code that doesn't handle ftp scenarios as well as it should?
+ Extension code that doesn't handle ftp scenarios as well as it should?
+ Extension rules that are created with http in mind and don't also match ftp urls when they should?
+ External monitoring and/or blocking systems that neglect the ftp scenarios?

Disabling FTP might be the way to go. Lets assume it remains enabled though. I created an html file that embeds an iframe via ftp, an img via http, and an img via ftp. Test browser was fresh FF 47.0.1 portable with NS 2.9.0.12.

1) Load page via http: All the embeds worked. As expected.
2) Load page via https: FF blocked iframe (active content blocked by default), both imgs retrieved (display content allowed by default). As expected, but the mixed display content can be very bad.
3) Set security.mixed_content.block_display_content=true.
4) Load page via https: FF blocked iframe and imgs. As expected, but will cause problems for some content at some websites. Need finer control.
5) ABE can be used to solve the display content problem, by selectively accepting/denying http at https sites. Will it work for ftp too? Return security.mixed_content.block_display_content=false before testing.
6) I'm stuck. Can you get it to work?

Disabling FTP

That was on Mozilla's agenda at one point (& likely will come up again).
[Does Chrome support FTP? If not, you can be sure Mozilla will drop it.
And after that, they're after http:.]

As for proposals to remove built-in FTP support:
https://bugs.chromium.org/p/chromium/is ... ?id=333943 (available)
https://bugzilla.mozilla.org/show_bug.cgi?id=1174462 (verified wont fix)

Firefox related:
https://bugzilla.mozilla.org/show_bug.cgi?id=1219201 (comment: ftp is deprecated but letting it ride)
https://bugzilla.mozilla.org/show_bug.cgi?id=1219194 (comment: only security fixes to ftp code)

I think (nonsecure) FTP may still be common-ish in some circles. Hard to know, since blocking url gathering and telemetry is common and there is equipment on private networks that may still use it. I was only saying that it might be wise to disable it where it is not needed.

I haven't found a simple off switch. The prefs network.protocol-handler.expose.ftp and network.protocol-handler.external.ftp look helpful. AdblockPlus can block the embeds as long as there are no exceptions. I think ublock extended ABP syntax and maybe (shrug) it can limit exceptions and block top level requests.

I tried again but couldn't get ABE to block it. I don't know if it is operator error, a bug, oversight, or by design. I'll wait awhile and if no answer I'll report it as a bug.

About ABE and ftp viewtopic.php?p=78594#p78594

@barbaz: Thanks, at least I know it isn't blocking ftp for others either. I saw that Site pattern intended to match the ws and wss schemes. Are you able to block websockets with ABE? Example: Allow javascript on www.websocket.org/echo.html but block the websocket connections to echo.websocket.org.

(According to uBlock Origin) Websocket connections are sent to HTTP observers with the ws(s) scheme mutated into http(s), so yes ABE probably can block those.

I asked because I tried these:
and these:
and these:
and this:
and none of them worked. FF 47.0.1 portable with NS 2.9.0.12. Also tried my main system with FF 47.0.1, NS 2.9.0.12, and other extensions, same results.

Odd. I've confirmed A) ABE ignores WebSockets, B) uBlock Origin isn't doing anything special to see the WebSockets in its HTTP observer.

Is this a bug in ABE?

I hadn't tested uBlock Origin in Firefox against websockets and figured I should. My results:

1) ||echo.websocket.org^ (worked)
2) http://echo.websocket.org (worked)
3) ws://echo.websocket.org (doesn't work)

I'd call that positive results. However, there is the question of whether websockets should be blocked using #2, #3, or both. The websocket upgrade requests are http/https, so in a way it makes sense for http/https rules to match those upgrade requests. On the other hand, there may be circumstances where someone would want to allow http/https at example.com while denying websockets there. Someone else might want to deny http/https at a site while allowing websocket connections there. When it comes to those that want to restrict websockets, the most popular approach may be blocking websockets at all sites and only whitelisting the websocket connections that they are OK with.

Supported filter syntax will help determine what is and isn't possible. In addition to browser APIs. I don't know what Ublock Origin is doing to address websockets in Firefox, but I think it does require special handling (separate helper addon) to address websockets in Chrome like browsers due to https://bugs.chromium.org/p/chromium/is ... ?id=129353.

I think it is important for "web filters", "web firewalls", and other blockers to be able to block the schemes/protocols that web pages and applications can use. Especially those that can be used to perform exchanges with remote servers. If you can't block ws:/wss: or ftp: or whatever, you have a hole that might be exploited. Are there any other schemes we should take a look at while we're on this subject?

FYI, I tested uBlock Origin and AdblockPlus in Chrome. AFAICT, neither is able to block ftp:. I also tested uBlock Origin in Firefox, and it didn't detect or block my ftp: tests. Those interested should double check me.

PLD wrote: there may be circumstances where someone would want to allow http/https at example.com while denying websockets there. Someone else might want to deny http/https at a site while allowing websocket connections there. When it comes to those that want to restrict websockets, the most popular approach may be blocking websockets at all sites and only whitelisting the websocket connections that they are OK with.

uBlock Origin uses the (undocumented) filter option $websocket to make a filter match only websocket connections.

PLD wrote:FYI, I tested uBlock Origin and AdblockPlus in Chrome. AFAICT, neither is able to block ftp:. I also tested uBlock Origin in Firefox, and it didn't detect or block my ftp: tests. Those interested should double check me.

And consider searching their issue tracker: https://github.com/gorhill/uBlock/issues/1343

This is getting off-topic so can we please take further uBlock Origin specific discussion here? Thanks.

PLD wrote:I think it is important for "web filters", "web firewalls", and other blockers to be able to block the schemes/protocols that web pages and applications can use. Especially those that can be used to perform exchanges with remote servers. If you can't block ws:/wss: or ftp: or whatever, you have a hole that might be exploited. Are there any other schemes we should take a look at while we're on this subject?

Well it depends on the purpose of the blocker. ABE is designed specifically to block CSRF; whatever else might get allowed through is immaterial.
Let's keep this in mind when figuring what protocols ABE is missing support for blocking.

I would guess that it's quite likely that websockets could theoretically be exploited in CSRF. The only bad thing I can think could happen from cross-site request to ftp protocol is use of the browser to DoS attack the ftp site, but last I checked, NoScript has protection against DoS attempts elsewhere, so I'm not sure ABE needs ftp support.