Yes, true
I didn't noticed. Is very bad
Amedeo
On 09/apr/2012, at 22:52, Patrick Robinson wrote:
> That code represents the per-app version of the "conventional wisdom" that I
> started out questioning, below. The problem with this is that the user can
> specifiy a "senderID" (as in the URL I gave there), and then senderID() will
> *not* return null; in the case below, it'll be "99".
>
>
> On Apr 9, 2012, at 4:48 PM, Amedeo Mantica wrote:
>
>> 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]
