Like you, that's what I thought initially, until the security scanning application report hit me.
For each simulated attack (including null-characters and other characters) our *.do URLs were showing errors and exceptions in all their full glory right on the web page. That was the basis for my initial comment about making sure your JSPs paint clean even for bad data -- not that our apps used JSPs in the URL. Even one single obscure such 'failure' meant the application was not going out. I am getting the very latest Struts binaries to see what I can take out from my own code. For the third time in a day I am saying this : (The whole webapp was quite an eye opener to me) I am disappointed that I had to be the first one discussing this PUBLICLY (I am not that lucky or capable to be the first to do it). And what I liked about my SafeValidatorForm was this :- once the form's values get past it, I am in la-la-land. And so were the other developers in the entire team whose capabilities range from you-know-where to a full 10. Its gatekeeping was something like the java security policy checks , no code changes -- if I am allowed to stretch things a bit in my favor. Maybe its my style, but I prefer hooks and filters, rather than enhanced capabilities. And with that single class, I reduced the scanning report down to one heavenly page for all the applications. Ok. (Truthfully ;-), to get down to one page, we replaced <!-- with <%-- and also took out javascript validation that Struts does provide :-( -- these scanners think any javascript is a potential problem ). -----Original Message----- From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich Sent: Wednesday, November 03, 2004 4:31 PM To: [EMAIL PROTECTED] Subject: Re: hacker-proofing Struts-based exposed websites There are known hacks, some dealing with buffer overruns of the server that gives you acess to the OS shell, or port scans or sniffing, or ... So I see you have apache 1.3 (with it's known hacks) in front of it. I assume you read up on securing apache. I think very little has to do w/ Struts itself, unless you can crash the application remotely or disptach commands that give you something. .V Bill Chmura wrote: > I can't really speak to the actual code or process itself as I have not worked > with struts in a little while - but anytime something is labled as "hacker > proof" it kind of sticks under my nail. > > Maybe its more aptly "securing validation", but I cannot imagine that this > would "hacker proof your struts application" > > In anycase, its noble to share and try to improve the community - kudos > > > On Wednesday 03 November 2004 10:42 am, Seetamraju, Uday wrote: > >>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 >> >> >> >>-------------------------------------------------------- >>The information contained in this message is intended only for the >>recipient, and may be a confidential attorney-client communication or may >>otherwise be privileged and confidential and protected from disclosure. If >>the reader of this message is not the intended recipient, or an employee or >>agent responsible for delivering this message to the intended recipient, >>please be aware that any dissemination or copying of this communication is >>strictly prohibited. If you have received this communication in error, >>please immediately notify us by replying to the message and deleting it >>from your computer. >> >>Thank you, >> >>Standard & Poor's >> >>-------------------------------------------------------- > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
