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]
