Re: preventing direct component access
Re: preventing direct component access
- Subject: Re: preventing direct component access
- From: Mike Schrag <email@hidden>
- Date: Mon, 09 Apr 2012 10:10:16 -0400
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@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden