Yeah, you're right ... might be kind of a pain in the butt to fix without hackery then :)
On Apr 9, 2012, at 3:41 PM, Patrick Robinson wrote: > But it doesn't even have to have the ".wo" on the end of the page name for > this hack to work. If the app has a "SecretPage.wo" component, then a URL > like this will instantiate and return it: > > https://myhost.mydomain/cgi-bin/WebObjects/MyApp.woa/wo/SecretPage//88.99 > > - Patrick > > > On Apr 9, 2012, at 10:10 AM, Mike Schrag wrote: > >> probably just catch any time you have a ".wo" in your URL and throw ... you >> could do it in the url rewriter or something. i don't think there's ever any >> reason to have a .wo reference in a normal app. >> >> ms >> >> On Apr 9, 2012, at 10:00 AM, Patrick Robinson wrote: >> >>> Yeah, that _does_ sound rather annoying! :-P >>> >>> Is there a perhaps less-annoying way to approximate similar behavior? >>> >>> >>> On Apr 5, 2012, at 2:46 PM, Mike Schrag wrote: >>> >>>> I changed this in WO core, and unfortunately it's kind of annoying to fix >>>> without some hackery, but in WOComponentRequestHandler, there's a static >>>> method requestHandlerValuesForRequest ... That dictionary has a key named >>>> "wopage" in it. If you did some class rewriting (with like gluonj or >>>> something), you could change that static method to remove the wopage key >>>> ... That MIGHT be enough to do it. >>>> >>>> On Apr 5, 2012, at 2:39 PM, Patrick Robinson wrote: >>>> >>>>> I've stumbled across a wrinkle re: what I had assumed to be the >>>>> conventional wisdom for preventing direct access to component pages via >>>>> URLs like the following: >>>>> >>>>> http://myhost.mydomain/cgi-bin/WebObjects/MyApp.woa/-9876/wo/SecretPage.wo >>>>> >>>>> It's an old, old WO problem, and I'm wondering what other people do to >>>>> handle it. >>>>> >>>>> I've always figured the best idea is to just configure the web server to >>>>> catch WO URLs that end in /wo/(.+)\.wo and rewrite or redirect them. >>>>> Another potential approach is to try to recognize and catch such requests >>>>> in the app itself, somewhere like the Application class's pageWithName. >>>>> The problem is, these solutions don't catch all the sneaky ways of >>>>> slipping in a back door. >>>>> >>>>> Consider: >>>>> >>>>> http://myhost.mydomain/cgi-bin/WebObjects/MyApp.woa/-9876/wo/SecretPage.wo//1.2 >>>>> >>>>> This ends up with Application's pageWithName trying to create a page with >>>>> the name "SecretPage". A new session has already been created somewhere >>>>> down inside the component request handler, it'll have a WOContext with a >>>>> contextID of 0, and the senderID will be 2. You'd be hard-pressed to >>>>> know that you shouldn't allow the page creation to proceed. >>>>> >>>>> You could try to change the web server's search pattern to also catch a >>>>> slash followed by more characters after the ".wo", but you'd have to be >>>>> careful not to disallow sessionIDs that just happen to end in "wo". And >>>>> even if you could reliably block the above, the hacker could try this: >>>>> >>>>> http://myhost.mydomain/cgi-bin/WebObjects/MyApp.woa/-9876/wo/SecretPage.wox//1.2 >>>>> (that is, add more characters after the ".wo") >>>>> >>>>> Now that doesn't fit the pattern at all, and gets hung up in the >>>>> Application's pageWithName, where a way-too-informative >>>>> WOPageNotFoundException is thrown. Of course, you'd catch that somewhere >>>>> like handleException(). Doesn't quite seem like the right approach, >>>>> either. >>>>> >>>>> My point here is, there are more ways of hacking a WebObjects URL than I >>>>> had previously considered. Does anyone have what they consider to be an >>>>> ironclad solution to this problem? >>>>> >>>>> (I hate it when I discover stuff I thought I had dealt with 10 years ago >>>>> is still biting me.) >>>>> >>>>> - Patrick >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
