You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Carl-Eric Menzel <cm...@wicketbuch.de> on 2018/02/01 21:45:53 UTC
Ajax Form submission and method mismatch
Hi,
I've just encountered an interesting oddity. For a normal form
submission, there is Form#onMethodMismatch where I can decide what
should happen if somebody calls the form's URL with a GET request rather
than the usual POST. At least in 6.x and 7.x this is called from
onFormSubmitted() - but not from onFormSubmitted(submitter).
The result is that for forms that have an ajax button and thus a valid
submitter, I can't stop somebody building a GET request and firing that
against the button's URL. Theoretically I could override
AjaxFormSubmitBehavior's onEvent method, but that doesn't work for ajax
buttons, which build their own AjaxFormSubmitBehavior.
On one of my current projects the customer is quite security-minded and
would like the application to block these GET requests. My question is:
Is it intentional that only the regular onFormSubmitted() method checks
this? If yes, I'd like to know the reasoning please. If not, I'm going
to write a patch to fix this.
Or maybe I'm missing something and am going the wrong way entirely. In
that case, let me know please.
Carl-Eric
Re: Ajax Form submission and method mismatch
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Ok. I see.
On Fri, Feb 2, 2018 at 3:42 PM, Carl-Eric Menzel <cm...@wicketbuch.de>
wrote:
> GET requests can be triggered by someone opening a page with e.g. an
> image URL pointing to that. In a small application, this URL can be
> guessable.
> But even if it weren't a security issue - I still would like to know why
> there is this inconsistency between onFormSubmitted and
> onFormSubmitted(submitter).
>
> On Fri, Feb 2, 2018, at 15:39, Ernesto Reinaldo Barreiro wrote:
> > Ok. But does that posses a real security issue? i.e not logged used
> > triggering a click on "that" button that does not exists for them?
> >
> > On Fri, Feb 2, 2018 at 3:36 PM, Carl-Eric Menzel
> > <cm...@wicketbuch.de>> wrote:
> >
> >> You're not wrong, but I'd still like to be able to block GET. And the>>
> other question is **why** this check isn't done for forms with submit>>
> components (I haven't tried it, but I suspect using a regular button>>
> rather than an ajax button would run into the same issue).
> >>
> >> On Fri, Feb 2, 2018, at 14:45, Ernesto Reinaldo Barreiro wrote:
> >>> Hi,
> >>>
> >>> Maybe I'm wrong but for AJAX only logged in user could get that
> >>> REQUEST to> work because it is page relative. Or am I completely
> >>> wrong?>>>
> >>> On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel
> >>> <cm...@wicketbuch.de>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I've just encountered an interesting oddity. For a normal form
> >>>> submission,>> there is Form#onMethodMismatch where I can
> >>>> decide what>> should
> >>>> happen if>> somebody calls the form's URL with a GET request
> >>>> rather than>>>> the usual>> POST. At least in 6.x and 7.x this is
> called from
> >>>> onFormSubmitted() - but>> not from onFormSubmitted(submitter).
> >>>>
> >>>> The result is that for forms that have an ajax button and thus
> >>>> a valid>> submitter, I can't stop somebody building a GET
> >>>> request and>>>> firing that>> against the button's URL. Theoretically
> I could
> >>>> override>>>> AjaxFormSubmitBehavior's onEvent method, but that
> doesn't work
> >>>> for ajax>> buttons, which build their own AjaxFormSubmitBehavior.
> >>>>
> >>>> On one of my current projects the customer is quite security-
> >>>> minded and>> would like the application to block these GET
> >>>> requests. My>>>> question is: Is>> it intentional that only the
> regular
> >> onFormSubmitted() method
> >>>> checks this?>> If yes, I'd like to know the reasoning please.
> >>>> If not,>> I'm going to
> >>>> write a>> patch to fix this.
> >>>>
> >>>> Or maybe I'm missing something and am going the wrong way
> >>>> entirely. In>> that case, let me know please.
> >>>>
> >>>> Carl-Eric
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards - Ernesto Reinaldo Barreiro
> >>
> >>
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
>
>
--
Regards - Ernesto Reinaldo Barreiro
Re: Ajax Form submission and method mismatch
Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
GET requests can be triggered by someone opening a page with e.g. an
image URL pointing to that. In a small application, this URL can be
guessable.
But even if it weren't a security issue - I still would like to know why
there is this inconsistency between onFormSubmitted and
onFormSubmitted(submitter).
On Fri, Feb 2, 2018, at 15:39, Ernesto Reinaldo Barreiro wrote:
> Ok. But does that posses a real security issue? i.e not logged used
> triggering a click on "that" button that does not exists for them?
>
> On Fri, Feb 2, 2018 at 3:36 PM, Carl-Eric Menzel
> <cm...@wicketbuch.de>> wrote:
>
>> You're not wrong, but I'd still like to be able to block GET. And the>> other question is **why** this check isn't done for forms with submit>> components (I haven't tried it, but I suspect using a regular button>> rather than an ajax button would run into the same issue).
>>
>> On Fri, Feb 2, 2018, at 14:45, Ernesto Reinaldo Barreiro wrote:
>>> Hi,
>>>
>>> Maybe I'm wrong but for AJAX only logged in user could get that
>>> REQUEST to> work because it is page relative. Or am I completely
>>> wrong?>>>
>>> On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel
>>> <cm...@wicketbuch.de>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've just encountered an interesting oddity. For a normal form
>>>> submission,>> there is Form#onMethodMismatch where I can
>>>> decide what>> should
>>>> happen if>> somebody calls the form's URL with a GET request
>>>> rather than>>>> the usual>> POST. At least in 6.x and 7.x this is called from
>>>> onFormSubmitted() - but>> not from onFormSubmitted(submitter).
>>>>
>>>> The result is that for forms that have an ajax button and thus
>>>> a valid>> submitter, I can't stop somebody building a GET
>>>> request and>>>> firing that>> against the button's URL. Theoretically I could
>>>> override>>>> AjaxFormSubmitBehavior's onEvent method, but that doesn't work
>>>> for ajax>> buttons, which build their own AjaxFormSubmitBehavior.
>>>>
>>>> On one of my current projects the customer is quite security-
>>>> minded and>> would like the application to block these GET
>>>> requests. My>>>> question is: Is>> it intentional that only the regular
>> onFormSubmitted() method
>>>> checks this?>> If yes, I'd like to know the reasoning please.
>>>> If not,>> I'm going to
>>>> write a>> patch to fix this.
>>>>
>>>> Or maybe I'm missing something and am going the wrong way
>>>> entirely. In>> that case, let me know please.
>>>>
>>>> Carl-Eric
>>>>
>>>
>>>
>>>
>>> --
>>> Regards - Ernesto Reinaldo Barreiro
>>
>>
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
Re: Ajax Form submission and method mismatch
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Ok. But does that posses a real security issue? i.e not logged used
triggering a click on "that" button that does not exists for them?
On Fri, Feb 2, 2018 at 3:36 PM, Carl-Eric Menzel <cm...@wicketbuch.de>
wrote:
> You're not wrong, but I'd still like to be able to block GET. And the
> other question is *why* this check isn't done for forms with submit
> components (I haven't tried it, but I suspect using a regular button
> rather than an ajax button would run into the same issue).
>
> On Fri, Feb 2, 2018, at 14:45, Ernesto Reinaldo Barreiro wrote:
> > Hi,
> >
> > Maybe I'm wrong but for AJAX only logged in user could get that
> > REQUEST to> work because it is page relative. Or am I completely wrong?
> >
> > On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel
> > <cm...@wicketbuch.de>> wrote:
> >
> >> Hi,
> >>
> >> I've just encountered an interesting oddity. For a normal form
> >> submission,>> there is Form#onMethodMismatch where I can decide what
> should
> >> happen if>> somebody calls the form's URL with a GET request rather than
> >> the usual>> POST. At least in 6.x and 7.x this is called from
> >> onFormSubmitted() - but>> not from onFormSubmitted(submitter).
> >>
> >> The result is that for forms that have an ajax button and thus
> >> a valid>> submitter, I can't stop somebody building a GET request and
> >> firing that>> against the button's URL. Theoretically I could override
> >> AjaxFormSubmitBehavior's onEvent method, but that doesn't work
> >> for ajax>> buttons, which build their own AjaxFormSubmitBehavior.
> >>
> >> On one of my current projects the customer is quite security-
> >> minded and>> would like the application to block these GET requests. My
> >> question is: Is>> it intentional that only the regular
> onFormSubmitted() method
> >> checks this?>> If yes, I'd like to know the reasoning please. If not,
> I'm going to
> >> write a>> patch to fix this.
> >>
> >> Or maybe I'm missing something and am going the wrong way
> >> entirely. In>> that case, let me know please.
> >>
> >> Carl-Eric
> >>
> >
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
>
>
--
Regards - Ernesto Reinaldo Barreiro
Re: Ajax Form submission and method mismatch
Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
You're not wrong, but I'd still like to be able to block GET. And the
other question is *why* this check isn't done for forms with submit
components (I haven't tried it, but I suspect using a regular button
rather than an ajax button would run into the same issue).
On Fri, Feb 2, 2018, at 14:45, Ernesto Reinaldo Barreiro wrote:
> Hi,
>
> Maybe I'm wrong but for AJAX only logged in user could get that
> REQUEST to> work because it is page relative. Or am I completely wrong?
>
> On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel
> <cm...@wicketbuch.de>> wrote:
>
>> Hi,
>>
>> I've just encountered an interesting oddity. For a normal form
>> submission,>> there is Form#onMethodMismatch where I can decide what should
>> happen if>> somebody calls the form's URL with a GET request rather than
>> the usual>> POST. At least in 6.x and 7.x this is called from
>> onFormSubmitted() - but>> not from onFormSubmitted(submitter).
>>
>> The result is that for forms that have an ajax button and thus
>> a valid>> submitter, I can't stop somebody building a GET request and
>> firing that>> against the button's URL. Theoretically I could override
>> AjaxFormSubmitBehavior's onEvent method, but that doesn't work
>> for ajax>> buttons, which build their own AjaxFormSubmitBehavior.
>>
>> On one of my current projects the customer is quite security-
>> minded and>> would like the application to block these GET requests. My
>> question is: Is>> it intentional that only the regular onFormSubmitted() method
>> checks this?>> If yes, I'd like to know the reasoning please. If not, I'm going to
>> write a>> patch to fix this.
>>
>> Or maybe I'm missing something and am going the wrong way
>> entirely. In>> that case, let me know please.
>>
>> Carl-Eric
>>
>
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
Re: Ajax Form submission and method mismatch
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Hi,
Maybe I'm wrong but for AJAX only logged in user could get that REQUEST to
work because it is page relative. Or am I completely wrong?
On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel <cm...@wicketbuch.de>
wrote:
> Hi,
>
> I've just encountered an interesting oddity. For a normal form submission,
> there is Form#onMethodMismatch where I can decide what should happen if
> somebody calls the form's URL with a GET request rather than the usual
> POST. At least in 6.x and 7.x this is called from onFormSubmitted() - but
> not from onFormSubmitted(submitter).
>
> The result is that for forms that have an ajax button and thus a valid
> submitter, I can't stop somebody building a GET request and firing that
> against the button's URL. Theoretically I could override
> AjaxFormSubmitBehavior's onEvent method, but that doesn't work for ajax
> buttons, which build their own AjaxFormSubmitBehavior.
>
> On one of my current projects the customer is quite security-minded and
> would like the application to block these GET requests. My question is: Is
> it intentional that only the regular onFormSubmitted() method checks this?
> If yes, I'd like to know the reasoning please. If not, I'm going to write a
> patch to fix this.
>
> Or maybe I'm missing something and am going the wrong way entirely. In
> that case, let me know please.
>
> Carl-Eric
>
--
Regards - Ernesto Reinaldo Barreiro
Re: Ajax Form submission and method mismatch
Posted by Martin Grigorov <ma...@gmail.com>.
On Feb 3, 2018 11:19, "Carl-Eric Menzel" <cm...@wicketbuch.de> wrote:
I've started working on it.
Incidentally, I just noticed that 6.x which I think is supposed to be
targeting Java 6, can't actually be built with JDK6! The clirr maven plugin
wants to run on at least Java 7. I'm going to work with Java 7 for the time
being.
https://ci.apache.org/builders/wicket-branch-6.x is green.
There we use JDK 1.6 for build, via Maven toolchains.
Do you see any Maven warnings from toolchains plugin complaining that your
configuration doesn't have oracle:jdk16 ?
On 02.02.2018 19:54, Sven Meier wrote:
> Hi Carl-Eric,
>
> WICKET-4107 was specifically about preventing GET request on stateless
> forms. Why not do something similar for Ajax behaviors?
>
> Have fun
>
> Sven
>
>
> Am 01.02.2018 um 22:45 schrieb Carl-Eric Menzel:
>
>> Hi,
>>
>> I've just encountered an interesting oddity. For a normal form
>> submission, there is Form#onMethodMismatch where I can decide what should
>> happen if somebody calls the form's URL with a GET request rather than the
>> usual POST. At least in 6.x and 7.x this is called from onFormSubmitted() -
>> but not from onFormSubmitted(submitter).
>>
>> The result is that for forms that have an ajax button and thus a valid
>> submitter, I can't stop somebody building a GET request and firing that
>> against the button's URL. Theoretically I could override
>> AjaxFormSubmitBehavior's onEvent method, but that doesn't work for ajax
>> buttons, which build their own AjaxFormSubmitBehavior.
>>
>> On one of my current projects the customer is quite security-minded and
>> would like the application to block these GET requests. My question is: Is
>> it intentional that only the regular onFormSubmitted() method checks this?
>> If yes, I'd like to know the reasoning please. If not, I'm going to write a
>> patch to fix this.
>>
>> Or maybe I'm missing something and am going the wrong way entirely. In
>> that case, let me know please.
>>
>> Carl-Eric
>>
>
>
Re: Ajax Form submission and method mismatch
Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
I've started working on it.
Incidentally, I just noticed that 6.x which I think is supposed to be
targeting Java 6, can't actually be built with JDK6! The clirr maven
plugin wants to run on at least Java 7. I'm going to work with Java 7
for the time being.
On 02.02.2018 19:54, Sven Meier wrote:
> Hi Carl-Eric,
>
> WICKET-4107 was specifically about preventing GET request on stateless
> forms. Why not do something similar for Ajax behaviors?
>
> Have fun
>
> Sven
>
>
> Am 01.02.2018 um 22:45 schrieb Carl-Eric Menzel:
>> Hi,
>>
>> I've just encountered an interesting oddity. For a normal form
>> submission, there is Form#onMethodMismatch where I can decide what
>> should happen if somebody calls the form's URL with a GET request
>> rather than the usual POST. At least in 6.x and 7.x this is called
>> from onFormSubmitted() - but not from onFormSubmitted(submitter).
>>
>> The result is that for forms that have an ajax button and thus a valid
>> submitter, I can't stop somebody building a GET request and firing
>> that against the button's URL. Theoretically I could override
>> AjaxFormSubmitBehavior's onEvent method, but that doesn't work for
>> ajax buttons, which build their own AjaxFormSubmitBehavior.
>>
>> On one of my current projects the customer is quite security-minded
>> and would like the application to block these GET requests. My
>> question is: Is it intentional that only the regular onFormSubmitted()
>> method checks this? If yes, I'd like to know the reasoning please. If
>> not, I'm going to write a patch to fix this.
>>
>> Or maybe I'm missing something and am going the wrong way entirely. In
>> that case, let me know please.
>>
>> Carl-Eric
>
Re: Ajax Form submission and method mismatch
Posted by Sven Meier <sv...@meiers.net>.
Hi Carl-Eric,
WICKET-4107 was specifically about preventing GET request on stateless
forms. Why not do something similar for Ajax behaviors?
Have fun
Sven
Am 01.02.2018 um 22:45 schrieb Carl-Eric Menzel:
> Hi,
>
> I've just encountered an interesting oddity. For a normal form
> submission, there is Form#onMethodMismatch where I can decide what
> should happen if somebody calls the form's URL with a GET request
> rather than the usual POST. At least in 6.x and 7.x this is called
> from onFormSubmitted() - but not from onFormSubmitted(submitter).
>
> The result is that for forms that have an ajax button and thus a valid
> submitter, I can't stop somebody building a GET request and firing
> that against the button's URL. Theoretically I could override
> AjaxFormSubmitBehavior's onEvent method, but that doesn't work for
> ajax buttons, which build their own AjaxFormSubmitBehavior.
>
> On one of my current projects the customer is quite security-minded
> and would like the application to block these GET requests. My
> question is: Is it intentional that only the regular onFormSubmitted()
> method checks this? If yes, I'd like to know the reasoning please. If
> not, I'm going to write a patch to fix this.
>
> Or maybe I'm missing something and am going the wrong way entirely. In
> that case, let me know please.
>
> Carl-Eric