4 ms·

What about the protections from XSS which Content Security Policies[0] can provide? It would be unfortunate when a bug in your blog engine can cause a hack of y

What about the protections from XSS which Content Security Policies[0] can provide? It would be unfortunate when a bug in your blog engine can cause a hack of your store. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

mrkurt 9y ago
CSP still applies, you can apply restrictions by path and hostname. Or am I missing your meaning?
- jakobdabo 9y ago
  For some reason I believed that CSP rules can be hostnames but not paths. At least in Mozialla's documentation above there is not a single example of a rule with a full path. I can't check it by myself right now to find out the truth as I'm far away from my development PC.
  - mrkurt 9y ago
    Ah, Mozilla's docs are not great. The spec allows a URI, and there is guidance on how to interpret paths: https://www.w3.org/TR/CSP2/#source-list-path-patching https://www.w3.org/TR/CSP2/#source-list-path-patching
  - lvh 9y ago
    According to the CSP2 spec, the value of a -src directive contains three parts: - protocol/scheme (optional) - hostname (mandatory) - path (optional) Notably, there is no query portion or fragment portion; browsers are expected to ignore those. Path matching works like a prefix if it ends in a slash. If it doesn't, only exactly that path matches. In CSP3, the secure protocol/scheme (https, wss) always matches, even if you explicitly specify http:// http://. In CSP2, the implicit scheme matches either; an explicit scheme only matches that scheme. This is typically not useful behavior because you probably have HSTS anyway, so people just use hostnames and only rarely specify the protocol. Most values in practice seem to just be hostnames in general; paths too are rare.
    - jakobdabo 9y ago
      Thank you, that was insightful.
- dgoldstein0 9y ago
  CSP doesn't help unless you can apply a strict policy to every page of your site. If a single page has an XSS, that gives js execution to the attacking code, which can then steal cookies, forge requests, exfiltrate localstorage, etc. With multiple domains, you at least can limit the blast radius of an XSS; on the same domain, most protections can be circumvented. E.g. there's no cors protection, so if different apps use different implementations of csrf, just fetch a the other app's page over XHR and parse out it's csrf token; it's probably their or in a cookie which you should be able to read.
dom0 9y ago
Cookies aren't restricted to paths as well.
- yahelc 9y ago
  No, cookies can be restricted to paths, it's just less commonly utilized. https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie#new-cookie_path https://developer.mozilla.org/en-US/docs/Web/API/Document/co...
  - tptacek 9y ago
    They can be, but the restriction isn't useful, because the Javascript same-origin policy doesn't reliably defend the boundary.
    - dgoldstein0 9y ago
      exactly. It still boggles my mind that browsers don't send up the path and domain of a cookie when sending the name & value with a request. for anyone interested in the topic, https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-zheng-updated.pdf https://www.usenix.org/system/files/conference/usenixsecurit... is a must read

mrkurt 9y ago

CSP still applies, you can apply restrictions by path and hostname. Or am I missing your meaning?

jakobdabo 9y ago
For some reason I believed that CSP rules can be hostnames but not paths. At least in Mozialla's documentation above there is not a single example of a rule with a full path. I can't check it by myself right now to find out the truth as I'm far away from my development PC.
- mrkurt 9y ago
  Ah, Mozilla's docs are not great. The spec allows a URI, and there is guidance on how to interpret paths: https://www.w3.org/TR/CSP2/#source-list-path-patching https://www.w3.org/TR/CSP2/#source-list-path-patching
- lvh 9y ago
  According to the CSP2 spec, the value of a -src directive contains three parts: - protocol/scheme (optional) - hostname (mandatory) - path (optional) Notably, there is no query portion or fragment portion; browsers are expected to ignore those. Path matching works like a prefix if it ends in a slash. If it doesn't, only exactly that path matches. In CSP3, the secure protocol/scheme (https, wss) always matches, even if you explicitly specify http:// http://. In CSP2, the implicit scheme matches either; an explicit scheme only matches that scheme. This is typically not useful behavior because you probably have HSTS anyway, so people just use hostnames and only rarely specify the protocol. Most values in practice seem to just be hostnames in general; paths too are rare.
  - jakobdabo 9y ago
    Thank you, that was insightful.
dgoldstein0 9y ago
CSP doesn't help unless you can apply a strict policy to every page of your site. If a single page has an XSS, that gives js execution to the attacking code, which can then steal cookies, forge requests, exfiltrate localstorage, etc. With multiple domains, you at least can limit the blast radius of an XSS; on the same domain, most protections can be circumvented. E.g. there's no cors protection, so if different apps use different implementations of csrf, just fetch a the other app's page over XHR and parse out it's csrf token; it's probably their or in a cookie which you should be able to read.

dom0 9y ago

Cookies aren't restricted to paths as well.

yahelc 9y ago
No, cookies can be restricted to paths, it's just less commonly utilized. https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie#new-cookie_path https://developer.mozilla.org/en-US/docs/Web/API/Document/co...
- tptacek 9y ago
  They can be, but the restriction isn't useful, because the Javascript same-origin policy doesn't reliably defend the boundary.
  - dgoldstein0 9y ago
    exactly. It still boggles my mind that browsers don't send up the path and domain of a cookie when sending the name & value with a request. for anyone interested in the topic, https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-zheng-updated.pdf https://www.usenix.org/system/files/conference/usenixsecurit... is a must read