You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by ad...@apache.org on 2020/09/03 16:48:16 UTC
[wicket] branch master updated: Documentation for Fetch Metadata
and Coop/Coep Suppport (#7)
This is an automated email from the ASF dual-hosted git repository.
adelbene pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new a1a8fd5 Documentation for Fetch Metadata and Coop/Coep Suppport (#7)
new fd0ee42 Merge pull request #447 from salcho/update-docs
a1a8fd5 is described below
commit a1a8fd5e0e8a9ddeaba06544419d65530027ca45
Author: Ecenaz Ozmen <eo...@columbia.edu>
AuthorDate: Fri Aug 28 13:26:02 2020 +0300
Documentation for Fetch Metadata and Coop/Coep Suppport (#7)
---
.../src/main/asciidoc/security/security_10.adoc | 25 +++++++++++++++
.../src/main/asciidoc/security/security_5.adoc | 36 ++++++++++++++++++++--
.../src/main/asciidoc/security/security_9.adoc | 2 +-
wicket-user-guide/src/main/asciidoc/single.adoc | 4 +++
4 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/wicket-user-guide/src/main/asciidoc/security/security_10.adoc b/wicket-user-guide/src/main/asciidoc/security/security_10.adoc
new file mode 100644
index 0000000..020e3a3
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/security/security_10.adoc
@@ -0,0 +1,25 @@
+A major consequence of transient execution attacks for the web is the risk of exposing private authenticated data to untrusted sites via microarchitectural side channels. Some web APIs increase the risk of side-channel attacks like https://meltdownattack.com/[Spectre]. To mitigate that risk, browsers offer two opt-in mechanisms to effectively isolate resources from third-party origins through Cross-Origin Opener Policy and Cross-Origin Embedder Policy.
+
+https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy[Cross-Origin Opener Policy (COOP)] is a security mitigation that lets developers isolate their resources against side-channel attacks and information leaks. The COOP response header allows a document to request a new browsing context group to better isolate itself from other untrustworthy origins.
+
+https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy[Cross-Origin Embedder Policy (COEP)] prevents a document from loading any cross-origin resources which don't explicitly grant the document permission to be loaded.
+
+COOP and COEP are independent mechanisms that can be enabled, tested and deployed separately. While enabling one doesn’t require developers to enable the other, when set together COOP and COEP allows developers to use powerful features (such as __SharedArrayBuffer__, __performance.measureMemory()__ and the JS Self-Profiling API) securely, while still mitigating information leaks and side channel attacks like Spectre. Read more about COOP/COEP on https://docs.google.com/document/d/1zDlfvf [...]
+
+Wicket provides highly configurable support for COOP and COEP. Users can specify the mode for each policy. For COOP, the __CoopMode__ represents the three valid header values __same-origin__ (__SAME_ORIGIN__ mode), __same-origin-allow-popups__ (__SAME_ORIGIN_ALLOW_POPUPS__ mode), __unsafe-none__ (__UNSAFE_NONE__ mode) and disabling COOP enitrely (__DISABLED__). For COEP the __CoepMode__ represents whether the policy will be __Report-Only__ (__REPORTING__ mode), enforcing (__ENFORCING__ m [...]
+
+To set preferred policies use the __CrossOriginOpenerPolicyConfiguration__ and __CrossOriginEmbedderPolicyConfiguration__ in __SecuritySettings__. The configuration should be set in the __init()__ method, the values are read once at startup (in __WebApplication#validateInit())__, and if the configurations indicate the policies aren't __DISABLED__ the respective listeners (__CrossOriginOpenerPolicyRequestCycleListener__, __CrossOriginEmbedderPolicyRequestCycleListener__) will be added aut [...]
+
+MyApplication.java
+[source,java]
+----
+ @Override
+ protected void init() {
+ super.init();
+ // configure COOP
+ getSecuritySettings().setCrossOriginOpenerPolicyConfiguration(CoopMode.SAME_ORIGIN, "exemptions");
+ // configure COEP
+ getSecuritySettings().setCrossOriginEmbedderPolicyConfiguration(CoepMode.ENFORCING, "exemptions");
+ // ...
+ }
+----
diff --git a/wicket-user-guide/src/main/asciidoc/security/security_5.adoc b/wicket-user-guide/src/main/asciidoc/security/security_5.adoc
index 52707b8..25a64c2 100644
--- a/wicket-user-guide/src/main/asciidoc/security/security_5.adoc
+++ b/wicket-user-guide/src/main/asciidoc/security/security_5.adoc
@@ -2,7 +2,40 @@
_CryptoMapper_ helps preventing CSRF attacks by making the urls impossible to be guessed by an attacker but still there is some theoretical chance this to happen.
-To further help against this kind of vulnerability Wicket provides _CsrfPreventionRequestCycleListener_ - a _IRequestCycleListener_ that forbids requests made from a different origin. By default only actions are forbidden, i.e. a request coming from different origin cannot execute _Link.onClick()_ or submit forms (_Form.onSubmit()_). Any request to render pages are still allowed so Wicket pages could be easily embedded in other applications.
+To further help against this kind of vulnerability Wicket provides _ResourceIsolationRequestCycleListener_ - a _IRequestCycleListener_ that uses __IResourceIsolationPolicy__ objects to decide whether to allow or reject cross-origin requests. By default only actions are checked, i.e. a cross-origin request cannot execute _Link.onClick()_ or submit forms (_Form.onSubmit()_). Any request to render pages are still allowed so Wicket pages could be easily embedded in other applications.
+
+MyApplication.java
+[source,java]
+----
+ @Override
+ protected void init() {
+ super.init();
+ getRequestCycleListeners().add(new ResourseIsolationRequestCycleListener());
+ // ...
+ }
+----
+
+_ResourceIsolationRequestCycleListener_ is highly configurable. It allows to add exempted paths that will not be checked with the __addExemptedPath__ method. It can be configured with multiple _ResourceIsolationPolicy_ objects to be checked in order.
+
+An __IResourceIsolationPolicy__ returns a __ResourceIsolationOutcome__ after processing a request, which can be one of 3 values (__ALLOWED__, __DISALLOWED__, __UNKNOWN__). The __ResourceIsolationRequestCycleListener__ checks the __IResourceIsolationPolicy__ objects in order and uses the first outcome that is not __UNKNOWN__ to trigger the appropriate action. If all return __UNKNOWN__ __unknownOutcomeAction__ is applied. The actions can be configured through the listener.
+
+The default constructor uses the __FetchMetadataResourceIsolationPolicy__, which checks Fetch Metadata headers, and the __OriginBasedResourceIsolationPolicy__ which uses the Origin and Referer headers to forbid requests made from a different origin, in order. The __OriginBasedResourceIsolationPolicy__ contains the refactored logic of the now deprecated __CsrfPreventionRequestCycleListener__.
+The listener can be configured to include custom __IResourceIsolationPolicy__ objects.
+
+MyApplication.java
+[source,java]
+----
+ @Override
+ protected void init() {
+ super.init();
+ getRequestCycleListeners().add(new ResourseIsolationRequestCycleListener(new FetchMetadataResourceIsolationPolicy()));
+ // ...
+ }
+----
+
+_ResourceIsolationRequestCycleListener_ is not an alternative to _CryptoMapper_! Both of them could be used separately or in tandem to prevent CSRF attacks depending on the application requirements.
+
+Wicket also provides the deprecated (since version 9.1.0) _CsrfPreventionRequestCycleListener_ - a _IRequestCycleListener_ that forbids requests made from a different origin. Similar to the __ResourceIsolationRequestCycleListener__ by default only actions are forbidden, i.e. a request coming from different origin cannot execute _Link.onClick()_ or submit forms (_Form.onSubmit()_). Any request to render pages are still allowed so Wicket pages could be easily embedded in other applications.
MyApplication.java
[source,java]
@@ -18,4 +51,3 @@ MyApplication.java
_CsrfPreventionRequestCycleListener_ is highly configurable. It allows to define a whitelist of allowed origins via _addAcceptedOrigin(String acceptedOrigin)_, to enable/disable it dynamically by overriding _isEnabled()_, to define different kind of actions when a request is rejected or allowed, to set custom error message and code for the rejected requests.
_CsrfPreventionRequestCycleListener_ is not an alternative to _CryptoMapper_! Both of them could be used separately or in tandem to prevent CSRF attacks depending on the application requirements.
-
diff --git a/wicket-user-guide/src/main/asciidoc/security/security_9.adoc b/wicket-user-guide/src/main/asciidoc/security/security_9.adoc
index 74acf19..6728352 100644
--- a/wicket-user-guide/src/main/asciidoc/security/security_9.adoc
+++ b/wicket-user-guide/src/main/asciidoc/security/security_9.adoc
@@ -6,6 +6,6 @@ Wicket natively supports role-based authorizations with strategies _MetaDataRole
After having explored how Wicket internally implements authentication and authorization, we continued with how to configure our applications to support HTTPS and how to specify which pages must be served over this protocol.
-We've explored the protection Wicket offers against CSRF attacks with URL encryption and the _CsrfPreventionRequestCycleListener_. This was followed by an explanation of the Content Security Policy used by Wicket and how to tune this for your application.
+We've explored the protection Wicket offers against CSRF attacks with URL encryption and the _ResourceIsolationRequestCycleListener_, or the (now deprecated) __CsrfPreventionRequestCycleListener__. This was followed by an explanation of the Content Security Policy used by Wicket and how to tune this for your application. We've also explained Cross-Origin Opener Policy and Cross-Origin Embedder policy to achieve cross-origin isolation, and how to configure the policies for your application.
In the last paragraph we have seen how Wicket protects package resources with a guard entity that allows us to decide which package resources can be accessed from users.
diff --git a/wicket-user-guide/src/main/asciidoc/single.adoc b/wicket-user-guide/src/main/asciidoc/single.adoc
index 2f53eb5..a134fca 100644
--- a/wicket-user-guide/src/main/asciidoc/single.adoc
+++ b/wicket-user-guide/src/main/asciidoc/single.adoc
@@ -663,6 +663,10 @@ include::security/security_5.adoc[leveloffset=+1]
include::security/security_6.adoc[leveloffset=+1]
+=== Cross Origin Isolation with COOP and COEP
+
+include::security/security_10.adoc[leveloffset=+1]
+
=== Package Resource Guard
include::security/security_7.adoc[leveloffset=+1]