You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Arron Bates <ar...@keyboardmonkey.com> on 2001/11/28 02:45:39 UTC
Re: Extensibility of struts & Property Security
Yes, yes. Point made.
That series of emails makes for some good bedside reading.
I think that the solution that was arrived at is fine for protecting the
struts system objects themselves.
Is there anything happening to allow the developer to protect their own
properties from this kind of arbitrary attack?
Thought I had would be to configure a property modifier, or property
mapping which yields other "security properties" which have to be
checked before a property is set. ie: getMyProperty() property method
uses a getMyPropertySecurity() to return a defined value which was set
while writing the view so you can't just pass the one key value pair to
change a value, but a two key value pairs with the second value being a
specific hashing or such. This would stop the casual hacking of any
property via the URL. You could also then define a security property for
all things struts within the ActionForm.
The possibility then in extending this would be to define a security
property to each property to be set, or a more simpler global security
property for the entire request, and let the developer decide as to how
fine grained the property setting security should be, if at all.
Just a thought.
Arron.
Ted Husted wrote:
>http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=813
>
>"So, someone could also call
>
>getServlet().setTempDir(whatever)
>
>with
>
>http://whatever.com/do/someAction?servlet.tempdir=whatever
>
>Hmmm."
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Custom Software ~ Technical Services.
>-- Tel +1 716 737-3463
>-- http://www.husted.com/struts/
>
>
>Arron Bates wrote:
>
>>It doesn't even have to be a careful look at the code. It's not complex
>>in the least.
>>
>>I must be missing something with the "String or boolean properties that
>>affect the system state" thing.
>>
>>Do you mean what it is that I do with the example, where I have a string
>>property that represents a submit button that add objects to the tree
>>and another that can delete them?... If it isn't, can I get an example?...
>>
>>Arron.
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Extensibility of struts & Property Security
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Arron,
Ideas... Great.
I think that source code samples can be more useful than abstract
ideas in free style. Every developer in this list has his own work and
doing struts-related activity by his free time.
If you can help in this way to the community, please post code and
config samples to the list.
Wednesday, November 28, 2001, 5:22:45 PM, you wrote:
A> No code, just an idea after Ted provided a link to a thread of mails
A> that had to do with the original problem of getting at the struts system
A> objects.
A> But I'm lookin into it.
A> I'll get back to ya, but should be able to get a mock set-up running of
A> the idea itself...
A> ...then the debate can start as to the syntax of configuring it, and
A> when, should it be a singleton, ad-infinitum. :)
A> Arron
A> Oleg V Alexeev wrote:
>>Hello Arron,
>>
>>I think that it is intersting and flexible approach. Can you supply
>>samples for it or refactor existing code to support such ideas?
>>
>>Wednesday, November 28, 2001, 6:37:06 AM, you wrote:
>>
>>AB> Not a special class, I'm talking about placing it into the process.
>>AB> Before the servlet updates the properties it checks for a security
>>AB> mapping. Based on the request and the security, it updates the
>>AB> properties. It would be more secure, and every property which is up to
>>AB> be set, can rest assured that it's safe. And that includes the
>>AB> properties that we "mean to expose" nested or otherwise.
>>
>>AB> All amounting to better security and an easier development path for the
>>AB> developers.
>>AB> I've had to use a decoupling through nested objects for an app that's in
>>AB> development. 100's of input fields. Writing proxy classes for it all.
>>AB> You have to be kidding.
>>
>>AB> Ted, there are some requirements out there where you *must* use nested
>>AB> objects.
>>AB> When is Struts going to *properly* support this!!??...
>>
>>
>>AB> Arron.
>>
>>AB> Ted Husted wrote:
>>
>>>>Personally, I have the feeling that it's better to encourage people to
>>>>define a proxy object, or wrapper, as was done with the ActionServlet,
>>>>than invent a special class for people to learn.
>>>>
>>>>I actually believe that this is the approach that should have been used
>>>>in the first place, and in other places in the codebase. The
>>>>ActionServlet was placed there to provide access to certain properties,
>>>>and now the wrapper object defines exactly which properties those are.
>>>>An Encapsulate Class refactoring, if you will.
>>>>
>>>>Meanwhile, I'm suggesting that we do the same sort of thing with
>>>>multiple ActionSerlvets in another thread. Instead of exposing the
>>>>ActionServlet, we should expose a JavaBean with only the properites we
>>>>mean to expose.
>>>>
>>>>I think the important thing is to pound on the point that the ActionForm
>>>>is a firewall; it, and any objects it nests, are in the wild.
>>>>
>>>>Arron Bates wrote:
>>>>
>>>>> Yes, yes. Point made.
>>>>>That series of emails makes for some good bedside reading.
>>>>>
>>>>>I think that the solution that was arrived at is fine for protecting the
>>>>>struts system objects themselves.
>>>>>Is there anything happening to allow the developer to protect their own
>>>>>properties from this kind of arbitrary attack?
>>>>>
>>>>>Thought I had would be to configure a property modifier, or property
>>>>>mapping which yields other "security properties" which have to be
>>>>>checked before a property is set. ie: getMyProperty() property method
>>>>>uses a getMyPropertySecurity() to return a defined value which was set
>>>>>while writing the view so you can't just pass the one key value pair to
>>>>>change a value, but a two key value pairs with the second value being a
>>>>>specific hashing or such. This would stop the casual hacking of any
>>>>>property via the URL. You could also then define a security property for
>>>>>all things struts within the ActionForm.
>>>>>
>>>>>The possibility then in extending this would be to define a security
>>>>>property to each property to be set, or a more simpler global security
>>>>>property for the entire request, and let the developer decide as to how
>>>>>fine grained the property setting security should be, if at all.
>>>>>
>>>>>Just a thought.
>>>>>
>>>>>Arron.
>>>>>
>>>>--
>>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>>
>>
>>
>>
>>AB> --
>>AB> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>AB> For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
A> --
A> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
A> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron <ar...@keyboardmonkey.com>.
No code, just an idea after Ted provided a link to a thread of mails
that had to do with the original problem of getting at the struts system
objects.
But I'm lookin into it.
I'll get back to ya, but should be able to get a mock set-up running of
the idea itself...
...then the debate can start as to the syntax of configuring it, and
when, should it be a singleton, ad-infinitum. :)
Arron
Oleg V Alexeev wrote:
>Hello Arron,
>
>I think that it is intersting and flexible approach. Can you supply
>samples for it or refactor existing code to support such ideas?
>
>Wednesday, November 28, 2001, 6:37:06 AM, you wrote:
>
>AB> Not a special class, I'm talking about placing it into the process.
>AB> Before the servlet updates the properties it checks for a security
>AB> mapping. Based on the request and the security, it updates the
>AB> properties. It would be more secure, and every property which is up to
>AB> be set, can rest assured that it's safe. And that includes the
>AB> properties that we "mean to expose" nested or otherwise.
>
>AB> All amounting to better security and an easier development path for the
>AB> developers.
>AB> I've had to use a decoupling through nested objects for an app that's in
>AB> development. 100's of input fields. Writing proxy classes for it all.
>AB> You have to be kidding.
>
>AB> Ted, there are some requirements out there where you *must* use nested
>AB> objects.
>AB> When is Struts going to *properly* support this!!??...
>
>
>AB> Arron.
>
>AB> Ted Husted wrote:
>
>>>Personally, I have the feeling that it's better to encourage people to
>>>define a proxy object, or wrapper, as was done with the ActionServlet,
>>>than invent a special class for people to learn.
>>>
>>>I actually believe that this is the approach that should have been used
>>>in the first place, and in other places in the codebase. The
>>>ActionServlet was placed there to provide access to certain properties,
>>>and now the wrapper object defines exactly which properties those are.
>>>An Encapsulate Class refactoring, if you will.
>>>
>>>Meanwhile, I'm suggesting that we do the same sort of thing with
>>>multiple ActionSerlvets in another thread. Instead of exposing the
>>>ActionServlet, we should expose a JavaBean with only the properites we
>>>mean to expose.
>>>
>>>I think the important thing is to pound on the point that the ActionForm
>>>is a firewall; it, and any objects it nests, are in the wild.
>>>
>>>Arron Bates wrote:
>>>
>>>> Yes, yes. Point made.
>>>>That series of emails makes for some good bedside reading.
>>>>
>>>>I think that the solution that was arrived at is fine for protecting the
>>>>struts system objects themselves.
>>>>Is there anything happening to allow the developer to protect their own
>>>>properties from this kind of arbitrary attack?
>>>>
>>>>Thought I had would be to configure a property modifier, or property
>>>>mapping which yields other "security properties" which have to be
>>>>checked before a property is set. ie: getMyProperty() property method
>>>>uses a getMyPropertySecurity() to return a defined value which was set
>>>>while writing the view so you can't just pass the one key value pair to
>>>>change a value, but a two key value pairs with the second value being a
>>>>specific hashing or such. This would stop the casual hacking of any
>>>>property via the URL. You could also then define a security property for
>>>>all things struts within the ActionForm.
>>>>
>>>>The possibility then in extending this would be to define a security
>>>>property to each property to be set, or a more simpler global security
>>>>property for the entire request, and let the developer decide as to how
>>>>fine grained the property setting security should be, if at all.
>>>>
>>>>Just a thought.
>>>>
>>>>Arron.
>>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>
>
>
>
>AB> --
>AB> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>AB> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Extensibility of struts & Property Security
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Arron,
I think that it is intersting and flexible approach. Can you supply
samples for it or refactor existing code to support such ideas?
Wednesday, November 28, 2001, 6:37:06 AM, you wrote:
AB> Not a special class, I'm talking about placing it into the process.
AB> Before the servlet updates the properties it checks for a security
AB> mapping. Based on the request and the security, it updates the
AB> properties. It would be more secure, and every property which is up to
AB> be set, can rest assured that it's safe. And that includes the
AB> properties that we "mean to expose" nested or otherwise.
AB> All amounting to better security and an easier development path for the
AB> developers.
AB> I've had to use a decoupling through nested objects for an app that's in
AB> development. 100's of input fields. Writing proxy classes for it all.
AB> You have to be kidding.
AB> Ted, there are some requirements out there where you *must* use nested
AB> objects.
AB> When is Struts going to *properly* support this!!??...
AB> Arron.
AB> Ted Husted wrote:
>>Personally, I have the feeling that it's better to encourage people to
>>define a proxy object, or wrapper, as was done with the ActionServlet,
>>than invent a special class for people to learn.
>>
>>I actually believe that this is the approach that should have been used
>>in the first place, and in other places in the codebase. The
>>ActionServlet was placed there to provide access to certain properties,
>>and now the wrapper object defines exactly which properties those are.
>>An Encapsulate Class refactoring, if you will.
>>
>>Meanwhile, I'm suggesting that we do the same sort of thing with
>>multiple ActionSerlvets in another thread. Instead of exposing the
>>ActionServlet, we should expose a JavaBean with only the properites we
>>mean to expose.
>>
>>I think the important thing is to pound on the point that the ActionForm
>>is a firewall; it, and any objects it nests, are in the wild.
>>
>>Arron Bates wrote:
>>
>>> Yes, yes. Point made.
>>>That series of emails makes for some good bedside reading.
>>>
>>>I think that the solution that was arrived at is fine for protecting the
>>>struts system objects themselves.
>>>Is there anything happening to allow the developer to protect their own
>>>properties from this kind of arbitrary attack?
>>>
>>>Thought I had would be to configure a property modifier, or property
>>>mapping which yields other "security properties" which have to be
>>>checked before a property is set. ie: getMyProperty() property method
>>>uses a getMyPropertySecurity() to return a defined value which was set
>>>while writing the view so you can't just pass the one key value pair to
>>>change a value, but a two key value pairs with the second value being a
>>>specific hashing or such. This would stop the casual hacking of any
>>>property via the URL. You could also then define a security property for
>>>all things struts within the ActionForm.
>>>
>>>The possibility then in extending this would be to define a security
>>>property to each property to be set, or a more simpler global security
>>>property for the entire request, and let the developer decide as to how
>>>fine grained the property setting security should be, if at all.
>>>
>>>Just a thought.
>>>
>>>Arron.
>>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
AB> --
AB> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
AB> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Ted Husted <hu...@apache.org>.
Arron wrote:
> How does the current buffering mechanism do its thing for flat beans?...
> Is there a short answer without telling me to go read the code?... :)
The ActionForms ~are~ the buffering mechanism. That's one reason why
they are not an interface. They should not be tied directly to a model,
but serve as a pessimistic firewall betweeen the untrusted presentation
layer (HTTP/HTML), and the rest of your application, which can then be
more optimistic about the quality of data passed between components.
What's happened is that when we added the nesting feature (late in the
1.0 cycle), we opened a backdoor that can realize some of the same
problems caused when ActionForm was an interface. Someone can nest a
bean that is tied directly to the model, and a hostile user can make
unchecked system state changes.
But, so long as the beans you nest do not update the system state (as
the ActionServlet bean did), then there is nothing to worry about. A
value object, for example, would generally be OK, since they accept data
at one point, and then commit it at another. Between the accept and
commit points, you can validate the input. But the ActionServlet exposed
a direct setter, which is a bad thing on an ActionForm. So, we in
affect, we wrapped it in a value object, so unauthorized system state
changes could not be made.
Nesting beans on an ActionForm is a powerful tool, but with power comes
responsibility.
The one and only danger is nesting a bean that makes direct changes to
the system state via a public property which accepts a single String or
boolean parameter. Protected or private properties or properties with
complex signatures or types will not make it past the autopopulation
guantlet.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
> Arron.
>
> >
> >
> >Arron Bates wrote:
> >
> >>Not a special class, I'm talking about placing it into the process.
> >>Before the servlet updates the properties it checks for a security
> >>mapping. Based on the request and the security, it updates the
> >>properties. It would be more secure, and every property which is up to
> >>be set, can rest assured that it's safe. And that includes the
> >>properties that we "mean to expose" nested or otherwise.
> >>
> >>All amounting to better security and an easier development path for the
> >>developers.
> >>I've had to use a decoupling through nested objects for an app that's in
> >>development. 100's of input fields. Writing proxy classes for it all.
> >>You have to be kidding.
> >>
> >>Ted, there are some requirements out there where you *must* use nested
> >>objects.
> >>When is Struts going to *properly* support this!!??...
> >>
> >>Arron.
> >>
> >>Ted Husted wrote:
> >>
> >>>Personally, I have the feeling that it's better to encourage people to
> >>>define a proxy object, or wrapper, as was done with the ActionServlet,
> >>>than invent a special class for people to learn.
> >>>
> >>>I actually believe that this is the approach that should have been used
> >>>in the first place, and in other places in the codebase. The
> >>>ActionServlet was placed there to provide access to certain properties,
> >>>and now the wrapper object defines exactly which properties those are.
> >>>An Encapsulate Class refactoring, if you will.
> >>>
> >>>Meanwhile, I'm suggesting that we do the same sort of thing with
> >>>multiple ActionSerlvets in another thread. Instead of exposing the
> >>>ActionServlet, we should expose a JavaBean with only the properites we
> >>>mean to expose.
> >>>
> >>>I think the important thing is to pound on the point that the ActionForm
> >>>is a firewall; it, and any objects it nests, are in the wild.
> >>>
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron <ar...@keyboardmonkey.com>.
>
>
>This idea came up in the original thread, but no one stepped forward
>with any code.
>
It has my interest.
I'll first take a squizz at the target areas, generate a hack version,
look at the viability, and see what happens from there.
>The one and only time there is a problem is when the nested object makes
>a direct and immediate change to the internal system state. So long as
>the nested object is buffering the input, and can be validated before
>any change is committed, then it's a non-issue.
>
How does the current buffering mechanism do its thing for flat beans?...
Is there a short answer without telling me to go read the code?... :)
Arron.
>
>
>Arron Bates wrote:
>
>>Not a special class, I'm talking about placing it into the process.
>>Before the servlet updates the properties it checks for a security
>>mapping. Based on the request and the security, it updates the
>>properties. It would be more secure, and every property which is up to
>>be set, can rest assured that it's safe. And that includes the
>>properties that we "mean to expose" nested or otherwise.
>>
>>All amounting to better security and an easier development path for the
>>developers.
>>I've had to use a decoupling through nested objects for an app that's in
>>development. 100's of input fields. Writing proxy classes for it all.
>>You have to be kidding.
>>
>>Ted, there are some requirements out there where you *must* use nested
>>objects.
>>When is Struts going to *properly* support this!!??...
>>
>>Arron.
>>
>>Ted Husted wrote:
>>
>>>Personally, I have the feeling that it's better to encourage people to
>>>define a proxy object, or wrapper, as was done with the ActionServlet,
>>>than invent a special class for people to learn.
>>>
>>>I actually believe that this is the approach that should have been used
>>>in the first place, and in other places in the codebase. The
>>>ActionServlet was placed there to provide access to certain properties,
>>>and now the wrapper object defines exactly which properties those are.
>>>An Encapsulate Class refactoring, if you will.
>>>
>>>Meanwhile, I'm suggesting that we do the same sort of thing with
>>>multiple ActionSerlvets in another thread. Instead of exposing the
>>>ActionServlet, we should expose a JavaBean with only the properites we
>>>mean to expose.
>>>
>>>I think the important thing is to pound on the point that the ActionForm
>>>is a firewall; it, and any objects it nests, are in the wild.
>>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Ted Husted <hu...@apache.org>.
This idea came up in the original thread, but no one stepped forward
with any code.
The one and only time there is a problem is when the nested object makes
a direct and immediate change to the internal system state. So long as
the nested object is buffering the input, and can be validated before
any change is committed, then it's a non-issue.
Arron Bates wrote:
>
> Not a special class, I'm talking about placing it into the process.
> Before the servlet updates the properties it checks for a security
> mapping. Based on the request and the security, it updates the
> properties. It would be more secure, and every property which is up to
> be set, can rest assured that it's safe. And that includes the
> properties that we "mean to expose" nested or otherwise.
>
> All amounting to better security and an easier development path for the
> developers.
> I've had to use a decoupling through nested objects for an app that's in
> development. 100's of input fields. Writing proxy classes for it all.
> You have to be kidding.
>
> Ted, there are some requirements out there where you *must* use nested
> objects.
> When is Struts going to *properly* support this!!??...
>
> Arron.
>
> Ted Husted wrote:
>
> >Personally, I have the feeling that it's better to encourage people to
> >define a proxy object, or wrapper, as was done with the ActionServlet,
> >than invent a special class for people to learn.
> >
> >I actually believe that this is the approach that should have been used
> >in the first place, and in other places in the codebase. The
> >ActionServlet was placed there to provide access to certain properties,
> >and now the wrapper object defines exactly which properties those are.
> >An Encapsulate Class refactoring, if you will.
> >
> >Meanwhile, I'm suggesting that we do the same sort of thing with
> >multiple ActionSerlvets in another thread. Instead of exposing the
> >ActionServlet, we should expose a JavaBean with only the properites we
> >mean to expose.
> >
> >I think the important thing is to pound on the point that the ActionForm
> >is a firewall; it, and any objects it nests, are in the wild.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron Bates <ar...@keyboardmonkey.com>.
Not a special class, I'm talking about placing it into the process.
Before the servlet updates the properties it checks for a security
mapping. Based on the request and the security, it updates the
properties. It would be more secure, and every property which is up to
be set, can rest assured that it's safe. And that includes the
properties that we "mean to expose" nested or otherwise.
All amounting to better security and an easier development path for the
developers.
I've had to use a decoupling through nested objects for an app that's in
development. 100's of input fields. Writing proxy classes for it all.
You have to be kidding.
Ted, there are some requirements out there where you *must* use nested
objects.
When is Struts going to *properly* support this!!??...
Arron.
Ted Husted wrote:
>Personally, I have the feeling that it's better to encourage people to
>define a proxy object, or wrapper, as was done with the ActionServlet,
>than invent a special class for people to learn.
>
>I actually believe that this is the approach that should have been used
>in the first place, and in other places in the codebase. The
>ActionServlet was placed there to provide access to certain properties,
>and now the wrapper object defines exactly which properties those are.
>An Encapsulate Class refactoring, if you will.
>
>Meanwhile, I'm suggesting that we do the same sort of thing with
>multiple ActionSerlvets in another thread. Instead of exposing the
>ActionServlet, we should expose a JavaBean with only the properites we
>mean to expose.
>
>I think the important thing is to pound on the point that the ActionForm
>is a firewall; it, and any objects it nests, are in the wild.
>
>Arron Bates wrote:
>
>> Yes, yes. Point made.
>>That series of emails makes for some good bedside reading.
>>
>>I think that the solution that was arrived at is fine for protecting the
>>struts system objects themselves.
>>Is there anything happening to allow the developer to protect their own
>>properties from this kind of arbitrary attack?
>>
>>Thought I had would be to configure a property modifier, or property
>>mapping which yields other "security properties" which have to be
>>checked before a property is set. ie: getMyProperty() property method
>>uses a getMyPropertySecurity() to return a defined value which was set
>>while writing the view so you can't just pass the one key value pair to
>>change a value, but a two key value pairs with the second value being a
>>specific hashing or such. This would stop the casual hacking of any
>>property via the URL. You could also then define a security property for
>>all things struts within the ActionForm.
>>
>>The possibility then in extending this would be to define a security
>>property to each property to be set, or a more simpler global security
>>property for the entire request, and let the developer decide as to how
>>fine grained the property setting security should be, if at all.
>>
>>Just a thought.
>>
>>Arron.
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Ted Husted <hu...@apache.org>.
Personally, I have the feeling that it's better to encourage people to
define a proxy object, or wrapper, as was done with the ActionServlet,
than invent a special class for people to learn.
I actually believe that this is the approach that should have been used
in the first place, and in other places in the codebase. The
ActionServlet was placed there to provide access to certain properties,
and now the wrapper object defines exactly which properties those are.
An Encapsulate Class refactoring, if you will.
Meanwhile, I'm suggesting that we do the same sort of thing with
multiple ActionSerlvets in another thread. Instead of exposing the
ActionServlet, we should expose a JavaBean with only the properites we
mean to expose.
I think the important thing is to pound on the point that the ActionForm
is a firewall; it, and any objects it nests, are in the wild.
Arron Bates wrote:
>
> Yes, yes. Point made.
> That series of emails makes for some good bedside reading.
>
> I think that the solution that was arrived at is fine for protecting the
> struts system objects themselves.
> Is there anything happening to allow the developer to protect their own
> properties from this kind of arbitrary attack?
>
> Thought I had would be to configure a property modifier, or property
> mapping which yields other "security properties" which have to be
> checked before a property is set. ie: getMyProperty() property method
> uses a getMyPropertySecurity() to return a defined value which was set
> while writing the view so you can't just pass the one key value pair to
> change a value, but a two key value pairs with the second value being a
> specific hashing or such. This would stop the casual hacking of any
> property via the URL. You could also then define a security property for
> all things struts within the ActionForm.
>
> The possibility then in extending this would be to define a security
> property to each property to be set, or a more simpler global security
> property for the entire request, and let the developer decide as to how
> fine grained the property setting security should be, if at all.
>
> Just a thought.
>
> Arron.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>