Try this in your Application.java:
public WOComponent pageWithName(String pageName, WOContext context)
{
if((context.senderID()==null)&&(componentRequestHandlerKey().equals(context.request().requestHandlerKey())))
{
log.error("Direct Access attempt");
pageName="Main";
}
return super.pageWithName(pageName, context);
}
On 09/apr/2012, at 21:59, Mike Schrag wrote:
> 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/amedeomantica%40me.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]
