From 235f8591c95cac5354ac14dd8922fc5d23a206fb Mon Sep 17 00:00:00 2001 From: Keith Cirkel Date: Fri, 10 Nov 2023 11:06:02 +0000 Subject: [PATCH 1/4] add details on security for invokers --- .../pages/components/invokers.explainer.mdx | 143 ++++++++++++++++++ 1 file changed, 143 insertions(+) diff --git a/site/src/pages/components/invokers.explainer.mdx b/site/src/pages/components/invokers.explainer.mdx index 022bce546..35871fe54 100644 --- a/site/src/pages/components/invokers.explainer.mdx +++ b/site/src/pages/components/invokers.explainer.mdx @@ -268,6 +268,149 @@ If the _Invokee_ is a `` element the _Invoker_ implicitly receives an will be `aria-expanded=true` when the _Invokee_ is open and `aria-expanded=false` otherwise. +### Security + +This proposal adds new capabilities in that elements can be interacted with +using HTML where prior these required scripting (read: JS). Care has been taken +within this proposal to ensure there are no substantially new security +implications, and that the risk is kept low. + +In general, _preventing scripting is not a security barrier_ because very few +users or websites disable scripting. That being said, we should not grant +significant new capabilities with or without scripting. + +Invokers, by design, have two security affordances: + +- Without scripting, they require user interaction - the invoker button needs + to be clicked for the browser to fire an Invoke Event. Scripts are able to + synthesise the `InvokeEvent`, or the `click` event on the button - but + scripts are already capable of causing the same interactions without Invokers. +- The `invoketarget` takes an IDREF which must reference an ID within the same + document. `invokeTargetElement` can be assigned a cross-root element, but + this requires scripting which means all actions are already possible. + +To go into more detail, below is a brief summary of the security considerations +per interaction: + +#### Popovers + +This proposal allows opening and closing popovers with `invoketarget`. This is +already possible with `popovertarget`, and so there is no new capability here. + +#### Dialogs + +This proposal allows opening and closing `` elements with +`invoketarget`. While this is new capability (prior to this proposal scripting +is required), it poses the same security considerations as popovers in that it +toggles the visiblity of a new element. Modal dialog elements are also placed +on the "top layer" which means they occlude other content. This is already +possible with popovers, which are also placed on the top layer, so while +buttons to open `` elements is a new capability, it is not a novel new +security threat considering attackers could already craft a popover. + +Modal dialogs also trap focus, such that focus can only be moved within +elements inside the dialog or the browser native controls (such as the URL +bar). This is considered to not pose a significant threat as the invoking +button requires user activation, the dialog cannot render outside of the +document frame (iframe or browser window) and so cannot occlude the browsers +Chrome, and there are built in gestures to close a dialog (such as the Esc key +via a `CloseWatcher`) that cannot be opted out of with or without invokers. + +#### Details (proposed follow-on) + +This proposal aims to allow opening and closing `
` elements with +`invoketarget`. This is not considered to be new capability, as it is already +possible to do this with the `` element. + +#### Input (proposed follow-on) + +It should be noted that input pickers (like the file picker dialog) render native +controls outside of the bounds of the document frame (iframe or browser window). +Due to this, the security implications of invoking these elements should be +carefully considered. + +Scripts can call `.showPicker()` on form elements, and the picker will open. +There are some cross-origin restrictions, for example calling `.showPicker()` +on elements in a cross-origin context only works for `` or +``. + +It is also possible to wrap an `` in a `