You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Sven Meier <sv...@meiers.net> on 2020/03/12 11:28:45 UTC
CSPRequestCycleListener headers
Hi Emond,
it seems to me the CSPRequestCycleListener might add CSP headers
prematurely.
What if a request comes in for one page and another page is rendered in
response?
The listener will already add the headers when the request handler is
resolved for the former page.
What if the page streams back a resource? Setting the headers doesn't
make sense then, does it?
Sven
Re: CSPRequestCycleListener headers
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Mar 12, 2020 at 3:34 PM Martin Grigorov <mg...@apache.org>
wrote:
>
>
> On Thu, Mar 12, 2020 at 3:03 PM Emond Papegaaij <em...@gmail.com>
> wrote:
>
>> Hi Sven,
>>
>> Yes, you might be right. When rendering another page, normally the
>> header will be overridden when the second handler is resolved.
>> However, this will not happen when the page is not protected
>> (protectedPageFilter). Do you see a solution for this? Maybe recording
>> the desired action in the RequestCycle per handler, so the last
>> handler will always override the previous one? The action can then be
>> performed in onEndRequest. It would be nice if we had some tests for
>> this, but I'm not that experienced in writing tests with WicketTester
>> :)
>>
>
> One is never too old to learn how to write tests with WicketTester! ;-)
>
Actually, every time you look into some part of Wicket code you find things
to improve.
Go look into it, Emond! :-)
>
>
>>
>> Setting the header on a resource usually doesn't make sense, but
>> doesn't hurt either. I haven't found a clear explanation of how CSP
>> values interact across requests. For example, for js you can use
>> strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded
>> via js.
>>
>> Best regards,
>> Emond
>>
>> On Thu, Mar 12, 2020 at 12:28 PM Sven Meier <sv...@meiers.net> wrote:
>> >
>> > Hi Emond,
>> >
>> > it seems to me the CSPRequestCycleListener might add CSP headers
>> > prematurely.
>> >
>> > What if a request comes in for one page and another page is rendered in
>> > response?
>> > The listener will already add the headers when the request handler is
>> > resolved for the former page.
>> >
>> > What if the page streams back a resource? Setting the headers doesn't
>> > make sense then, does it?
>> >
>> > Sven
>> >
>>
>
Re: CSPRequestCycleListener headers
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Mar 12, 2020 at 3:03 PM Emond Papegaaij <em...@gmail.com>
wrote:
> Hi Sven,
>
> Yes, you might be right. When rendering another page, normally the
> header will be overridden when the second handler is resolved.
> However, this will not happen when the page is not protected
> (protectedPageFilter). Do you see a solution for this? Maybe recording
> the desired action in the RequestCycle per handler, so the last
> handler will always override the previous one? The action can then be
> performed in onEndRequest. It would be nice if we had some tests for
> this, but I'm not that experienced in writing tests with WicketTester
> :)
>
One is never too old to learn how to write tests with WicketTester! ;-)
>
> Setting the header on a resource usually doesn't make sense, but
> doesn't hurt either. I haven't found a clear explanation of how CSP
> values interact across requests. For example, for js you can use
> strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded
> via js.
>
> Best regards,
> Emond
>
> On Thu, Mar 12, 2020 at 12:28 PM Sven Meier <sv...@meiers.net> wrote:
> >
> > Hi Emond,
> >
> > it seems to me the CSPRequestCycleListener might add CSP headers
> > prematurely.
> >
> > What if a request comes in for one page and another page is rendered in
> > response?
> > The listener will already add the headers when the request handler is
> > resolved for the former page.
> >
> > What if the page streams back a resource? Setting the headers doesn't
> > make sense then, does it?
> >
> > Sven
> >
>
Re: CSPRequestCycleListener headers
Posted by Emond Papegaaij <em...@gmail.com>.
I've changed the code. From what I can see, the header is now only set
once per request. It could be there some exceptions to this, for
example when the request is restarted during rendering. IMHO that's
not a big issue, because the header is still added only once.
I've also added a demo-case to the CSP example that shows that CSP
protection still works in ajax requests.
Best regards,
Emond
On Fri, Mar 13, 2020 at 9:18 AM Emond Papegaaij
<em...@gmail.com> wrote:
>
> Hi Sven,
>
> I've reread the spec a bit more precise last night. I think we can
> change the code to only set the header on a RenderPageRequestHandler.
> The CSP is taken from the page and applies to all resources loaded by
> that page. The only exceptions are child-contexts: iframes, objects
> and js-workers. For iframes, Wicket will render a new page and thus
> set the CSP. This only leaves objects and js-workers, which IMHO are
> quite rare. I'm not sure if the child-context will inherit the CSP
> from the page if it's not set. I couldn't find this in the spec.
>
> The reason to use a header is that it is the recommended method of
> delivery for the CSP. The meta tag has some problems, for example when
> resources show up before the tag.
>
> I'll give the above a try and see if it works.
>
> Best regards,
> Emond
>
> On Thu, Mar 12, 2020 at 9:40 PM Sven Meier <sv...@meiers.net> wrote:
> >
> > Hi Emond,
> >
> > for me setting the appropriate headers is part of rendering.
> >
> > I've just tried setting HTTP CSP headers from
> > CSPNonceHeaderResponseDecorator, and that almost works (with minor
> > changes to HtmlHeaderContainer, which currently doesn't allow setting of
> > headers during rendering).
> >
> > Before you took over, CSPNonceHeaderResponseDecorator wrote the CSP
> > headers in http-equiv <meta> tags.
> > What was your reason to change this to HTTP headers in the first place?
> >
> > Regards
> > Sven
> >
> >
> > On 12.03.20 14:02, Emond Papegaaij wrote:
> > > Hi Sven,
> > >
> > > Yes, you might be right. When rendering another page, normally the
> > > header will be overridden when the second handler is resolved.
> > > However, this will not happen when the page is not protected
> > > (protectedPageFilter). Do you see a solution for this? Maybe recording
> > > the desired action in the RequestCycle per handler, so the last
> > > handler will always override the previous one? The action can then be
> > > performed in onEndRequest. It would be nice if we had some tests for
> > > this, but I'm not that experienced in writing tests with WicketTester
> > > :)
> > >
> > > Setting the header on a resource usually doesn't make sense, but
> > > doesn't hurt either. I haven't found a clear explanation of how CSP
> > > values interact across requests. For example, for js you can use
> > > strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded
> > > via js.
> > >
> > > Best regards,
> > > Emond
> > >
> > > On Thu, Mar 12, 2020 at 12:28 PM Sven Meier <sv...@meiers.net> wrote:
> > >> Hi Emond,
> > >>
> > >> it seems to me the CSPRequestCycleListener might add CSP headers
> > >> prematurely.
> > >>
> > >> What if a request comes in for one page and another page is rendered in
> > >> response?
> > >> The listener will already add the headers when the request handler is
> > >> resolved for the former page.
> > >>
> > >> What if the page streams back a resource? Setting the headers doesn't
> > >> make sense then, does it?
> > >>
> > >> Sven
> > >>
Re: CSPRequestCycleListener headers
Posted by Emond Papegaaij <em...@gmail.com>.
Hi Sven,
I've reread the spec a bit more precise last night. I think we can
change the code to only set the header on a RenderPageRequestHandler.
The CSP is taken from the page and applies to all resources loaded by
that page. The only exceptions are child-contexts: iframes, objects
and js-workers. For iframes, Wicket will render a new page and thus
set the CSP. This only leaves objects and js-workers, which IMHO are
quite rare. I'm not sure if the child-context will inherit the CSP
from the page if it's not set. I couldn't find this in the spec.
The reason to use a header is that it is the recommended method of
delivery for the CSP. The meta tag has some problems, for example when
resources show up before the tag.
I'll give the above a try and see if it works.
Best regards,
Emond
On Thu, Mar 12, 2020 at 9:40 PM Sven Meier <sv...@meiers.net> wrote:
>
> Hi Emond,
>
> for me setting the appropriate headers is part of rendering.
>
> I've just tried setting HTTP CSP headers from
> CSPNonceHeaderResponseDecorator, and that almost works (with minor
> changes to HtmlHeaderContainer, which currently doesn't allow setting of
> headers during rendering).
>
> Before you took over, CSPNonceHeaderResponseDecorator wrote the CSP
> headers in http-equiv <meta> tags.
> What was your reason to change this to HTTP headers in the first place?
>
> Regards
> Sven
>
>
> On 12.03.20 14:02, Emond Papegaaij wrote:
> > Hi Sven,
> >
> > Yes, you might be right. When rendering another page, normally the
> > header will be overridden when the second handler is resolved.
> > However, this will not happen when the page is not protected
> > (protectedPageFilter). Do you see a solution for this? Maybe recording
> > the desired action in the RequestCycle per handler, so the last
> > handler will always override the previous one? The action can then be
> > performed in onEndRequest. It would be nice if we had some tests for
> > this, but I'm not that experienced in writing tests with WicketTester
> > :)
> >
> > Setting the header on a resource usually doesn't make sense, but
> > doesn't hurt either. I haven't found a clear explanation of how CSP
> > values interact across requests. For example, for js you can use
> > strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded
> > via js.
> >
> > Best regards,
> > Emond
> >
> > On Thu, Mar 12, 2020 at 12:28 PM Sven Meier <sv...@meiers.net> wrote:
> >> Hi Emond,
> >>
> >> it seems to me the CSPRequestCycleListener might add CSP headers
> >> prematurely.
> >>
> >> What if a request comes in for one page and another page is rendered in
> >> response?
> >> The listener will already add the headers when the request handler is
> >> resolved for the former page.
> >>
> >> What if the page streams back a resource? Setting the headers doesn't
> >> make sense then, does it?
> >>
> >> Sven
> >>
Re: CSPRequestCycleListener headers
Posted by Sven Meier <sv...@meiers.net>.
Hi Emond,
for me setting the appropriate headers is part of rendering.
I've just tried setting HTTP CSP headers from
CSPNonceHeaderResponseDecorator, and that almost works (with minor
changes to HtmlHeaderContainer, which currently doesn't allow setting of
headers during rendering).
Before you took over, CSPNonceHeaderResponseDecorator wrote the CSP
headers in http-equiv <meta> tags.
What was your reason to change this to HTTP headers in the first place?
Regards
Sven
On 12.03.20 14:02, Emond Papegaaij wrote:
> Hi Sven,
>
> Yes, you might be right. When rendering another page, normally the
> header will be overridden when the second handler is resolved.
> However, this will not happen when the page is not protected
> (protectedPageFilter). Do you see a solution for this? Maybe recording
> the desired action in the RequestCycle per handler, so the last
> handler will always override the previous one? The action can then be
> performed in onEndRequest. It would be nice if we had some tests for
> this, but I'm not that experienced in writing tests with WicketTester
> :)
>
> Setting the header on a resource usually doesn't make sense, but
> doesn't hurt either. I haven't found a clear explanation of how CSP
> values interact across requests. For example, for js you can use
> strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded
> via js.
>
> Best regards,
> Emond
>
> On Thu, Mar 12, 2020 at 12:28 PM Sven Meier <sv...@meiers.net> wrote:
>> Hi Emond,
>>
>> it seems to me the CSPRequestCycleListener might add CSP headers
>> prematurely.
>>
>> What if a request comes in for one page and another page is rendered in
>> response?
>> The listener will already add the headers when the request handler is
>> resolved for the former page.
>>
>> What if the page streams back a resource? Setting the headers doesn't
>> make sense then, does it?
>>
>> Sven
>>
Re: CSPRequestCycleListener headers
Posted by Emond Papegaaij <em...@gmail.com>.
Hi Sven,
Yes, you might be right. When rendering another page, normally the
header will be overridden when the second handler is resolved.
However, this will not happen when the page is not protected
(protectedPageFilter). Do you see a solution for this? Maybe recording
the desired action in the RequestCycle per handler, so the last
handler will always override the previous one? The action can then be
performed in onEndRequest. It would be nice if we had some tests for
this, but I'm not that experienced in writing tests with WicketTester
:)
Setting the header on a resource usually doesn't make sense, but
doesn't hurt either. I haven't found a clear explanation of how CSP
values interact across requests. For example, for js you can use
strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded
via js.
Best regards,
Emond
On Thu, Mar 12, 2020 at 12:28 PM Sven Meier <sv...@meiers.net> wrote:
>
> Hi Emond,
>
> it seems to me the CSPRequestCycleListener might add CSP headers
> prematurely.
>
> What if a request comes in for one page and another page is rendered in
> response?
> The listener will already add the headers when the request handler is
> resolved for the former page.
>
> What if the page streams back a resource? Setting the headers doesn't
> make sense then, does it?
>
> Sven
>