Frank W. Zammetti wrote:
Now, imagine a hacker wants to get to a completely different table in the database (I suppose reading from a selected table would be a better example, but I digress). To do so, they can pass in the canceled parameter and whatever table name they want, assuming they can mangle the URL properly and establish a session first. Since Struts will populate the form and fire the Action *without* calling validate() in this case, the hacker has the "in" they want.
Maybe I'm missing how the above would happen. How would passing in the canceled parameter end up getting them access to a table? Oh wait, maybe this is with regular Actions with just an execute? It's been so long since I used a non Dispatch Action I'm not aware of the behavior. So I have an Action called "GetMeATable" with an execute method that returns a table from the db, if I pass in through a get parameter the canceled param it will still execute that action?
Even if the above is true, I'm not so sure that's a big deal as far as Struts goes in regard to it being a 'security problem with Struts'. You can always find a ton of security loop holes if you don't truly check that the logged in user has access to some backend procedure. For example if you have an update dispatch method or an "UpdateAction" you could easily type in the url someUrl?dispath=update&id=42&whatever=something etc and have it go through and be processed.
Bottom line is if security is an issue, no one should ever rely on the validate method. That's just silly. I'm sure the docs even state that the purpose of the validate method is to just validate data entry (required fields, no Strings in number fields, etc.).
Because the validate method was skipped when canceled was called and someone could put that into an URL and still maybe have the execute method called (which I'm not sure that's what happens anyway), is the least of Strut's problems:)
Like I said, I'm describing a scenario that would probably not happen too often, and certainly not by anyone with half a brain :) But that's the basic mechanism in a nutshell... now imagine how many innocent and less obvious ways to screw up that would be exploitable there may be :)
Yea there are plenty. I remember someone on the list here a while back came up with this pretty cool scheme to mask dispatch action method names. It was pretty cool even though I never needed it. If I remember correctly, it acted sort of like the token mechanism - a random string was created before going to a page and that string was decoded on the server side into finding the proper dispatch method to call. To me it's just much simpler to make sure you validate the user logged in really can do what they are attempting to do somewhere on the server side or with filters.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
