struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <paul4chris...@yahoo.com>
Subject Re: Validation Security Hole?
Date Fri, 27 Jan 2006 13:50:33 GMT
>> I very much dislike changing the default behavior within a minor release or a milestone.
But,
if we can restrain the changes to the configuration, I suppose we could live with it. 

Ted, perhaps you need to think about this more :) Unless there are plans to come up with a
different solution for 1.3/1.4, I don't want to put into Struts a solution that you're going
to
immediately rip out for a better approach. And I don't say that because I put time into the
patch... ;-) but because it will create anguish for developers, and who wants to buy into
a
solution you're virtually about to toss away?

If the set-property is the way to go, let's do it. And if you want it into the DTD instead,
we can
do that too. It's just modifying the DTD. +1/-1 for the DTD?

>> In any case, we should not just ignore the cancel token. If the token is present,
and
Cancellable is not set, then we should log the error and throw an exception so that the developer
knows the contract is not being observed (or that the website is being spoofed).

IMO, bad idea. What if you don't want to handle the cancel at all? That's how this whole thread
started. The notion of canceling is semantically nonsensical for most actions that back a
GET
request (view airline ticket, view any item, etc.) The problem is not that the token is an
intrinsic evil, but that the token is not always necessary. So you pass in a token of the
CANCEL
button and you're not handling it -- big deal. Whose to say that's incorrect behavior? It's
only
incorrect if the action is supposed to handle it but is not, and you need a requirements document
for that ;-)

It is my understanding that Exceptions are heavy-lifting, relatively speaking, compared to
a
normal non-exception execution path. Don't you think, devilishly speaking, it would be a great
idea to write a loop that passes in the CANCEL token knowing the server will generate an exception
every time? Unless I am overly scrupulous, I'd say that lays the foundation of a DoS attack,
eating up alot of CPU to churn exceptions.

Paul

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message