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?[XSS] Disable JavaScript on FTP-served pages when a potential DOM XSS threat is detected (thanks Emanuel Bronshtein @e3amn2l for reporting)
JavaScript on FTP-served pages
JavaScript on FTP-served pages
From NS 2.9.0.12 release notes:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Re: JavaScript on FTP-served pages
Yep, it should be enabled if you whitelisted or Temporarily allowed the site.PLD wrote:Uh, so Javascript is enabled on (other) FTP-served pages?
Quick test indicates, yes that's exactly what happens.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?
*Always* check the changelogs BEFORE updating that important software!
-
Re: JavaScript on FTP-served pages
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
Re: JavaScript on FTP-served pages
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?
+ 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
+ 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
Re: JavaScript on FTP-served pages
That was on Mozilla's agenda at one point (& likely will come up again).Disabling FTP
[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
Re: JavaScript on FTP-served pages
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.
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.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Re: JavaScript on FTP-served pages
About ABE and ftp viewtopic.php?p=78594#p78594
*Always* check the changelogs BEFORE updating that important software!
-
Re: JavaScript on FTP-served pages
@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
Re: JavaScript on FTP-served pages
(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!
-
Re: JavaScript on FTP-served pages
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.
Code: Select all
Site ws:
Deny ALL from ALL
Site wss:
Deny ALL from ALL
Code: Select all
Site ws://echo.websocket.org
Deny ALL from ALL
Site wss://echo.websocket.org
Deny ALL from ALL
Code: Select all
Site http://echo.websocket.org
Deny ALL from ALL
Site https://echo.websocket.org
Deny ALL from ALL
Code: Select all
Site echo.websocket.org
Deny ALL from ALL
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
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
Re: JavaScript on FTP-served pages
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?
Is this a bug in ABE?
*Always* check the changelogs BEFORE updating that important software!
-
Re: JavaScript on FTP-served pages
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.
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.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Re: JavaScript on FTP-served pages
uBlock Origin uses the (undocumented) filter option $websocket to make a filter match only websocket connections.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.
And consider searching their issue tracker: https://github.com/gorhill/uBlock/issues/1343PLD 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.
This is getting off-topic so can we please take further uBlock Origin specific discussion here? Thanks.
Well it depends on the purpose of the blocker. ABE is designed specifically to block CSRF; whatever else might get allowed through is immaterial.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?
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!
-