[Javascript] ssi, layers, table alternative to frames

[Michael Dougherty]

>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!"

...at least you keep yourself amused... <g>

-----Original Message-----
From: javascript at LaTech.edu [mailto:javascript at LaTech.edu]
Sent: Monday, April 14, 2003 10:51 PM
To: javascript at latech.edu
Subject: Re: [Javascript] ssi, layers, table alternative to frames



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
_______________________________________________
Javascript mailing list
Javascript at LaTech.edu
https://lists.LaTech.edu/mailman/listinfo/javascript