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)" <chn...@gmail.com> >>> To: "Patrick Robinson" <p...@vt.edu> >>> Cc: "WebObjects-Dev Mailing List" <webobjects-dev@lists.apple.com> >>> 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" <p...@vt.edu> >>>> To: "Amedeo Mantica" <amedeomant...@me.com> >>>> Cc: "WebObjects-Dev Mailing List" <webobjects-dev@lists.apple.com> >>>> 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 (Webobjects-dev@lists.apple.com) >>>>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >>>>>>>>>>>> >>>>>>>>>>>> This email sent to msch...@pobox.com >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/amedeomantica%40me.com >>>>>>> >>>>>>> This email sent to amedeomant...@me.com >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/webobjects-dev/chng34%40gmail.com >>>>> >>>>> This email sent to chn...@gmail.com >>>>> >>> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/amedeomantica%40me.com >> >> This email sent to amedeomant...@me.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
