🚀 go-pugleaf

Thus said jpmork@primenet.com (Jim Mork):
>Well, I've read the responses so far, and what I get is this:  graphical
>Web browsers run by downloading an applet, so if a Lawrence Livermore

*Some* graphical Web browsers run by downloading applets.  Not all do,
and there's no reason non-graphical browsers couldn't do this as well.
A version of HotLynxJava would actually be pretty neat, although it
seems likely most Java scripts will do useless eye candy rather than
add real functionality.

>Our manager wants to go ahead with WWW presence, but is concerned that
>we could get infected.  But, then, that wo uld seem to require that
>employees would be browsing the web, hardly the kind of thing we are
>getting connected for.  Of course, we don't want citizens logging on
>and getting anything from us (bad PR), but how wo uld the above
>conditions permit US to get infected.

The problem is that it's all rather complicated.  The Web involves
several different protocols and a potentially unlimited number of
media types implemented under different envirnoments by a number of
different programs.  All of these things have to be considered if you
really need a total security picture, and would need to be considered
against your security policy (since there can be substantial variances
in what various organizations consider a violation.)

A few of the more common concerns with reading stuff include things like:

- The famous gopher URL spoof.  RFC 1738 discusses it, and some
  popular browsers are still vulnerable to it.
- Postscript is an interpreted language, and there may exist
  vulnerabilities in downloading and interpreting it from elsewhere.
  RFC 1521 discusses this some.
- Any application program (Word processor, spreadsheet, whatever)
  that has some type of macro facility it potentially a risky media
  type, since some macroing languages can create viruses or other
  security problems.  Unfortunately, proper security reviews of
  such media types are not generally performed prior to their
  widespread use.  Thanks a lot, Gopher.
- If you have a security policy on interactions between your internal
  network and the big net, it will need to be looked at.  If you have a
  firewall and need a proxy to get past it, try to use one that will
  enforce that policy.

If you're setting up a Web server, the security of that server itself
and access to it without giving public access to portions of your
network you don't want to is more important.  HTTP servers can have
security considerations, certainly.  Some are vulnerable to the
grappling-hook attack that Robert Morris' worm used on finger, for
example.

If you need a real, "this is mission-criticial and if I make the wrong
call I could get fired" answer, don't get it from the net.