That looks like it may be an issue with ERXWOForm._appendHiddenFieldsToResponse instead of ERXRequest.
Do you have any other examples of where this can occur? Ramsey On Jul 12, 2011, at 12:32 PM, Simon wrote: > here you go, i just found a WO powered site on the web that will kindly > demonstrate the issue. it is sensitive to encoding, but this link should work > in chrome and firefox (not got any IE's nearby to test): > > https://secure.kagi.com/cgi-bin/WebObjects/PQ?wosid=3D%22%3E%3Cscript%3Ealert%281%29%3C/scri=pt%3E > > the issue is of course that rather than an alert, someone injects a > location.href= that points to a fake site that has an identical login page to > yours, and hence you customers unwittingly hand over your login details.... > > simon > > On 12 July 2011 18:27, Ramsey Gurley <rgur...@smarthealth.com> wrote: > I never understood that JIRA. How does the bad session ID get back into the > page? I would expect a session restoration error page if a bad session ID > were maliciously injected. > > Ramsey > > On Jul 12, 2011, at 6:51 AM, Mike Schrag wrote: > >> My recommendation is to only use cookie session ids and actually throw very >> early if you get a URL session id. >> >> Sent from my iPhone >> >> On Jul 12, 2011, at 3:36 AM, Simon <si...@potwells.co.uk> wrote: >> >>> i think core WO is still plagued with the wosid cross-scripting issue too. >>> we patch it in ERXRequest - not sure if the patch ever made it into wonder >>> though... >>> >>> simon >>> >>> >>> On 12 July 2011 02:43, Mike Schrag <msch...@pobox.com> wrote: >>> You have to be mindful of ever rendering any tainted strings ... Any string >>> that came from user input should be considered a risk for cross site >>> scripting, so that's any field editable by a user, or any query parameter, >>> etc. If you append those strings to response or <WOString> render them, >>> make sure to escape HTML or strip HTML. >>> >>> ms >>> >>> On Jul 11, 2011, at 9:41 PM, Mai Nguyen wrote: >>> >>> > Do you mean the issue of malicious HTML tags? >>> > >>> > I wonder what would be the best way to prevent those? >>> > >>> > thanks, >>> > >>> > mai >>> > >>> > >>> > On Jul 11, 2011, at 6:36 PM, George Domurot wrote: >>> > >>> >> If you output strings with escapeHTML=false, you could have an issue. >>> >> You may want to consider stripping all potential tags from strings prior >>> >> to rendering, or at the time of entry. >>> >> >>> >> -G >>> >> >>> >> On Jul 11, 2011, at 6:01 PM, Mai Nguyen wrote: >>> >> >>> >>> Hello, >>> >>> I have found some good information about WebObjects and security at the >>> >>> following wiki link: >>> >>> >>> >>> http://en.wikibooks.org/wiki/WebObjects/Web_Applications/Development/Authentication_and_Security >>> >>> >>> >>> However, there is no mention about SQL injections which seems to be an >>> >>> active subject lately. Is WebObjects pretty safe, as there is no need >>> >>> to generate SQL directly and access to the DB is going through the EOs >>> >>> normally? >>> >>> Are there any other loopholes that I am not aware of? >>> >>> About the following article: >>> >>> http://support.apple.com/kb/TA26730?viewlocale=en_US >>> >>> Would the normal WebObjects behavior be pretty safe if one does not >>> >>> allow the user to enter HTML tags? Does Project Wonder do something in >>> >>> this area? >>> >>> >>> >>> Many thanks for your advice, >>> >>> >>> >>> -mai _______________________________________________ >>> >>> Do not post admin requests to the list. They will be ignored. >>> >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> >>> Help/Unsubscribe/Update your Subscription: >>> >>> http://lists.apple.com/mailman/options/webobjects-dev/george%40boxofficetickets.com >>> >>> >>> >>> This email sent to geo...@boxofficetickets.com >>> >> >>> > >>> > _______________________________________________ >>> > Do not post admin requests to the list. They will be ignored. >>> > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> > Help/Unsubscribe/Update your Subscription: >>> > http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >>> > >>> > This email sent to msch...@pobox.com >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/simon%40potwells.co.uk >>> >>> This email sent to si...@potwells.co.uk >>> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com >> >> This email sent to rgur...@smarthealth.com > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
