3 ms·

I didn't quite get the CSP part. Why use and srcdoc and <meta http-equiv="Content-Security-Policy"> instead of a real server header? Static hosting?

by est 4mo ago

simonw 4mo ago
If you host iframe apps at a fixed URL like: /-/apps/iframe-content/timeline.html You can protect it with CSP headers, but you can't also protect it with the sandbox="" attribute (should a user visit it directly) If you want both sandbox= restrictions and CSP headers at the same time the only way I've found that works cross all major borders is the iframe plus srcdoc="" with injected CSP meta headers patterns. Note that a lot of sandbox implementations serve their iframe content from a separate domain, to ensure cookies and localStorage and other same origin things are robustly protected. I can't do that easily for Datasette because it's open source software that people can run on their own laptops, so I didn't want to block people on "now register a domain/subdomain and set this up in DNS".
- est 4mo ago
  [dead]
- cxr 4mo ago
  CSP is optional and designed to be one part of a defense-in-depth strategy (to extent that it was thoughtfully designed at all—it's an awful standard that should not have made it past proposal stage). It's not a solution for sandboxing untrusted content and should not be relied upon that way. Treating it like one is a great demonstration of how some uses of CSP make people more vulnerable.
  - simonw 4mo ago
    Right, which is why I'm combining it with <iframe sandbox=""> - which really is designed to be used as a sandbox (if you can figure out the right way to implement it.)
    - cxr 4mo ago
      > <iframe sandbox=""> - which really is designed to be used as a sandbox Not for untrusted content living on the same origin to prevent it from exercising any of the powers that it would ordinarily have to be able to access sensitive data. It's a misleading name and shouldn't have been chosen. There is no combination of CSP or the iframe sandbox attribute that can be relied upon for that purpose. This is a fundamental limitation of the way the specs were written. (There needs to be a big warning about this on MDN, but moving from the old wiki to a wiki with GitHub for login to the GitHub-based pull request process really didn't help the there's-a-problem-on-this-page-but-limited-resources-to-make-things-better problem.)
      - simonw 4mo ago
        That's why I'm careful not to include allow-same-origin in the sandbox attribute - without that the iframe content is treated as a separate origin from the parent. And I serve the content in srcdoc= to ensure there's no URL a user can visit which would directly execute the content outside of that iframe sandbox.
        cxr 4mo ago
        > That's why I'm careful not to include allow-same-origin in the sandbox attribute It doesn't matter. I just said there is no combination of CSP or the iframe sandbox attribute that can be relied upon here.
        simonw 4mo ago
        If that's true then my project is fatally flawed and I need to stop distributing it. I'm not convinced it's true - I've been thinking about this for months, and building experimental prototypes to help me get to the combination that I think makes sense. Can you describe an exploit that the combination I'm using of iframe sandbox= srcdoc= with an injected meta CSP tag doesn't handle? Would moving the untrusted content to be served from a separate domain entirely close the hole? (In case it's not clear the iframe sandbox= is the bit that's doing most of the work here - the CSP stuff is there mainly to protect against malicious apps that deliberately exfiltrate stolen private data.)

I didn't quite get the CSP part. Why use and srcdoc and <meta http-equiv="Content-Security-Policy"> instead of a real server header? Static hosting?

by est 4mo ago

I didn't quite get the CSP part. Why use and srcdoc and <meta http-equiv="Content-Security-Policy"> instead of a real server header? Static hosting?

simonw 4mo ago

If you host iframe apps at a fixed URL like: /-/apps/iframe-content/timeline.html You can protect it with CSP headers, but you can't also protect it with the sandbox="" attribute (should a user visit it directly) If you want both sandbox= restrictions and CSP headers at the same time the only way I've found that works cross all major borders is the iframe plus srcdoc="" with injected CSP meta headers patterns. Note that a lot of sandbox implementations serve their iframe content from a separate domain, to ensure cookies and localStorage and other same origin things are robustly protected. I can't do that easily for Datasette because it's open source software that people can run on their own laptops, so I didn't want to block people on "now register a domain/subdomain and set this up in DNS".

est 4mo ago
[dead]
cxr 4mo ago
CSP is optional and designed to be one part of a defense-in-depth strategy (to extent that it was thoughtfully designed at all—it's an awful standard that should not have made it past proposal stage). It's not a solution for sandboxing untrusted content and should not be relied upon that way. Treating it like one is a great demonstration of how some uses of CSP make people more vulnerable.
- simonw 4mo ago
  Right, which is why I'm combining it with <iframe sandbox=""> - which really is designed to be used as a sandbox (if you can figure out the right way to implement it.)
  - cxr 4mo ago
    > <iframe sandbox=""> - which really is designed to be used as a sandbox Not for untrusted content living on the same origin to prevent it from exercising any of the powers that it would ordinarily have to be able to access sensitive data. It's a misleading name and shouldn't have been chosen. There is no combination of CSP or the iframe sandbox attribute that can be relied upon for that purpose. This is a fundamental limitation of the way the specs were written. (There needs to be a big warning about this on MDN, but moving from the old wiki to a wiki with GitHub for login to the GitHub-based pull request process really didn't help the there's-a-problem-on-this-page-but-limited-resources-to-make-things-better problem.)
    - simonw 4mo ago
      That's why I'm careful not to include allow-same-origin in the sandbox attribute - without that the iframe content is treated as a separate origin from the parent. And I serve the content in srcdoc= to ensure there's no URL a user can visit which would directly execute the content outside of that iframe sandbox.
      - cxr 4mo ago
        > That's why I'm careful not to include allow-same-origin in the sandbox attribute It doesn't matter. I just said there is no combination of CSP or the iframe sandbox attribute that can be relied upon here.
        simonw 4mo ago
        If that's true then my project is fatally flawed and I need to stop distributing it. I'm not convinced it's true - I've been thinking about this for months, and building experimental prototypes to help me get to the combination that I think makes sense. Can you describe an exploit that the combination I'm using of iframe sandbox= srcdoc= with an injected meta CSP tag doesn't handle? Would moving the untrusted content to be served from a separate domain entirely close the hole? (In case it's not clear the iframe sandbox= is the bit that's doing most of the work here - the CSP stuff is there mainly to protect against malicious apps that deliberately exfiltrate stolen private data.)