Feature Request: please implement overriding of blocked network ports
https://bugs.webkit.org/show_bug.cgi?id=14100
Summary Feature Request: please implement overriding of blocked network ports
Indrek Siitan
Reported 2007-06-12 11:59:31 PDT
Hello, looks like this following patch to implement blocking of ports similar to FF is seriously biting me: http://trac.webkit.org/projects/webkit/changeset/20227 Namely, Hanza.Net, the online banking app of my bank, is using port 563 if you're authenticating with the government-issued ID smartcard (http://www.id.ee/?lang=en). For password-based authentication, the normal SSL port (443) is used, but in that case there are some serious caps to transfer amounts, etc. FF has implemented a configuration option to override that, that is suggested for FF users on the bank's website: http://www.hansa.ee/midauut/2006_10/firefox.html As a die-hard Safari fan and user, I kindly ask to implement a similar way to work around that restriction - such as by editing the plist file or anything. :) Indrek
Attachments
Alexey Proskuryakov
Comment 1 2007-06-23 06:06:28 PDT
Hmm... This is a regression that affects a banking site, why it isn't a P1?
Indrek Siitan
Comment 2 2007-06-23 06:24:03 PDT
Well, it's a bank in Estonia, not US. :) But some quick numbers - Hanza.Net currently has ~700K users, and the Safari penetration is roughly around 5% in Estonia (which might rise a bit though with the Windows version). So this is going to hit around 35000 users when 3.0 goes production.
Rosyna
Comment 3 2007-06-23 06:38:27 PDT
Don't many ISPs block port 563 (SSL+NNTP) as it can be used to get inappropriate files that is against the TOS of said ISP (like pornography, pirated materials, or otherwise subversive materials)? In fact, I thought this was a default block on some corporate internet routers. But that's for this specific port. I am still confused as to why this port list is embedded inside a source code file instead of a separate resource file like in the case of the IDN whitelist list.
David Kilzer (:ddkilzer)
Comment 4 2007-06-23 12:17:43 PDT
Maciej Stachowiak
Comment 5 2007-07-06 02:21:01 PDT
The original restriction was made to prevent web sites from doing cross-protocol attacks, where sometimes an http request might look like a request from some different protocol. I think it's probably safe to allow odd ports for the main document, though. It's pretty hard to use that as an attack. And if the main document comes off of a weird port, subresources could come from the same host+port. I'd have to look at the original security bug that spawned this to make sure.
Maciej Stachowiak
Comment 6 2007-07-06 02:24:36 PDT
Scratch that - I don't think my suggestion would work. See original vulnerability report at http://www.remote.org/jochen/sec/hfpa/index.html
Mark Rowe (bdash)
Comment 7 2007-07-06 02:44:51 PDT
I filed a new P1, bug 14538, which is specifically about the breakage of the banking website. This existing bug is about the proposed enhancement of being able to disable all network port blocking via a user default or similar.
Indrek Siitan
Comment 8 2007-07-06 02:49:16 PDT
Well, I whined at the bank until they finally went ahead and are moving the smartcard-authorized site to a separate host as soon as the Verisign certificate arrives.
J Towler
Comment 9 2007-12-07 07:18:54 PST
Safari is blocking me from viewing a site on port 6000 (as used by QNAP NAS devices). Is there another bug for adding comments about this, or is this the best one? My problem isn't with other sites that use non-standard ports. 6000 is my primary one, not checked other ports for failure yet. On updating OSX, and getting Safari 3, Safari has become pretty much useless to me. Presumably having some over ride feature such as FF would do the trick? Can anyone point in the direction of instructions / hints to build my own copy of webkit / safari, in the short term. (Sorry, not really a good chunk of text to add to a bug report, but I can't find anywhere better to add info).
Scott Perry
Comment 10 2010-06-11 13:00:47 PDT
ZNC (the IRC bouncer) uses the same port for both IRC and its administrative interface. frequently this port is in the IRC range, making administration via Safari impossible.
Joel Peterson
Comment 11 2011-03-30 15:37:04 PDT
Why is this still an issue more than 3 years later? I'm having the same experience on iOS 4.2.x with port 6000.
Note You need to log in before you can comment on or make changes to this bug.