tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Filters don't affect request dispatcher forward
Date Tue, 03 Dec 2002 17:20:58 GMT


On 3 Dec 2002, Alexander Wallace wrote:

> Date: 03 Dec 2002 10:21:19 -0600
> From: Alexander Wallace <tomcater@rwsoft-online.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> Subject: Re: Filters don't affect request dispatcher forward
>
> Hey I love that! Thanks, let me try it!
>
> Now, with this solution, I figure i can't fore stuff that doesn't match
> the "to be secured" pattern to go over http and not https if it is
> requested, right? I still can live with that, but it would sure be
> cool..
>

I'm not sure what you're really asking, but ...

If you declare a security constraint with a transport guarantee, any URL
that matches the specified pattern(s) can *only* be accessed via SSL.  Any
URL that does not match the pattern can be accessed over *either* SSL or
non-SSL.

One additional note -- web applications that allow a user to switch from
SSL back to non-SSL on the same session are broken.  What you've just done
is allowed anyone snooping the network to swipe the session id and
impersonate your user (for example, click the "buy" button again using the
credit card number that was entered on a secure page).

You should program your apps that, once a user switches from non-SSL to
SSL, you never again accept a non-SSL request for that same session id.
If the user needs to go back (for example, after checking out of an
ecommerce site you want to buy some more stuff), start a new session first
(and clear the confidential data you might have captured).

> Thanks!

Craig


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message