Check out http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
They have a very good Java based implementation of security code that you can integrate with your java based project to help you sanitize your user/externally provided data. It is not sufficient to check for <script> tags in your incoming data. There is a lot of other things that can cause cross site scripting, SQL injection, cross request forging, etc issues. The best approach is to provide a white list validation of every incoming parameter and check to see if the param matches expected range of values. Anything else is considered dangerous. The ESAPI framework has a very good white list param implementation. There are also methods for sanitizing XML, DB calls, request headers, javascript, LDAP calls, etc. The OWASP Top Ten list http://www.owasp.org/index.php/Top_Ten is a recognized list of top vulnerabilities that various penetration testing tools generate compliance reports against. Good Luck Dov Rosenberg On 7/22/10 4:04 PM, "Lachlan Deck" <[email protected]> wrote: > On 22/07/2010, at 9:28 PM, Patrick Middleton wrote: > >> Some of our customers are commissioning penetration testing reports, which >> are flagging vulnerabilities in our WebObjects applications. The problem >> reported is with URLs such as >> .../wa/MyDirectAction?wosid=XYZ%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3 >> E , direct actions that preserve the session ID, where the session ID can be >> manipulated (at the cost of no longer being a valid session ID) to enable >> injecting some executable JavaScript onto a webpage. In principle this is a >> vulnerability for various attacks such as XSS, SQL injection and so on. In >> practice, I'm confident there are no exploits in the apps for which I am >> responsible because any useful work is done via component actions; no valid >> session ID equals nothing useful served, and a valid session ID means you can >> get at what the app is supposed to let you be able to get at. >> >> But I'd like to tighten things up so that the penetration testing automated >> scanners find nothing because there's nothing to find. > > In addition to what Anjo's already said, have you considered storing your > wosids in cookies so they're not in the url at all? > >> I myself am still (don't laugh) working with WO4.5.1. > > Java or Objective-C? > >> What are things like in 5.4.x? > > 4.5.x was before my time with WO, so can't compare. 53/54 are certainly more > popular... > >> It seems to me that I ought to subclassing (or adding to existing subclasses) >> to override these: >> >> com.webobjects.appserver.WODirectAction >> public String getSessionIDForRequest(WORequest aRequest) >> public void takeFormValueArraysForKeyArray(NSArray aKeyArray) >> public void takeFormValuesForKeyArray(NSArray aKeyArray) >> public void takeValueForKey(Object value, String key) >> >> com.webobjects.appserver.WOComponent >> public void takeValuesFromRequest(WORequest aRequest, WOContext aContext) >> public void takeValueForKey(Object value, String key) >> >> in order to sanitize inputs -- mostly by removing anything containing the >> likes of '<script'. What do you think? > > How about just app.dispatchRequest and if any bogus input is provided return > pageNotFound. > > with regards, > -- > > Lachlan Deck > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/drosenberg%40inquira.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
