[
https://issues.apache.org/jira/browse/WICKET-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149633#comment-17149633
]
Emond Papegaaij commented on WICKET-6786:
-----------------------------------------
Hi Santiago,
I do not agree with you on this approach. The current
{{CsrfPreventionRequestCycleListener}} uses an approach to detecting CSRF
attacks that is very similar to using the Fetch Metadata. Both rely on headers
sent by the browser. The downside of the current implementation is that its
reliance on the {{Origin}} header makes it less reliable. It sometimes blocks
legitimate requests. Using Fetch Metadata should be much more reliable,
eliminating most if not all false positives. The major downside of using Fetch
Metadata is that it is only supported by recent Chromium based browsers. This
makes it a very poor candidate for a good protection.
If the Fetch Metadata implementation were to be separate from the current
implementation, users would need to add both to protect their application. This
would give the about the same protection as the current implementation already
gives, with the same false positives. The new implementation would add no
benefit at all.
If the two implementations are combined in a single listener, it can
dynamically base it's decisions on the headers sent by the browsers. For
browsers with support for Fetch Metadata, the protection can be based on these
headers, giving a strong protection with no false positives. For other
browsers, the old implementations will be used. This gives a much better
experience, requires less effort from the developer and allows a gradual
migration from the old to the new implementation as more browsers get Fetch
Metadata support.
> 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)