We are putting some websites open to all IP addresses using Appservers. We have successfully stayed well within JSTL and Struts.
My google searches didn't get me to any open information on how to use struts in a safe manner. So, I had to start inventing the wheel. I hope I didn't spend this much effort to 'reinvent'.
Our struts-based web-applications here, have survived hack-vulnerability tools that the company uses. I was the only one involved in the development side to get the "secure" stamp of approval for these web-applications.
I ended up creating a new struts-contrib based on this experience. I am sending this email, since, after a few trials, I feel that I have a reasonably simple approach to make the individual URLs/Actions pass the typical secure-web-site tests.
I thought maybe I could get feedback to improve my code, and as well let others benefit.
----------------------------------------
The basic motivation : There should be very little changes to struts applications to make them hacker-proof. Also, this shouldn't change the way people design struts applications.
There are java.security.policy issues that are orthogonal to this email, that I am not including in here.
The entire details are in one nice HTML web page that I wrote up just for this. http://mysite.verizon.net/sarma/GNU/SafeValidatorForm.html
Thanks.
Udaybhaskar Sarma Seetamraju
Maybe I should wait for other commentary on this because I'm probably missing something...but after scanning your page for a bit, I'm not getting it...I don't see what this adds to the built in struts validators, especially required and maxlength. (Or alternatively, I don't see why it is better than them.)
There is the invalid string checker, but one could be added as a custom validator pretty easily (and be more flexible I think, checking for any set of characters a user wants instead of just character 0 and the html code delimiters.)
Can you maybe expand (here or in the text of your document) on the advantages over the built in validations? How is this better for security than just making a field required,maxlength,invalidCharacter in the validator framework?
(note: invaildCharacter is obviously a bogus implementation of what I was talking about above...)
Thanks, Matt
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
