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 <[email protected]> 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 <[email protected]> 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 < > <[email protected]>[email protected]>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> >> 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> >> 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 ( <[email protected]> >> [email protected]) >> >>> Help/Unsubscribe/Update your Subscription: >> >>> >> <http://lists.apple.com/mailman/options/webobjects-dev/george%40boxofficetickets.com> >> http://lists.apple.com/mailman/options/webobjects-dev/george%40boxofficetickets.com >> >>> >> >>> This email sent to <[email protected]> >> [email protected] >> >> >> > >> > _______________________________________________ >> > Do not post admin requests to the list. They will be ignored. >> > Webobjects-dev mailing list ( <[email protected]> >> [email protected]) >> > Help/Unsubscribe/Update your Subscription: >> > >> <http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com> >> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >> > >> > This email sent to <[email protected]>[email protected] >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ( <[email protected]> >> [email protected]) >> Help/Unsubscribe/Update your Subscription: >> <http://lists.apple.com/mailman/options/webobjects-dev/simon%40potwells.co.uk> >> http://lists.apple.com/mailman/options/webobjects-dev/simon%40potwells.co.uk >> >> This email sent to <[email protected]>[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/rgurley%40smarthealth.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]
