This is an archive post from the Netsparker (now Invicti) blog. Please note that the content may not reflect current product names and features in the Invicti offering.
Every security researcher should develop their skills in reading and understanding RFCs. While they may not provide an exciting read, they still can help you decipher how certain protocols work and what obstacles developers might face while attempting to implement them.
Here is one example of an RFC text.
This text was the taken from RFC 7231 and explains those cases in which the server should send a Content-Type header. For those not familiar with the vocabulary in these documents, they contain various key words for developers, to help them correctly implement the protocol's features. The keyword 'SHOULD' from the sample RFC has a very specific meaning. It is defined in RFC 2119 Key words for use in RFCs to Indicate Requirement Levels as follows:
This word, or the adjective 'RECOMMENDED', means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
This means that developers don't necessarily have to implement functionality with the 'SHOULD' key word, if they have good reason.
But what happens if the server doesn't send a proper Content-Type header? How do web browsers deal with this scenario?
What is Mime Type Sniffing?
However, it's possible to prevent a browser from correcting the mime type. The way to do this is to set a header called X-Content-Type-Options with its only allowed value nosniff. You may have seen this header already, but probably didn't think it was of great importance. The truth is that X-Content-Type-Options is an important header in terms of security, especially since it allows Site-Isolation to be used.
What is Site-Isolation?
Site Isolation is a new feature that was introduced with Google Chrome 63. Simply put, different origins now run in different processes, regardless of whether they are loaded in a different tab, the same tab, or even in an iframe.
The Universal XSS (uXSS) is an XSS type that results from a vulnerability in the browser itself and allows you to access the DOM from different origins. But is this isolation even necessary, if we already have the Same Origin Policy (SOP)? Well, SOP continues to be the most important building block in terms of client-side security features in relation to managing resources of different origins. But what happens if there is a Universal XSS (uXSS) vulnerability that allows an attacker to bypass the Same Origin Policy?
This is where Site Isolation comes into play. The content of HTML, JSON and XML files are maintained as separate processes and won't be shared with other processes unless otherwise specified by CORS headers. So even if you were able to include a JSON file from a different origin, Chrome decides whether or not to use a different process for any given file by looking at the Content-Type header. The following Content-Types may be opened in a new process:
In addition to the correct Content-Type, you need to make sure to include the X-Content-Type-Options: nosniff.
What You Need to Know About Site Isolation
Site Isolation is available, but turned off by default in Chrome 63 and above. If you want to enable it, you need to enter chrome://flags/#enable-site-per-process into your browser and enable Site Isolation. The changes will take effect as soon as you restart the browser.
Additionally, it's possible to enable Site Isolation for specific sites. This is a little bit more complicated than the option we mentioned above, since you need to pass an additional parameter to Chrome when you start it. You can do this by passing flags to the chrome executable. The flag --isolate-origins=https://google.com,https://youtube.com will therefore enable this feature for google.com and youtube.com only.
Another caveat is that HTTP Range Requests don't work as separate process, due to their Content-Type (multipart/byteranges). For sensitive files, you should disable HTTP Range Requests, if you want your users to benefit from Site Isolation.
But this isn't the only current disadvantage. When Site Isolation is enabled for every website, you might notice an increased resource consumption of an additional 10-20%. That's why it's recommended to only protect certain sites with this feature. Additionally, this technology is not free from bugs. If you print a website, the iframes that are displayed on the page will be empty and in some cases clicks and page scrolling won't work as expected within iframes.
Yet again, it seems that better security measures come at the cost of worse user experience. It's hard to say if Chrome will get rid of the bugs in iframes, and whether the performance hits can be mitigated. However, if you want to be extra careful and can live with the occasional bug, or if you have a powerful high-end PC that can deal with 10-20% higher resource consumption, Site Isolation is a great feature that's worth testing.