Stripes

Validation sometimes fails with indexed property notation

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: Release 1.5.6
  • Fix Version/s: Release 1.5.7, Release 1.6
  • Component/s: Validation
  • Labels:
    None

Description

This is the problem as it was described to me by Yannik Hampe.

=====

Consider the following action bean:

--snip

public class DemoAction implements ActionBean
{
private ActionBeanContext context;
@ValidateNestedProperties({ @Validate(field="i", minvalue=1) })
public List<MyClass> myProperty;
public Resolution demo() throws Exception

{ return new StreamingResolution("text/plain", Integer.toString(myProperty.get(0).i)); }

public static class MyClass

{ public Integer i; }

@Override
public void setContext(ActionBeanContext context)

{ this.context = context; }

@Override
public ActionBeanContext getContext()

{ return context; }

}

--snip

There are two ways to call this actionBean and pass a value i:

1. Demo.action?myProperty[0].i=-5
2. Demo.action?myProperty[0][i]=-5

Using the first method will be caught by Stripes' validation system. Using the second URL will print "-5" in the Browser, proving that the @Validate annotation has been bypassed.

This happens, because in net.sourceforge.stripes.controller.ParameterName the "strippedName" is generated by using the matcher Pattern.compile("\\[.*?
]") to remove indexes on indexed properties. But this will also remove the [i] in the example above, causing Stripes to use the @Validate tag that is attached to myProperty instead of the corresponding @Validate tag in the @ValidateNestedProperties annotation. Since in the example above the former tag is not present, Stripes will not perform any validation at all, but binding still works.

In the example above the consequences don't matter. But in other situations the validation tags may be used to protect the system from malicious input, for example if someone uses mask="^[a-z]$" and expects the string then to be safe to be used in certain parsers, such as SQL-parsers without further escaping.

Activity

Hide
Yannik Hampe added a comment - 09/Aug/11 1:51 PM

Note that this will work without a List as well.
If "myProperty" is declared like this:

@ValidateNestedProperties({ @Validate(field="i", minvalue=1) })
public MyClass myProperty;

Then one can bypass the validation as well, for example using the following URL: Demo.action?myProperty[i]=-5

Show
Yannik Hampe added a comment - 09/Aug/11 1:51 PM Note that this will work without a List as well. If "myProperty" is declared like this: @ValidateNestedProperties({ @Validate(field="i", minvalue=1) }) public MyClass myProperty; Then one can bypass the validation as well, for example using the following URL: Demo.action?myProperty[i]=-5
Hide
Ben Gunter added a comment - 17/May/12 4:38 PM

Thank you. This was a nice find. I tried to fix the issue while still supporting the bracket notation for bean property access, but that proved to be quite daunting. Instead, I have disabled bracket notation for bean properties. The binding will simply fail with an exception that is caught by the property binder and logged at debug.

Show
Ben Gunter added a comment - 17/May/12 4:38 PM Thank you. This was a nice find. I tried to fix the issue while still supporting the bracket notation for bean property access, but that proved to be quite daunting. Instead, I have disabled bracket notation for bean properties. The binding will simply fail with an exception that is caught by the property binder and logged at debug.

People

Vote (1)
Watch (0)

Dates

  • Created:
    09/Aug/11 10:35 AM
    Updated:
    17/May/12 4:38 PM
    Resolved:
    17/May/12 4:38 PM