You proposal is based on determination that the request is 'from the same
client'. What is your definition for a 'client' and how do you determine if
two requests are form the same client ?
Tal
> -----Original Message-----
> From: Scott Christley [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 17, 2001 10:54 AM
> To: [EMAIL PROTECTED]
> Subject: denial of service attack
>
>
>
> I must apologize first by saying that I originally found this bug with
> Jserv not Tomcat, but those of you who are familiar with Tomcat
> internals can probably tell fairly quickly if this would still be an
> issue.
>
> =====
> This bug deals with an out of memory condition within Jserv which is
> more a design/security issue. The scenario is that when a session is
> created by a servlet; memory is allocated by the JVM for that session
> and stays allocated until these two conditions occur 1) the servlet
> invalidates the session or the session timeout is reached which
> invalidates the session and 2) JVM garbage collection returns that
> allocated memory back to the heap.
>
> The reason this is a design/security issue is because any normal Java
> Servlet application can be used for a denial of service attack. The
> Java Servlet specification encourages applications to use sessions if
> they wish to maintain state. A hacker can easily discover if any
> application is a Java Servlet which uses sessions by checking to see if
> the JSESSIONID cookie is defined; if the hacker finds one then a simple
> program can be used to increase the memory usage on the server and crash
> the JVM.
>
> while (server is still up)
> send an HTTP request to the servlet URL which creates the session
>
> The timeout variable and the maximum java heap size are the only two
> ways that the application can attempt to avoid this attack; by setting a
> short timeout and a large heap size, one can hope that there is a
> sufficient span to handle all of the requests (i.e. the timeout kicks in
> before the memory has max'ed out). But there are problems with this:
>
> * Set a timeout too short and normal users get their session invalidated
> before they are able to complete normal usage of the application.
> * Java heap size reserves memory which cannot be swapped out (on solaris
> at least), so a large heap size puts a strain on the server's memory.
> * The hacker can always deploy additional clients to generate more
> concurrent requests.
> =====
>
> I have been writing stress tests for Jserv, Tomcat, and our own servlet
> engine; when I brought this issue up with the developers here, I
> essentially got my hand slapped (*sigh*) and told "application
> developers must deal with this, it is not the servlet engines
> responsibility". Which I think is a highly unfortunate answer because
> HttpSession is a core servlet API and telling developers that they
> cannot use it and should use an alternate mechansim, just seems wrong to
> me. So, I figured I would post a message to this list for discussion.
>
> I did have an idea for how this issue can be resolved; I've not totally
> thought it through, but it may be a good start.
>
> =====
> Given a parameter (num_of_sessions) which is the maximum number of new
> sessions.
> Given a parameter (time_period) which is a time interval.
>
> Implement a verification such that maximum number of new sessions that
> can be created from the same client within a time interval. This would
> require that you maintain a creation date and client identifier with
> each session.
>
> if (creating a new session)
> {
> session_count = 0
> Loop through set of sessions for that client
> {
> /* Was this session created within the time period */
> if ((current_date - creation_date_of_session) > time_period)
> ++session_count;
> }
> if ((session_count + 1) > num_of_sessions)
> /* Good possibility we are being attacked */
> else
> /* create the new session */
> }
> =====
>
> Presumably default values could be given to the num_of_session and
> time_period parameters which still allow the problem user (somebody
> opening up multiple browser windows, stoppng/starting browser, etc) to
> gain access to the application, yet small enough to prevent the JVM from
> consuming large amounts of memory before the attack is discovered. Once
> an attack is discovered, the servlet engine could be proactive and
> delete all of the sessions created by the client to free up the memory,
> log messages, etc.
>
> cheers
> Scott
>
> /* Thankfully Oracle doesn't speak for me, nor vice-versa */
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
