5 ms·

>Note: There’s a reasonable argument for warning on JavaScript includes as man-in-the-middle attacks can do nasty things, but that’s not true for CSS (on anythi

>Note: There’s a reasonable argument for warning on JavaScript includes as man-in-the-middle attacks can do nasty things, but that’s not true for CSS (on anything but IE) or images Changing an image on a button from "reply to this quip from your friend!" to "submit password to re-login" isn't a security risk?

three14 18y ago
This is exactly the issue. Once some content on the page is not SSL, you can't trust what you're seeing. Of course, it's easy to fix with an extension to HTML, something like hrefhash="DSKJsdfjsdfs234" so the browser can verify that the referenced resource hasn't been tampered with. Then you can have your non-private data served over HTTP, and cached by the browser and by proxies, and you don't need the extra server side computation of SSL.
- jrockway 18y ago
  I think browsers should respect HTTP's caching headers, even if the content is served over SSL. If the server says "hey, it's OK to cache this", I don't think the browser should second-guess that. If you want to be ultra-secure, get an extension for your browser that doesn't cache anything.
  - three14 18y ago
    I agree. But extending HTML to use a hash for verification has additional benefits. One - proxies can see plain HTTP, but they can't cache HTTPS (I think). Two - you can share the same images for the HTTP and HTTPS pages on your site. And three - you can point to a resource (e.g. a Javascript library, a download link, whatever) that you don't control, but you can now trust that the other site won't change it to something malicious.
    - three14 18y ago
      Just thought of another benefit - if the referenced resource is cached, the browser can save an extra HTTP request that it would have sent to check if the referenced data has been modified. Now it knows, given the hash, that it must be unchanged.
      - jrockway 18y ago
        All good points. I like your idea. I assume most people have frameworks that generate their <script src=...> tags for them, so this shouldn't even require developers to think about it.
- jbert 18y ago
  You could specify that you expect the referenced resource to be served with a given ETag. Would that be good enough?
  - litewulf 18y ago
    ETags can be arbitrary, the server can put whatever it wants.
    - jbert 18y ago
      Ah, yes. An attacker could fetch the resource themselves, discover the ETag and serve their malicious resource with the real ETag. Sorry.
- m_eiman 18y ago
  I had a similar idea a while ago, and put the results of my brainstorming here: http://eiman.tv/misc/http-content-signature.html http://eiman.tv/misc/http-content-signature.html The idea is to add a signed hash of the content in the HTTP headers, along with a way of verifying the signature. The point of it all is to make it possible to verify the source and integrity of content served from non-HTTPS servers. Feedback welcome!
tlrobinson 18y ago
Also, CSS in IE can contain JavaScript. I'm not sure how much access it has to the DOM though.

three14 18y ago

This is exactly the issue. Once some content on the page is not SSL, you can't trust what you're seeing. Of course, it's easy to fix with an extension to HTML, something like hrefhash="DSKJsdfjsdfs234" so the browser can verify that the referenced resource hasn't been tampered with. Then you can have your non-private data served over HTTP, and cached by the browser and by proxies, and you don't need the extra server side computation of SSL.

jrockway 18y ago
I think browsers should respect HTTP's caching headers, even if the content is served over SSL. If the server says "hey, it's OK to cache this", I don't think the browser should second-guess that. If you want to be ultra-secure, get an extension for your browser that doesn't cache anything.
- three14 18y ago
  I agree. But extending HTML to use a hash for verification has additional benefits. One - proxies can see plain HTTP, but they can't cache HTTPS (I think). Two - you can share the same images for the HTTP and HTTPS pages on your site. And three - you can point to a resource (e.g. a Javascript library, a download link, whatever) that you don't control, but you can now trust that the other site won't change it to something malicious.
  - three14 18y ago
    Just thought of another benefit - if the referenced resource is cached, the browser can save an extra HTTP request that it would have sent to check if the referenced data has been modified. Now it knows, given the hash, that it must be unchanged.
    - jrockway 18y ago
      All good points. I like your idea. I assume most people have frameworks that generate their <script src=...> tags for them, so this shouldn't even require developers to think about it.
jbert 18y ago
You could specify that you expect the referenced resource to be served with a given ETag. Would that be good enough?
- litewulf 18y ago
  ETags can be arbitrary, the server can put whatever it wants.
  - jbert 18y ago
    Ah, yes. An attacker could fetch the resource themselves, discover the ETag and serve their malicious resource with the real ETag. Sorry.
m_eiman 18y ago
I had a similar idea a while ago, and put the results of my brainstorming here: http://eiman.tv/misc/http-content-signature.html http://eiman.tv/misc/http-content-signature.html The idea is to add a signed hash of the content in the HTTP headers, along with a way of verifying the signature. The point of it all is to make it possible to verify the source and integrity of content served from non-HTTPS servers. Feedback welcome!

tlrobinson 18y ago

Also, CSS in IE can contain JavaScript. I'm not sure how much access it has to the DOM though.