[Javascript] ssi, layers, table alternative to frames

[David T. Lovering]

There are several reasons.  First, (as you noted) the SSI file's are buck
nekkid (techo-lingo), and can't be "hidden" in the fashion of normal files
and/or directories.  Next, since the process that devolves the SSI is actually
part of the web-server (Apache, et al), unless the web-server has been deliberately
neutered to be a non-root process, the resulting SSI will have root privileges.
If so, it can go anywhere, see anything, and generally mess about with things
one rather would not have messed with.  Yes, it is possible to build a "safe" 
web-server, but with so many people building theirs with "out-of-the-box" code,
they almost never are.  [It took me 25 minutes to build my web-server, the modules,
and the SSL certificates.  It then took me 2 weeks to harden it properly].

In addition, there are some particularly tasty methods of overflowing an SSI
(one classic exploit is the 'infinite backward regression' method), forcing it into
a trap condition that opens what is, for all intents and purposes, a root shell.
The insecure.org site (which is getting rather long in the tooth, and may have
been shut down by the Homeland Security nazis) used to have some classic exploits
for doing this.

Also, unless the SSI is embedded deep inside an authenticated code module, anybody
with FrontPage or a simple text-editor can whomp up a routine that will poke it
with arbitrary code.  "Poking with arbitrary code" is the equivalent of breaking
into your box.  At least with SSL or IPSec you have a trace id of the bozo that
bonked your machine -- plain old HTML doesn't even do that.

In general whenever dealing with an SSI I always have a mental image of Robbie the
Robot waving its arms about and shouting "Danger Will Robinson! Danger!"

-- Dave Lovering

Andrew Gibson wrote:
> 
> is that because the SSI's files themselves aren't protected, even when the
> main page that includes them is?
> 
> Andrew Gibson
> 
> >
> > As an added downside of SSI's -- they are NOTORIOUSLY insecure.  When I
> first
> > started honing my teeth on browser exploits for my computer security
> training,
> > the very start of the discussion was on the many easy and exciting ways to
> > crack a system that had SSI's in place and operational.  Although I've
> forgotten
> > much of what I learned during that series of CSI seminars, the frightening
> > simplicity of the exploits involved still sends shivers up my spine --
> particularly
> > when I hear well-meaning folks relying on those self-same server-side
> includes
> > today.  (Sort of the same frisson I get from finding someone enabling
> anonymous
> > FTP on a host that doesn't have backwards-path exclusion turned on).
> >
> > When I look through the latest Apache "Black Book", it still warns against
> enabling
> > SSI's except for the simplest of things.  Most military and government
> systems
> > have a flat-out edict against SSI's, period -- for precisely that reason.
> Next to
> > buffer-overflow exploits, SSI's are a hacker's (oops! I mean a
> "cracker's") best
> > friend.
> >
> 
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript