Comments below:
Adam James Fitzpatrick wrote:
>
> Rip Toren <[EMAIL PROTECTED]> wrote:
>
> >Ok;
> > This is getting interesting. Now, the question is whether the browser
> >is the correct place to work this problem?
>
> [snip]
>
> >It seems to me it has just become more obscure. The real problem seems
> >to be the server on port 25 accepting the mail for forwarding.
>
> No it's not - say the malicious web page recognises my ISP and sends back
> <IMG SRC="ftp:[EMAIL PROTECTED]:25";> which tells
> my web browser to connect to my SMTP server. Because that is my ISP's SMTP
My original thoughts were in the contect of a mal-user attacking
some other site using the browser. Then it was an relaying problem for
the sendmail daemon. But this approach (local browser connecting to
local sendmail) is a new kettle of fish.
The recent growth in dynamic HTML (under whatever names) makes it all
the easier to tailor, at the webserver, the URLs being sent back. The
above scenario seems very likely.
> server, it's *supposed* to accept mail from my IP address.
>
> >That input could come from a perl script, a telnet, or a custom program as
> >well as Mozilla. Maybe the connection should be blocked in Telnet as
> >well? Perl? where does it stop?
>
> It definitely is a problem in the browser. FTP does not permit the LF
> character in a user name, so Mozilla should reject a URL which has %0A
> in the user-name part of the URL. Instead, Mozilla is passing the LF
> through to the server, followed by the rest of the bogus user name - which
> is interpreted in that example as a sequence of SMTP commands.
There are at least 2 modes of solution. The first is mentioned here,
with the browser being the ultimate knowledge of all possible protocols
and being able to recognize any mal-formed URLs using that protocol. But
until all of that knowledge can be codified, I have a different
suggestion.
The connection goes either to the outside world, or localhost. How about
a security popup (and associated preference settings (allow, question,
deny)) concerning connection to the local host (localhost,
127.0.0.1,myIP,etc). Then the user would be in some control when a page
attempted to use the somewhat priveleged state of having the socketpeer
being the local host.
>
> The AllowPort() change is big (from a quick look at bonsai[1], it seems
<<snip>>
> we'll get a better idea of what it's about.
>
> [1]
> --
> Adam Fitzpatrick
