Commented already https://github.com/projectwonder/wonder/pull/150
On Apr 10, 2012, at 10:33 AM, Pascal Robert wrote: > > Le 2012-04-10 à 13:29, Amedeo Mantica a écrit : > >> I have patched WOComponentRequestHandler and created a pull request in the >> wonder/integration branch >> >> then you will set the property: >> >> ERXDirectComponentAccessAllowed=false > > If someone wants to review it: > > https://github.com/projectwonder/wonder/pull/150/files > >> 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/rgurley%40smarthealth.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]
