[ 
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)

Reply via email to