[OWASP-LEADERS] Basic security scheme for web app implemented.

Ingo Struck ingo at ingostruck.de
Tue Feb 4 11:59:35 EST 2003


Hi folks...

Within the OCL / owasp.aux.servlet.ServletUtil now exist some methods
to ensure a basic security scheme for requests/sessions.

The only thing a servlet must do to use it, is to call
	ServletUtil.checkRequest( request, response )
and stop request processing immediately if the method returns
false. The session object that denotes a valid user must be accessed
through
	ServletUtil.setUser( request, user ) 
	ServletUtil.getUser( request ).
setUser may only be called once with a non-null user for each
session and may be called with user set to null to invalidate the session.

That's all!
:o)

The mechanism consists of three parts:
1. providing two different ports for normal and privileged access
2. storing remote host information for new sessions (on initial requests)
3. checking subsequent requests against that

The principles behind that are:
- requests are only allowed on two pre-defined ports
  (normal/privileged channel)
- logged in sessions are allowed only via the privileged channel
  (usually https)
- sessions may always be switched from the normal to the privileged
  channel
- sessions that run on the privileged channel are not allowed to change
  back to the normal channel
- sessions may not replace their appended user
- requests with session information may not change the host IP
- requests with session information may not change the host name
- requests with session information may not change the user agent token
- any request with session information that violates one of the above rules
  will lead to an immediate invalidation of the appended session (and
  optionally to an error message within the response)

(Maybe the last point should be changed to prevent users from being
kicked off by attackers; maybe it suffices to store a "security violation"
flag in the session and spit out error messages with each subsequent
response).

These policies help to prevent the coarsest types of session-hijacking
attacks and ensure that privileged information does not leave the
web app through an unprivileged port.

Maybe user accounts should be enhanced by a security violation counter
and should be disabled after - say three or five - security violations; since 
this may lead to possible DoS attacks (deactivate user accounts with a number 
of session hijacking attackts) this is not implemented now.
Thoughts regarding that point are highly welcome.

In the default web app scenario the application server is accessed through a 
web server as an upstream proxy.

This has the following advantages:
- the application server does not need to cope with HTTPS / SSL stuff;
  doing this within the app server slows down things heavily (at least with
  tomcat) and induces some problems due to American export laws (JSSE).
- the application server receives some additional protection from the web
  server

The basic setup provides the two proxy ports
23080 (http)
23443 (https)

The apache configuration provides two virtual hosts (for port 80 and 443),
which forward incoming requests to these two ports on the local machine.
Requests between web server and application server always use HTTP,
such that the HTTPS server-side endpoint (with keys, certificates etc.), 
always remains on the web server (httpd).

If the application server (tomcat) runs on a different machine on a local
intranet, then the privileged line (23443) should be accessed through an
ssh tunnel to keep continue encryption chain for privileged access up to
the application server.

The application server (tomcat) should be set up such that connections are 
only allowed from localhost or web server machine respectively.

A living example for that is checked in at OCL / VulnXML.

This will soon be installed on the testbox too; you may then try out some 
attacks:

- create a session and tell your browser to send a different user agent
  string after that
- create a session and use it from a different IP address (e.g. within your
  intranet; or send it to a friend on a different dial up line)
- create a session and try to delete the "s" in https://
- try to access the application server directly through some illegal port
  (in most cases you have to install another / "default" connector e.g. on
   port 80)

Any thoughts, criticism and suggestions for improvement are highly welcome.

Kind regards

Ingo

-- 
ingo at ingostruck.de
Use PGP: http://ingostruck.de/ingostruck.gpg with fingerprint
C700 9951 E759 1594 0807  5BBF 8508 AF92 19AA 3D24




More information about the OWASP-Leaders mailing list