Re: Security and takeValuesFromRequest()
Re: Security and takeValuesFromRequest()
- Subject: Re: Security and takeValuesFromRequest()
- From: "Jerry W. Walker" <email@hidden>
- Date: Tue, 19 Apr 2005 01:03:45 -0400
Hi, Nathan,
I don't see how KVC could cause the problem you're concerned about so
long as you're using the WOComponentRequestHandler rather than the
WODirectActionRequestHandler.
Here is a listing of the request that comes back from the form on an
arbitrary WO page when the submit button is clicked by the user:
request
headers---------------------------------------------------------------
/cgi-bin/WebObjects/MyApplication.woa/wo/4.0.5.2.0.1
------------------------------------------------------------------------
------
> accept = */*
> accept-encoding = gzip, deflate;q=1.0, identity;q=0.5, *;q=0
> accept-language = en-us, ja;q=0.04, da-dk;q=0.91, da;q=0.87,
nl-nl;q=0.83, nl;q=0.78, fi-fi;q=0.74, fi;q=0.70, it-it;q=0.65,
it;q=0.61, ko-kr;q=0.57, ko;q=0.52, no-no;q=0.48, no;q=0.43,
pt-pt;q=0.39, pt;q=0.35, es;q=0.30, sv-se;q=0.26, sv;q=0.22
> connection = close
> content-length = 203
> content-type = application/x-www-form-urlencoded
> cookie = MyApplication=15806377011256593372361260051972; woinst=-1;
wosid=i7MiTXk6wlSzYIGtkmith0
> host = jwpismo.local:4444
> referer =
http://jwpismo.local:4444/cgi-bin/WebObjects/MyApplication.woa/wo/
2.0.5.3.1.0.4
> user-agent = Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us)
AppleWebKit/125.5.7 (KHTML, like Gecko) Safari/125.12
[2005-04-18 23:57:34 EDT] <WorkerThread1> <WOInputStreamData>: Reading
InputStream into byte data
content-----------------------------------------------------------------
------
0.5.2.0.1.1=apple+baker&0.5.2.0.1.3=0.5.2.0.1.3&0.5.2.0.1.7=charlie+delt
a&0.5.2.0.1.9=0.5.2.0.1.9&0.5.2.0.1.11=echo+foxtrot&0.5.2.0.1.13=0.5.2.0
.1.13&searchWholeWordsRadioButtons=true&0.5.2.0.1.19=Search
------------------------------------------------------------------------
------
Note that WO is using an HTTP POST rather than a GET, so the data in
the content section is not visible to the average user. However, I'm
sure you're not concerned about the average user, but are rather
concerned about the malicious hacker.
Even so, notice the means by which values are being returned to WO in
the request's content section, that is, the part from above that looks
like this:
content-----------------------------------------------------------------
------
0.5.2.0.1.1=apple+baker&0.5.2.0.1.3=0.5.2.0.1.3&0.5.2.0.1.7=charlie+delt
a&0.5.2.0.1.9=0.5.2.0.1.9&0.5.2.0.1.11=echo+foxtrot&0.5.2.0.1.13=0.5.2.0
.1.13&searchWholeWordsRadioButtons=true&0.5.2.0.1.19=Search
------------------------------------------------------------------------
------
Here are two of the values that are returned above:
0.5.2.0.1.1=apple+baker
0.5.2.0.1.7=charlie+delta
Although "apple+baker" and "charlie+delta" are values, the 0.5.2.0.1.1
and 0.5.2.0.1.7 are not the keys in KVC to which you were referring. To
describe what they are requires a little background.
WO builds a template when executing the AppendToResponse by parsing the
.html and the .wod files of the WOComponent(s). That template is
basically a depth first hierarchy of objects created by each of the
WOElements (WOComponents as subcompontents and WOActiveElements)
embedded in the WOComponent creating the Response. As the hierarchy is
built, each of the nodes of the hierarchy is numbered according to its
position in the hierarchy.
When the user clicks a button on a form to create a new request based
on the page of the last response, that request is sent to WO and a few
things happen. First, the URL of the response is examined. In the
response shown above, the response URL is:
/cgi-bin/WebObjects/MyApplication.woa/wo/4.0.5.2.0.1 (Note
that the "HTTP://"; and the domain are stripped off by the web adaptor)
Here, the WOSession ID is being carried in cookies, so is not found in
the URL as it would under default conditions. More normally, the URL
would look like this:
/cgi-bin/WebObjects/MyApplication.woa/wo/i7MiTXk6wlSzYIGtkmith0/
4.0.5.2.0.1
In this latter case, the "i7MiTXk6wlSzYIGtkmith0" is the session ID and
immediately follows the "/wo/" in the URL.
In either case, the WOSession ID is used to determine the session to
which this response should be routed by WO.
Next, the number immediately following the session ID and before the
first decimal point (the "4" in the above URL) is the contextID. This
number allows WO to determine to which request that you sent out (that
is, which page you sent out) this response correlates. Once WO knows
which session and which request, it also knows which WOComponent
created the request for this response and rebuilds the template.
As an aside, one of the pernicious bugs that often afflict new WO
developers is to allow some side effect of the AppendToResponse to
change the structure of the template before the following WORequest
returns. If that happens, WO rebuilds the template differently from
when the first Response went out and gets very confused as to which
values go with which form elements and which elements (buttons,
hyperlinks, etc.) caused the action that triggered the InvokeAction.
You can see the node numbers above in the printed request. Note the
first part of the content section that says "0.5.2.0.1.1=apple+baker".
That means that the value, "apple+baker", is being returned by the html
form element (node) whose HTML name (as assigned dynamically by WO
during the building of the template) is the number 0.5.2.0.1.1.
Nowhere in this data do the keys of key value coding appear. In fact,
if you've used a WOConditional to excise some fields from your HTML,
when the template is built for that response, those fields are not a
part of the template, so NONE of the numbers returned could possibly
refer to them in the follow up WORequest.
For a reasonably succinct description of this process, take a look at
the first three or four web pages that start here:
http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/
WebObjects_4.5/System/Documentation/Developer/WebObjects/DevGuide/
WOClasses19.html
These pages are WO4.5 documentation, but the process hasn't changed all
that much in the interim, and I couldn't quickly find comparable pages
for WO5.2.
The situation is not so straightforward with DirectAction logic, but I
don't think that was your question. There both keys and values can be
embedded in the URL and you have to be a bit more careful because they
can be spoofed under certain circumstances by a knowledgeable user. But
that's a subject for another time.
HTH.
Regards,
Jerry
On Apr 18, 2005, at 5:36 PM, Nathan Hampton wrote:
I have a situation where some users need to be able to change values
for only a sub-set of the keys in an EO, while others may change all
values. I did the usual thing -- putting the fields that require
higher privileges in a WOConditional -- but then realized that an HTTP
request could be created that would include values that the user
wasn't authorized to change. As a result, takeValuesFromRequest()
would make the changes, even though that user wasn't allowed to do so.
First of all, is this actually possible? If it is, how do I plug the
hole? (If it isn't, it's yet another way WO is just that cool.) My
immediate idea was to override takeValuesFromRequest() and use KVC to
ensure that the only changes in the request are changes the user is
allowed to make. Is there a better way to do this?
--NCH
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
--
__ Jerry W. Walker, Partner
C o d e F a b, LLC - "High Performance Industrial Strength Internet
Enabled Systems"
email@hidden
212 465 8484 X-102 office
212 465 9178 fax
_______________________________________________
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