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

David Raphael david.raphael at ceterum.net
Tue Feb 4 19:00:00 EST 2003


I am answering Emails sequentially....


Comments below:

On Tuesday, February 4, 2003, at 10:59  AM, Ingo Struck wrote:

> 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.

I would love to chat with you about this Ingo!

> 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.

I am implementing this.  This should be committed soon.  The number of 
failed attempts
will be administrator configurable.

This will also include prevention of key-space based attacks 
(brute-force).

>
> 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
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld  Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> owasp-portal mailing list
> owasp-portal at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-portal
>
>





More information about the OWASP-Leaders mailing list