Hi,

No one else answered your email and I guess they have the same problem as
me - I don't really understand the problem you describe.

You submit some form. Then you _intercept_ the request somehow and you
append some extra data. And finally your concern is that there is extra
data.

What I don't understand is: are you describing a security issue ?
If YES then use CRSF protection and/or CryptoMapper and/or custom token.



Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, May 16, 2016 at 1:02 PM, Samu Viitanen <zampp...@hotmail.com> wrote:

> Hello Wicket Users,
>
> I am a relatively new developer working with wicket. I have come across a
> strange feature that could cause problems in my project. When I submit a
> form that has validation errors and intercept the resulting POST request, I
> can insert query parameters in the URL. These query parameter values will
> then be appended after the original POST parameter.
>
> Example:
>
>
> /foo/fooAdmin?7-1.IBehaviorListener.0-admintabs-panel-wrapperform-tabbedpanel-panel-infoform-infosubmit&wicket-ajax=true&wicket-ajax-baseurl=fooAdmin%3F
>
> Will result in validation error. The request has POST parameters:
> tabbedpanel:panel:infoform:foo=This is not empty
> tabbedpanel:panel:infoform:bar=                 <- this field is required
> but empty in request
> tabbedpanel:panel:infoform:zoo=                 <- this field is not
> required but empty in request
>
> I intercept the request with BurpSuite and modify the request:
>
>
> /foo/fooAdmin?7-1.IBehaviorListener.0-admintabs-panel-wrapperform-tabbedpanel-panel-infoform-infosubmit&wicket-ajax=true&wicket-ajax-baseurl=fooAdmin%3F&tabbedpanel:panel:infoform:zoo=Haxor
>
> Results in error with TextField values:
> foo=This is not empty
> bar=                            <- Error
> zoo=;Haxor
>
> This behaviour obviously does not directly save anything, but if the user
> does not notice that a Text Field value has changed, he might save
> something that he did not intend to. NOTE: The inserted value does not
> replace the original value of the field, it just appends the new value to
> the original value in the POSTDATA. (zoo=Value -> zoo=Value;Haxor after
> attack)
>
> So I guess my question is: Is this intended? If so, is there a way around
> this or do I have to live with it?
>
> Thank you for your replies
>
> Samu Viitanen
>

Reply via email to