Hi,
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 environment 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 administrator to be 
conscious of security issues and address them proactively.

That said, I'd support the statement in the first paragraph on two grounds.  One is a 
simple historical comparison: use any search you like (plain Google, or forums like 
Bugtraq and CERT) and you'll see many more CGI-based attacked and vulnerabilities than 
Servlet-based ones.  Of course some of that is because CGI is an older and was more 
widely used for a long time, but those facts are irrelevant for the point of this 
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, make sure the user running it has 
only the required privileges, etc.  With Servlets, you can apply extremely 
fine-grained security using a variety of approaches like PrivilegedActions, 
SecurityManager (these two are inside the JVM and portable), the security-constraint 
elements in web.xml (which can also be done for CGI in most servers, like httpd), and 
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 given Servlet is 
secure than a given CGI script, IMHO.  If someone has tons of experience in CGI 
security assessments and little in Java, they might say the opposite ;)

As far as wiki implementations, let's see.  Of the top of my head, Friki 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:[EMAIL PROTECTED]
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 OddMuse, on a 
website that runs on a Linux server. In 'Using Linux (Fourth Edition)', the authors 
warn that "The biggest cause for concern about protecting your site from external 
threats is CGI scripts." They go 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 Programming (Second Edition)' 
which has a 30 page chapter on Security that details how various forms of 
authentication take place in servlets. However, I can't find any categorical statement 
that says servlets are actually any more secure than CGI.
 
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 more secure and why? I need this 
information so that we can choose the right approach for our wiki.
 
Also, if servlets are more secure than CGI, is anyone aware of a wiki that runs as a 
servlet, preferably open source?
 
 
Rhino
---
rhino1 AT sympatico DOT ca
"There are two ways of constructing a software design. One way is to make it so simple 
that there are obviously no deficiencies. And the other way is to make it so 
complicated that there are no obvious deficiencies." - C.A.R. Hoare



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to