[
https://issues.apache.org/jira/browse/WICKET-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150386#comment-17150386
]
Santiago Diaz commented on WICKET-6786:
---------------------------------------
Hi Edmond!
We're now retrofitting the new logic into the existing CSRF protection. One of
the changes in behaviour is Wicket's definition of a whitelist for CSRF:
cross-origin requests coming from an origin that has been whitelisted are
exempted from the existing CSRF checks.
In order to apply this same logic to Fetch Metadata, we propose to use the same
method as the existing code ({{getSourceUri)}}, which falls back to the
{{Origin}} or {{Referer}} headers. From our conversation, there are two
situations where we won't have Origin/Referer headers:
# When there's a top level navigation (a new tab has been opened, a bookmark
has been clicked, etc), in which case we can use {{Sec-Fetch-Site}} to choose
whether the request should continue normally.
# When there is an OAuth2 redirection flow or requests sent in no-cors mode,
i.e.
{code:java}
fetch("//cross-origin.com", {mode: 'no-cors', method: 'GET'}){code}
In this case, we often implement Fetch Metadata with the ability to add
exemptions to such endpoints (since these requests are seen as cross origin but
we can't tell what that origin is). That is, clients could be allowed to
specify a list of URIs in their {{WebApplication}} object that are exempted of
CSRF checks altogether.
Do you think allowing devs to add a list of URIs that are exempted from CSRF
checks would be useful for Wicket users?
> 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)
