Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Security of Servlets
Date: Thu, 30 Sep 2004 15:18:25 -0400
Message-ID: <9C5166762F311146951505C6790A9CF801FC3940@US-VS1.corp.mpi.com>
Thread-Topic: Security of Servlets
Thread-Index: AcSnHyF5A300e4/GR9q7zgIAHouJlAAAd49w
From: "Shapira, Yoav" <Yoav.Shapira@mpi.com>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>


H=
i,
I'd say it's easier to expose security flaws with CGI scripts than it =
is with Servlets, and vice versa it's easier to configure a secure env=
ironment for Servlets than it is for CGI scripts.

That's not the same as saying "Servlets are more secure than CGI."  I =
don't think such a categorical statement would be valid for this case,=
 and it's a waste of time looking for such a statement.

Both technologies require the system designer, deployer, and administr=
ator to be conscious of security issues and address them proactively.

That said, I'd support the statement in the first paragraph on two gro=
unds.  One is a simple historical comparison: use any search you like =
(plain Google, or forums like Bugtraq and CERT) and you'll see many mo=
re CGI-based attacked and vulnerabilities than Servlet-based ones.  Of=
 course some of that is because CGI is an older and was more widely us=
ed for a long time, but those facts are irrelevant for the point of th=
is discussion.

The second ground is the existence of finer grained control over Java =
code.  To secure a CGI script, you'd have to peer-review its code, mak=
e sure the user running it has only the required privileges, etc.  Wit=
h Servlets, you can apply extremely fine-grained security using a vari=
ety of approaches like PrivilegedActions, SecurityManager (these two a=
re inside the JVM and portable), the security-constraint elements in w=
eb.xml (which can also be done for CGI in most servers, like httpd), a=
nd Java's built-in controls over memory allocation and such low-level =
matters.

So both technologies can be made secure, but it's easier to assure a g=
iven Servlet is secure than a given CGI script, IMHO.  If someone has =
tons of experience in CGI security assessments and little in Java, the=
y might say the opposite ;)

As far as wiki implementations, let's see.  Of the top of my head, Fri=
ki is Java and open source (SourceForge).  MoinMoin is Python.  Litux =
is in the middle: Jython ;) 

Yoav Shapira
Millennium Research Informatics


-----Original Message-----
From: Rhino [mailto:rhino1@sympatico.ca] 
Sent: Thursday, September 30, 2004 2:56 PM
To: tomcat-user
Subject: Security of Servlets

We are giving some thought to putting a CGI-based Wiki, specifically O=
ddMuse, on a website that runs on a Linux server. In 'Using Linux (Fou=
rth Edition)', the authors warn that "The biggest cause for concern ab=
out protecting your site from external threats is CGI scripts." They g=
o on to suggest various precautions that will reduce the risk.
This has me wondering if servlets are equally insecure or have a much =
stronger security model. I also have Jason Hunter's 'Java Servlet Prog=
ramming (Second Edition)' which has a 30 page chapter on Security that=
 details how various forms of authentication take place in servlets. H=
owever, I can't find any categorical statement that says servlets are =
actually any more secure than CGI. 
=A0
I was wondering if someone with extensive experience with the security=
 aspects of both servlets and CGI can give me any sense of which is mo=
re secure and why?=A0I need this information so that we can choose the=
 right approach for our wiki.
=A0
Also, if servlets are more secure than CGI, is anyone aware of a wiki =
that runs as a servlet, preferably open source?
=A0
=A0
Rhino
---
rhino1 AT sympatico DOT ca
"There are two ways of constructing a software design. One way is to m=
ake it so simple that there are obviously no deficiencies. And the oth=
er way is to make it so complicated that there are no obvious deficien=
cies." - C.A.R. Hoare


This e-mail, including any attachments, is a confidential business com=
munication, and may contain information that is confidential, propriet=
ary and/or privileged.  This e-mail is intended only for the individua=
l(s) to whom it is addressed, and may not be saved, copied, printed, d=
isclosed or used by anyone else.  If you are not the(an) intended reci=
pient, please immediately delete this e-mail from your computer system=
 and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org