Wow, that's great, Amedeo! I hadn't paid much attention to that little corner of Project Wonder before. What is it that forces the patched PW version of that class to be loaded rather than the original WO version?
On Apr 10, 2012, at 1:31 PM, Amedeo Mantica wrote: > I have patched WOComponentRequestHandler and created a pull request in the > wonder/integration branch > > then you will set the property: > > ERXDirectComponentAccessAllowed=false > > Amedeo > > On 10/apr/2012, at 15:14, Patrick Robinson wrote: > >> I'm pretty sure this "feature" is the only mechanism by which a user can >> request a specific page (or component) by name. I would want to block >> arbitrary access to pages as well as prevent spurious session creation. >> >> But yes, there are ways to mitigate the effects. If an authenticated "user" >> is stored in the Session, then you can check for that before performing an >> action in invokeAction() or returning a response in appendToResponse(). And >> you *do* have to worry about invokeAction(), by the way: the presence of a >> senderID in the URL causes the component action handler to initiate the >> invokeAction phase. I suppose sessions with no authenticated user could >> even be terminated at the same time. >> >> No end to the fun! >> >> - Patrick >> >> On Apr 10, 2012, at 2:43 AM, Cheong Hee (Gmail) wrote: >> >>> Hi Patrick >>> >>> The rationale I am asking is the way web technology is, I think we may not >>> be able to block the arbitrary access of web pages. However, if we could >>> use user authentication as a way to check, terminate the unwanted sessions >>> and redirect to another stateless page, the impacts could be reduced. >>> Correct me if wrong.. >>> >>> Cheers >>> >>> Cheong Hee >>> >>> ----- Original Message ----- From: "Cheong Hee (Gmail)" <[email protected]> >>> To: "Patrick Robinson" <[email protected]> >>> Cc: "WebObjects-Dev Mailing List" <[email protected]> >>> Sent: Tuesday, April 10, 2012 12:53 PM >>> Subject: Re: preventing direct component access >>> >>> >>>> Hi Patrick >>>> >>>> This is an interesting old issue. Just curious, what will be your >>>> ultimate ideal resolution to this? Bar the access of the page, or reduce >>>> the redundant sessions creation or something else ... >>>> >>>> Cheers >>>> >>>> Cheong Hee >>>> >>>> ----- Original Message ----- From: "Patrick Robinson" <[email protected]> >>>> To: "Amedeo Mantica" <[email protected]> >>>> Cc: "WebObjects-Dev Mailing List" <[email protected]> >>>> Sent: Tuesday, April 10, 2012 4:52 AM >>>> Subject: Re: preventing direct component access >>>> >>>> >>>>> 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/chng34%40gmail.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]
