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?
In many cases, browsers don't need to consult the Content-Type header in order to understand what kind of content they are currently processing. If the content begins with an <html> tag, it will most likely be interpreted using the mime type (text/html) and be treated as an HTML file. Similarly, if a certain file doesn't have a proper mime type but is included via a script src attribute, browsers assume that its content-type was meant to be application/javascript.
This is also known as Mime Type Sniffing. However, this behaviour is not free from security implications. Think of an upload functionality, for example. Let's suppose that a user is allowed to upload text files. This doesn't seem dangerous at first. But if the server doesn't return a proper Content-Type, it's possible for a user to upload a file that contains HTML tags and JavaScript code. If you were to visit the page with a browser that attempts to find out which Content-Type was intended, it will probably recognize the HTML tags in the file and render the content as if the text/html Content-Type header was set.
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 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:
- text/html
- text/xml
- application/xml
- application/rss+xml
- application/json
- text/json
- text/x-json
- text/plain
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 like 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.
The post Netsparker’s Weekly Security Roundup 2018 – Week 04 appeared first on Security Boulevard.
from Netsparker’s Weekly Security Roundup 2018 – Week 04
