Action mapping documentation (and a security question)

View: New views
6 Messages — Rating Filter:   Alert me  

Action mapping documentation (and a security question)

by Jan T. Kim-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi All,

In the "Validating Input" section of the "Bootstrap" tutorial, I've
noticed the action mapping syntax

    <action name="Logon_*" method="{1}" class="tutorial.Logon">
      ...
    </action>


which the tutorial suggests as a shorthand for configuring

    <action name="Logon" class="tutorial.Logon">
      ...
    </action>
    <action name="Logon_input" method="input" class="tutorial.Logon">
      ...
    </action>

I have two questions about this:

(1) Where is the documentation of this wildcard syntax? In the
Guides > Core Developers Guide > Configuration Files > struts.xml
section I've only found the struts.xml DTD and little more, no
docs on the regular expression syntax and how groups within regular
expressions (I presume) are numbered and where references (of the
"{1}" type) can be used etc. Specifically, I'm puzzled how the
action name "Logon", which has no underscore in it, is matched by the
regexp "Logon_*".

(2) Isn't encoding methods in action name suffixes like this a potential
security issue? The action name suffix can obviously be edited by users,
but configuration pertains to executable content, so the border between
data provided by users and executable content could be crossed without
proper checks here, as users can change the intended suffix "_input"
to something else.

Best regards, Jan
--
 +- Jan T. Kim -------------------------------------------------------+
 |             email: j.kim@...                                 |
 |             WWW:   http://www.cmp.uea.ac.uk/people/jtk             |
 *-----=<  hierarchical systems are for files, not for humans  >=-----*

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...


Re: Action mapping documentation (and a security question)

by newton.dave :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jan T. Kim wrote:
> (1) Where is the documentation of this wildcard syntax?

http://struts.apache.org/2.x/docs/wildcard-mappings.html
http://struts.apache.org/2.x/docs/action-configuration.html#ActionConfiguration-WildcardMethod

Although the underscore thing is mentioned I don't think it's explicitly
stated. The first link above is linked off the "Guides" page directly,
and from the action configuration page.

> (2) Isn't encoding methods in action name suffixes like this a potential
> security issue?

Yep.

Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...


Re: Action mapping documentation (and a security question)

by Jan T. Kim-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sun, Jun 28, 2009 at 08:15:43AM -0400, Dave Newton wrote:
> Jan T. Kim wrote:
> >(1) Where is the documentation of this wildcard syntax?
>
> http://struts.apache.org/2.x/docs/wildcard-mappings.html
> http://struts.apache.org/2.x/docs/action-configuration.html#ActionConfiguration-WildcardMethod
>
> Although the underscore thing is mentioned I don't think it's explicitly
> stated. The first link above is linked off the "Guides" page directly,
> and from the action configuration page.

Ok -- from experimentation it seems to me that an "exclamation point
(aka 'bang'), underscore, or other special character" matches any other
special character or the empty string, as accessing "bleh", "bleh_"
and "bleh!" gives me a test form with validation errors while accessing
"bleh_input" gives me one without validation errors. (I tried a few
other characters but none exhibited this "special" behaviour so far --
does anyone know what the "other special characters" are?)

> >(2) Isn't encoding methods in action name suffixes like this a potential
> >security issue?

So, are wildcards useful for development but have to be expanded before
putting a system to production use?

Replacing the filename globbing like wildcard system with a complete
regular expression system would allow writing more precise rules, e.g.
one could write

    <action name="^bleh(_((input)|(dummy)))?$" method="{2}" ...>
      ...
    </action>

and be certain that the method attribute won't take any values other
than "input", "dummy", or the empty string (which then probably should
map to the execute method).

Best regards, Jan
--
 +- Jan T. Kim -------------------------------------------------------+
 |             email: j.kim@...                                 |
 |             WWW:   http://www.cmp.uea.ac.uk/people/jtk             |
 *-----=<  hierarchical systems are for files, not for humans  >=-----*

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...


Re: Action mapping documentation (and a security question)

by newton.dave :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jan T. Kim wrote:
>>> (2) Isn't encoding methods in action name suffixes like this a potential
>>> security issue?
>
> So, are wildcards useful for development but have to be expanded before
> putting a system to production use?

The only security issue I'm aware of is if the developer exposes
unwanted behavior in an action by making methods public when they
shouldn't be. A web app should have a real security mechanism in place
anyway, making sure that only users with appropriate access rights are
able to execute actions (or whatever granularity is required).

> Replacing the filename globbing like wildcard system with a complete
> regular expression system would allow writing more precise rules, e.g.
> one could write
>
>     <action name="^bleh(_((input)|(dummy)))?$" method="{2}" ...>
>       ...
>     </action>
>
> and be certain that the method attribute won't take any values other
> than "input", "dummy", or the empty string (which then probably should
> map to the execute method).

I'm sure we'd consider a patch, if such a matcher doesn't already
exist--but personally I'm not convinced of the utility, since it
basically means you'd then have two places to keep up to date: the
action class and its mapping (assuming XML configuration).

Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...


Re: Action mapping documentation (and a security question)

by musomesa :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


 If you lecture your developers to be aware that any public method becomes fair game the security concern might be mitigated but you still have a maintainability issue. With explicit configuration someone inheriting the code can easily figure out how an action method is used by looking at annotations or the XML.. If you allow bangs not only do you have to read *all* the JSPs in your application -- some URLs might be coming from outside the application making it impossible to account for all usage of the action.
Chris




 

-----Original Message-----
From: Jan T. Kim <j.kim@...>
To: Struts Users Mailing List <user@...>
Sent: Sun, Jun 28, 2009 10:55 am
Subject: Re: Action mapping documentation (and a security question)










On Sun, Jun 28, 2009 at 08:15:43AM -0400, Dave Newton wrote:
> Jan T. Kim wrote:
> >(1) Where is the documentation of this wildcard syntax?
>
> http://struts.apache.org/2.x/docs/wildcard-mappings.html
> http://struts.apache.org/2.x/docs/action-configuration.html#ActionConfiguration-WildcardMethod
>
> Although the underscore thing is mentioned I don't think it's explicitly
> stated. The first link above is linked off the "Guides" page directly,
> and from the action configuration page.

Ok -- from experimentation it seems to me that an "exclamation point
(aka 'bang'), underscore, or other special character" matches any other
special character or the empty string, as accessing "bleh", "bleh_"
and "bleh!" gives me a test form with validation errors while accessing
"bleh_input" gives me one without validation errors. (I tried a few
other characters but none exhibited this "special" behaviour so far --
does anyone know what the "other special characters" are?)

> >(2) Isn't encoding methods in action name suffixes like this a potential
> >security issue?

So, are wildcards useful for development but have to be expanded before
putting a system to production use?

Replacing the filename globbing like wildcard system with a complete
regular expression system would allow writing more precise rules, e.g.
one could write

    <action name="^bleh(_((input)|(dummy)))?$" method="{2}" ...>
      ...
    </action>

and be certain that the method attribute won't take any values other
than "input", "dummy", or the empty string (which then probably should
map to the execute method).

Best regards, Jan
--
 +- Jan T. Kim -------------------------------------------------------+
 |             email: j.kim@...                                 |
 |             WWW:   http://www.cmp.uea.ac.uk/people/jtk             |
 *-----=<  hierarchical systems are for files, not for humans  >=-----*

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...




 


Re: Action mapping documentation (and a security question)

by Jan T. Kim-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sun, Jun 28, 2009 at 11:51:59AM -0400, Dave Newton wrote:

> Jan T. Kim wrote:
> >>>(2) Isn't encoding methods in action name suffixes like this a potential
> >>>security issue?
> >
> >So, are wildcards useful for development but have to be expanded before
> >putting a system to production use?
>
> The only security issue I'm aware of is if the developer exposes
> unwanted behavior in an action by making methods public when they
> shouldn't be. A web app should have a real security mechanism in place
> anyway, making sure that only users with appropriate access rights are
> able to execute actions (or whatever granularity is required).
>
> >Replacing the filename globbing like wildcard system with a complete
> >regular expression system would allow writing more precise rules, e.g.
> >one could write
> >
> >    <action name="^bleh(_((input)|(dummy)))?$" method="{2}" ...>
> >      ...
> >    </action>
> >
> >and be certain that the method attribute won't take any values other
> >than "input", "dummy", or the empty string (which then probably should
> >map to the execute method).
>
> I'm sure we'd consider a patch, if such a matcher doesn't already
> exist--but personally I'm not convinced of the utility, since it
> basically means you'd then have two places to keep up to date: the
> action class and its mapping (assuming XML configuration).

That wouldn't be a change from the current state, my suggestion was to
replace / extend the current wildcard (plus special characters) mechanism
with / to a fully fledged regular expression mechanism (as provided
by java.util.regex), so that the "{n}" type references pertain to
groups, and ambiguities over whether special characters need to be
matched and end up in groups would disappear.

However, upon reflection I think that this could cause more backwards
compatibility issues than I originally anticipated, so it's probably
not worth pursuing.

Instead, I now wonder whether it would make sense to introduce an
additional level of indirection for the content of the action element
in struts.xml, so the content of action elements that differ in
method only wouldn't have to be repeated (similar to the way that
interceptor-ref works).

Best regards, Jan
--
 +- Jan T. Kim -------------------------------------------------------+
 |             email: j.kim@...                                 |
 |             WWW:   http://www.cmp.uea.ac.uk/people/jtk             |
 *-----=<  hierarchical systems are for files, not for humans  >=-----*

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...