Open Bug 1205143 Opened 9 years ago Updated 4 months ago

SRI checks not performed on stylesheets in internal per-page cache

Categories

(Core :: DOM: Security, defect, P3)

Product:
Core
Component:
DOM: Security
Type:
defect

Tracking

()

People

(Reporter: francois, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-backlog2])

Attachments

(1 file)

Test case
1.89 KB, patch
Details | Diff | Splinter Review 
Actual:

If a stylesheet is already in the cache and then we try to load it with an invalid SRI hash, it loads just fine.

Expected:

The stylesheet is blocked by SRI.
I looked deeper into this and it's not the network cache that's involved but rather the per-document cache:

https://dxr.mozilla.org/mozilla-central/rev/9ed17db42e3e46f1c712e4dffd62d54e915e0fac/layout/style/Loader.cpp#1124

If a stylesheet was loaded and parsed successfully once, we don't parse it again, we just clone the in-memory data structure.

I can't really think of an attack for this because to skip the SRI checks, someone has to load the stylesheet without SRI first in the document and then load it again with the wrong SRI hash in the **same** document.

Fixing this would involve removing this in-memory cache in the presence of SRI, which doesn't seem worth it.

What would you guys suggest?
Flags: needinfo?(mozilla)
Flags: needinfo?(dveditz)
Attached patch Test case — — Splinter Review 
Group: core-security
Flags: needinfo?(mozilla)
Flags: needinfo?(dveditz)

    
    

    
  
Francois met w/Christoph and me and we decided it's OK if we only check SRI the first time the sheet is loaded in a page. If the same sheet appears multiple times in a page with different SRI that's an edge case and possibly a bug in the page.

    
    

    
  
I mentioned this edge case on the W3C webappsec list: https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0108.html

    
    

    
  
I think what's problematic is that we end up dispatching different events on the <link> element from other browsers (unless the cache is standardized somehow). If this was not observable that would not be so bad, but it is.

    
  
Summary: SRI checks not performed on cached stylesheets → SRI checks not performed on stylesheets in internal per-page cache

    
  
Assignee: francois → nobody
Status: ASSIGNED → NEW
Whiteboard: [domsecurity-backlog]
Priority: -- → P2
Priority: P2 → P3
Whiteboard: [domsecurity-backlog] → [domsecurity-backlog2]

    
  
Severity: normal → S3

    
    

    
  
I recently stumbled upon this bug, however in a slightly different setting:


    

  • A page loads a css file without sri, the css file is cached.
    • 

  • The same page is reloaded, on reload the css is loaded with a bad sri hash.
    • 



This will load and interpret the css file on the second page load. I have put together an example (implemented in PHP) here: https://sri.q2.re/


I couldn't come up with a scenario where this leads to a security problem, but it surely is quite surprising and unexpected behavior.


FWIW, here's the example PHP code (test.css contains just "p {color:red;}"):


<?php

if (!isset($_COOKIE["load"])) {
    setcookie("load", "1", time()+120);
?><!DOCTYPE html><html><head><title>test</title>
<link rel="stylesheet" href="https://sriassets.q2.re/test.css">
<meta http-equiv="refresh" content="2">
</head><body>Wait a few seconds..
<?php

} else {
?><!DOCTYPE html><html><head><title>test</title>
<link rel="stylesheet" href="https://sriassets.q2.re/test.css" integrity="sha256-badhashbadhashbadhashbadhashbadhashRCJkxxyo=">
</head><body><p>This is red, styled with CSS with a bad SRI hash.</p>
<?php
}




          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: