Re: preventing direct component access
Re: preventing direct component access
- Subject: Re: preventing direct component access
- From: "Cheong Hee (Gmail)" <email@hidden>
- Date: Tue, 10 Apr 2012 12:53:40 +0800
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@hidden>
To: "Amedeo Mantica" <email@hidden>
Cc: "WebObjects-Dev Mailing List" <email@hidden>
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden