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 (Webobjects-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
