You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The RecipeRadar frontend web application provides subresource integrity information to clients (regardless of human/robot/other) for various elements on the page - including for example, the webmanifest file.
This allows clients to have a fairly strong guarantee that the contents they receive when they ask for that resource are in fact the intended, untampered contents.
It's a bit like finding a price alongside an item on a food menu, and then after you ask for that item, you also find the corresponding expected price for that item included on your payment receipt (in other words: it provides reassuring confirmation of subsequent information relating to a request you make based on previously-provided information).
The web application currently includes license-related information -- both for the application itself, and also for the dependencies of the application -- by using HTML object elements (see here in index.html).
These currently do not (cannot, based on any existing public HTML specifications edit: I suppose they can if they choose to. however it would have no defined purpose) include subresource integrity guarantees -- although the latest W3C WebAppSec spec I'm aware of (at time of writing 2023-01-17) does note that iframe support for subresource integrity may be added in future.
It's an unlikely attack vector, to be honest: I think that any potential attackers would have to be able to co-ordinate across TLS certificate providers (LetsEncrypt, in our case) and the network fabric used by clients -- and all to what goal? To modify the licensing information returned by a recipe search engine? It seems fairly unlikely - but also unlikely to be fair, if it were to occur.
Describe the solution you'd like
Use iframe elements to include the application's license and dependency licenses on the page, and include integrity attributes on those elements that adhere to what the anticipated spec for subresource integrity on iframe elements could reasonably be expected to describe (in the absence of such spec being known to exist).
Describe alternatives you've considered
In a similar kind of area, the typeMustMatch attribute on object elements may still retain some level of support in today's web browsers, and provides some added assurance about retrieved content (it should prevent, for example, accidental or intentional display of an image of Hafez -- unless such image were displayed as ASCII art, I suppose).
However, that attribute can also potentially cause some information leakage, and as a result has been removed from the HTML spec (and many browsers), so it probably isn't worthwhile to implement currently.
jayaddison
changed the title
Use iframes with content integrity for embedded content
Use iframes with content integrity for embedded licensing content
Jan 17, 2023
Is your feature request related to a problem? Please describe.
The RecipeRadar frontend web application provides subresource integrity information to clients (regardless of human/robot/other) for various elements on the page - including for example, the
webmanifest
file.This allows clients to have a fairly strong guarantee that the contents they receive when they ask for that resource are in fact the intended, untampered contents.
It's a bit like finding a price alongside an item on a food menu, and then after you ask for that item, you also find the corresponding expected price for that item included on your payment receipt (in other words: it provides reassuring confirmation of subsequent information relating to a request you make based on previously-provided information).
The web application currently includes license-related information -- both for the application itself, and also for the dependencies of the application -- by using HTML
object
elements (see here inindex.html
).These currently do not (
cannot, based on any existing public HTML specificationsedit: I suppose they can if they choose to. however it would have no defined purpose) include subresource integrity guarantees -- although the latest W3C WebAppSec spec I'm aware of (at time of writing 2023-01-17) does note thatiframe
support for subresource integrity may be added in future.It's an unlikely attack vector, to be honest: I think that any potential attackers would have to be able to co-ordinate across TLS certificate providers (LetsEncrypt, in our case) and the network fabric used by clients -- and all to what goal? To modify the licensing information returned by a recipe search engine? It seems fairly unlikely - but also unlikely to be fair, if it were to occur.
Describe the solution you'd like
Use
iframe
elements to include the application's license and dependency licenses on the page, and includeintegrity
attributes on those elements that adhere to what the anticipated spec for subresource integrity oniframe
elements could reasonably be expected to describe (in the absence of such spec being known to exist).Describe alternatives you've considered
In a similar kind of area, the
typeMustMatch
attribute onobject
elements may still retain some level of support in today's web browsers, and provides some added assurance about retrieved content (it should prevent, for example, accidental or intentional display of an image of Hafez -- unless such image were displayed as ASCII art, I suppose).However, that attribute can also potentially cause some information leakage, and as a result has been removed from the HTML spec (and many browsers), so it probably isn't worthwhile to implement currently.
Additional context
Relates to / awaits w3c/webappsec-subresource-integrity#21
The text was updated successfully, but these errors were encountered: