Well, if it's the spec I guess there's no much to argue. Maybe turn it into an option, but I already got the feeling of the community. I won't insist as this is my specific requirement and may not be of use to a wide range of the community.
Mark, there could be a MIM attack but that's yet another security issue. I guess you are missing my point. The way it's being discussed (point all security flaws), it's like we should also constraint the use of BASIC/DIGEST auth to be used only with CONFIDENTIAL transport, enforce CLIENT-CERT, etc. The point is not making the system all secure, is having the ability to CHOOSE what to secure (which Servlet/JSP spec already allows, I'm bringing to discussion just another degree). Actually this MIM attack is introduced by the workaround, I agree it would be better to specify the login page in the security constraints and that's actually the reason for this email. On Tue, Jun 21, 2011 at 1:25 PM, Mark Thomas <ma...@apache.org> wrote: > On 21/06/2011 17:05, Rafael Liu wrote: > > Hey Chris, > > > > as you said, each problem compromise different kinds of things: account > vs > > credentials. And I think they have different kind of consequences and can > > be, each one , dangerous its own way. I brought the discussion into the > list > > because I thought it was relevant. > > > > Looking at the code, a fix would be quite simple: replacing the forward() > by > > a send(). To have the same behaviour as today to the end user, a few more > > things should be done, because we would be changing from a POST to a GET, > > but AFAIK it's a matter of saving the target URL as a request parameter. > > Back button, bookmark and normal login should work. > > The spec requires that POST is used. > > > I agree it's kind of a philosophical question but I see some real > > implications. Anyway, for the record, as a quick and dirty fix I set the > > full URL with https schema in /form@action. But the hosting page isn't > HTTPS > > and the user may feel unsecure.. > > And rightly so. If the login page is not delivered over SSL that opens > the way for various MITM middle attacks. > > > On Tue, Jun 21, 2011 at 11:46 AM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Rafael, > > > > On 6/20/2011 8:12 PM, Rafael Liu wrote: > >>>> Good point Chuck. I agree with you, the webapp wouldn't be all > secured. > > But > >>>> there are 2 different things here: > >>>> > >>>> * the issue with the plain password > >>>> * the issue with session hijacking > > > > This does become somewhat of a philosophical question. I agree that > > credentials should always be secured. If the service itself is not > > particularly sensitive, I think it's acceptable to use SSL only during > > authentication. > > That is very much the minority view. I find it very hard to imagine any > scenario where a user needs to be authenticated (and hence the password > needs to be protected) but it is OK for the session to be compromised > without that being considered a security breach. > > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Rafael Liu +55 61 9608-7722 http://rafaelliu.net
