Re: [ProgSoc] Servlets

[Suresh Rajagopalan <suresh@nospam.progsoc.uts.edu.au>]

Well there you have it.
I will quite plainly make this factual statement:
Servlets are much more secure than CGI.

So if we are good enough to have CGI on here, then servlets need not be a
problem.
Servlets were designed to be a much better replacement for CGI.

On Fri, 2 Feb 2001, Greg Kopff wrote:

> At 08:34 AM 2/2/01 +1100, you wrote:
> >You can't just blithely say there are no security problems because
> >the JVM takes care of it... what about the points that I was asking?
> >* How does a servlet get write access local files (if at all)?
> 
> The Java Virtual Machine allows you to assign permissions to various things
> like disk access.  Attempting to break a permission results in a run-time
> exception.  The default policy file is probably <jdk
> dir>/jre/lib/security/java.policy.  By default, you have read and write
> access to the local filesystem.
> 
> >* How to control which local files it can access?
> 
> Again, the security policy.  And then there's the underlying OS's file
> system permissions ...
> 
> >* How can it do mysql queries?
> 
> You use the Java Database Connectivity stuff.  Never used it myself though.
>  Databases are slow and ugly.
> 
> >* Is it possible for a local user to read the servlet code
> >  and extract mysql passwords?
> 
> Servlets are like other Java programs.  You take your source and compile it
> to a class file.  So, just like a CGI, one could read passwords by:
>  - looking at the source
>  - running strings on the binary
> 
> >So how is this different from a regular CGI?
> 
> A regular CGI is forked and execed.  However, when a servlet is invoked the
> first time, the class file(s) are dynamically loaded by the JVM.  Each
> subsequent request is therefore much faster because invocation is simply a
> method call to the now resident class.  Servlets are faster than
> conventional CGIs because a servlet runs in the context of a thread, or
> light-weight process, which in many operating systems permit much faster
> context switching than heavy-weight processes.
> 
> >My understanding is that the client (i.e. browser) sends a
> >URL along with either GET or POST data (containing form parameters)
> >to the web server which then runs some program to process
> >the data and return HTML back to the browser. This is what
> >CGI programs do and I'm wondering if there is anything different
> >about servlets which makes them need to be handled differently.
> 
> Yes, a servlet is much like a CGI - however it is more tightly integrated
> with the webserver/servlet engine.  Instead of having to do lots of fiddly
> string manipulations on environment variables or command line arguments
> passed to a CGI process (with the inherent buffer overrun implications),
> servlets enable you to access all relevant details associated with the
> request via nicely encapsulated objects via accessor methods (giving you
> type safety).
> 
> >Well if you want Tomcat then we have to compile it together with
> > (...)
> 
> Alternatively, there is the W3 consortium's Jigsaw Webserver and Servlet
> Engine which is all written in Java.  See http://www.w3.org/jigsaw - then
> there's no need to modify apache.  Also, you get the full benefits of
> running servlets without apache's bloat.
> 
> 
> Regards,
> 
> 
>  Greg Kopff
> ===================================================
> gkopff@nospam.powersource.com.au      PowerSource Software
> Technical Director    http://www.powersource.com.au
> ===================================================
>   "We mock what we don't understand."
>                                - Austin Millbarge
> ===================================================
> -
> You are subscribed to the progsoc mailing list. To unsubscribe, send a
> message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
> If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.
> 

-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.