[
https://issues.apache.org/jira/browse/WICKET-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149689#comment-17149689
]
Emond Papegaaij commented on WICKET-6786:
-----------------------------------------
Yes, that's what I meant. I hope the new implementation can be retrofitted into
the existing API. The would be ideal. Many of the configuration options and
overridable methods are the same. The current implementation has several
conditions, which can be seen in {{checkRequest}}. It first checks if an Origin
was sent with the request. If not, it cannot determine if the request was cross
site, and invokes the {{noOriginAction}}. It then checks if the origin was
whitelisted, if so, the request is allowed. Finally, it checks if the request
originated from the same domain as its target. If so, it's safe, if not, the
{{conflictingOriginAction}} is invoked.
The default actions for both are to block the request with a HTTP 400. It is
also possible to allow the request, or to modify the request to only reload the
page. This last action is very specific to Wicket's request handling. It allows
to modify a request that would triggered a submit or clicking a link to just
reload the page without invoking any logic.
The main problem with the current implementation comes from the fact that
browsers do not always send an {{Origin}} header. The most problematic case is
opening a link in a new tab. However, I've also seen the header being omitted
in other cases. For example, it is sometimes missing in some OAuth2 redirection
flows. These cases invoke the {{noOriginAction}}, which defaults to ABORT.
Hence, when a user opens a link in a new tab, the request is often blocked. The
{{Sec-Fetch-*}} headers should be much more reliable in determining the origin
of the request (cross site or not).
> 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)
