JavaScript on FTP-served pages

General discussion about the NoScript extension for Firefox
Post Reply
PLD
Junior Member
Posts: 30
Joined: Fri May 08, 2015 7:00 am

JavaScript on FTP-served pages

Post by PLD » Wed Jul 27, 2016 8:40 pm

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?
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

barbaz
Senior Member
Posts: 9176
Joined: Sat Aug 03, 2013 5:45 pm

Re: JavaScript on FTP-served pages

Post by barbaz » Wed Jul 27, 2016 8:47 pm

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.
*Always* check the changelogs BEFORE updating that important software!
-

User avatar
therube
Ambassador
Posts: 7425
Joined: Thu Mar 19, 2009 4:17 pm
Location: Maryland USA

Re: JavaScript on FTP-served pages

Post by therube » Thu Jul 28, 2016 1:56 am

Sample page: ftp://ftp.intel.com/.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40

PLD
Junior Member
Posts: 30
Joined: Fri May 08, 2015 7:00 am

Re: JavaScript on FTP-served pages

Post by PLD » Thu Jul 28, 2016 2:29 am

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[s] 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?
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

User avatar
therube
Ambassador
Posts: 7425
Joined: Thu Mar 19, 2009 4:17 pm
Location: Maryland USA

Re: JavaScript on FTP-served pages

Post by therube » Thu Jul 28, 2016 2:11 pm

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:.]
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows NT 5.1; rv:43.0) Gecko/20100101 SeaMonkey/2.40

PLD
Junior Member
Posts: 30
Joined: Fri May 08, 2015 7:00 am

Re: JavaScript on FTP-served pages

Post by PLD » Thu Jul 28, 2016 11:06 pm

As for proposals to remove built-in FTP support:
https://bugs.chromium.org/p/chromium/issues/detail?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.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

barbaz
Senior Member
Posts: 9176
Joined: Sat Aug 03, 2013 5:45 pm

Re: JavaScript on FTP-served pages

Post by barbaz » Thu Jul 28, 2016 11:33 pm

*Always* check the changelogs BEFORE updating that important software!
-

PLD
Junior Member
Posts: 30
Joined: Fri May 08, 2015 7:00 am

Re: JavaScript on FTP-served pages

Post by PLD » Sat Jul 30, 2016 1:21 pm

@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.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

barbaz
Senior Member
Posts: 9176
Joined: Sat Aug 03, 2013 5:45 pm

Re: JavaScript on FTP-served pages

Post by barbaz » Sat Jul 30, 2016 4:09 pm

(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.
*Always* check the changelogs BEFORE updating that important software!
-

PLD
Junior Member
Posts: 30
Joined: Fri May 08, 2015 7:00 am

Re: JavaScript on FTP-served pages

Post by PLD » Sat Jul 30, 2016 6:33 pm

I asked because I tried these:

Code: Select all

Site ws:
Deny ALL from ALL

Site wss:
Deny ALL from ALL


and these:

Code: Select all

Site ws://echo.websocket.org
Deny ALL from ALL

Site wss://echo.websocket.org
Deny ALL from ALL


and these:

Code: Select all

Site http://echo.websocket.org
Deny ALL from ALL

Site https://echo.websocket.org
Deny ALL from ALL


and this:

Code: Select all

Site echo.websocket.org
Deny ALL from ALL


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.
Last edited by barbaz on Sun Jul 31, 2016 12:54 am, edited 1 time in total.
Reason: wrap in code tags to prevent linkification by the board
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

barbaz
Senior Member
Posts: 9176
Joined: Sat Aug 03, 2013 5:45 pm

Re: JavaScript on FTP-served pages

Post by barbaz » Sun Jul 31, 2016 12:53 am

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?
*Always* check the changelogs BEFORE updating that important software!
-

PLD
Junior Member
Posts: 30
Joined: Fri May 08, 2015 7:00 am

Re: JavaScript on FTP-served pages

Post by PLD » Sun Jul 31, 2016 2:32 pm

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/issues/detail?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.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

barbaz
Senior Member
Posts: 9176
Joined: Sat Aug 03, 2013 5:45 pm

Re: JavaScript on FTP-served pages

Post by barbaz » Sun Jul 31, 2016 3:09 pm

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.
*Always* check the changelogs BEFORE updating that important software!
-

Post Reply