You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Santiago Diaz (Jira)" <ji...@apache.org> on 2020/07/01 16:35:00 UTC

[jira] [Comment Edited] (WICKET-6786) CsrfPreventionRequestCycleListener should support Fetch Metadata Request Headers

    [ https://issues.apache.org/jira/browse/WICKET-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149542#comment-17149542 ] 

Santiago Diaz edited comment on WICKET-6786 at 7/1/20, 4:34 PM:
----------------------------------------------------------------

Hi Edmond!

[We|[https://lists.apache.org/thread.html/rbd8b1500fff1140d136a08e35cf8c0f5cf200bf8a60b6a58204ef9a7%40%3Cdev.wicket.apache.org%3E]] are excited and ready to start working on adding Fetch Metadata as a feature to wicket-core. This will be configurable and have logging capabilities. Reading the description of this issue, I think it would be less confusing to users if we implement an independent FetchMetadataRequestCycleListener with its own configuration, exemptions and logic. Since Fetch Metadata has the ability to reject cross-origin requests to endpoints that are not meant to be accessed cross-origin without the need for a token, this would effectively replace the CsrfPreventionRequestCycleListener.

I'd be happy to either get this issue assigned to me (and change its description to reflect our design) or create a brand new issue and add our description there (which we can later link to this issue, perhaps as a duplicate). What do you think?


was (Author: saldiaz):
Hi Edmond! [We|[https://lists.apache.org/thread.html/rbd8b1500fff1140d136a08e35cf8c0f5cf200bf8a60b6a58204ef9a7%40%3Cdev.wicket.apache.org%3E]] are excited and ready to start working on adding Fetch Metadata as a feature to wicket-core. This will be configurable and have logging capabilities. Reading the description of this issue, I think it would be less confusing to users if we implement an independent FetchMetadataRequestCycleListener with its own configuration, exemptions and logic. Since Fetch Metadata has the ability to reject cross-origin requests to endpoints that are not meant to be accessed cross-origin without the need for a token, this would effectively replace the CsrfPreventionRequestCycleListener.

I'd be happy to either get this issue assigned to me (and give a full description of our design there) or create a brand new issue and add our description there. What do you think?

> CsrfPreventionRequestCycleListener should support Fetch Metadata Request Headers
> --------------------------------------------------------------------------------
>
>                 Key: WICKET-6786
>                 URL: https://issues.apache.org/jira/browse/WICKET-6786
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket-core
>    Affects Versions: 9.0.0-M5, 8.8.0
>            Reporter: Emond Papegaaij
>            Priority: Major
>
> {{CsrfPreventionRequestCycleListener}} tries to determine the origin of a request via interpretation of the origin header and use this to block cross origin requests. The origin header however is not very reliable. For example, when a user opens a link in a new tab, the header is not sent. Fetch Metadata Request Headers (https://w3c.github.io/webappsec-fetch-metadata/) aims to solve this via a set of well defined headers. For Wicket, {{sec-fetch-site}} is the most important: {{same-origin}} is safe, {{none}} is a user opening a link via (for example) a bookmark, {{same-site}} and {{cross-origin}} should be blocked.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)