Posted by greggles on January 4, 2018 at 5:23pm
The chromium project blog post about meltdown/spectre has some advice for web applications to increase their security in case a client has not upgraded.
Quoting the 3 main bullet points:
- Where possible, prevent cookies from entering the renderer process' memory by using the SameSite and HTTPOnly cookie attributes, and by avoiding reading from document.cookie.
- Don’t serve user-specific or sensitive content from URLs that attackers can predict or easily learn. Attackers can load such URLs in their attack pages (e.g.
<img src=”https://email.example.com/inbox.json”/>) to get the sensitive information into the process rendering their page, and can then use out-of-bounds reads to discover the information. Use anti-CSRF tokens and SameSite cookies, or random URLs to mitigate this kind of attack. - Make sure your MIME types are correct and specify a nosniff header for any URLs with user-specific or sensitive content, to get the most out of cross-site document blocking for users who have Site Isolation enabled.
About addressing these in Drupal:
- HTTPOnly cookies in Drupal/Apache/Nginx are pretty standard for a while now. The owasp wiki on samesite has some good info. However it appears that PHP has an RFC about samesite support that may not be added until 7.3
- Drupal generally uses very predictable urls, so this is a concern. It's possible some kind of module that looks for an extra url param on a list of sensitive urls (e.g. along the lines of what is done in haubergeon) could be helpful.
- There's probably some opportunity for more work on mime types and nosniff in the default .htaccess file
Comments
Tip 2 removed from Chromium article
It may be worth noting that Chromium have since removed tip 2: "Don’t serve user-specific or sensitive content from URLs that attackers can predict or easily learn ..." from their article.
A comment was given here: https://twitter.com/fugueish/status/949025331234533376
It seems they removed it
It seems they removed it because of confusion, not because it is an unnecessary protection for sites that serve sensitive content on well known urls.
knaddison blog | Morris Animal Foundation
That might be. I'm no
That might be. I'm no security expert. I just noted it was gone.
The confusion was that people believed that pages like this: https://mail.google.com/mail/u/0/#inbox would be considered insecure (since that URL is the same for everyone logged in to gmail), which is not what this is about, right?
As I understand it the issue is limited to subresources, which I guess is json-documents for example. And that text/html mimetype is not considered to be such a subresource.
Sorry, just trying to learn more about this.
client security vs server side security
The key here is to recognise that the suggested measures concern vulnerabilities which might be exploited on the client system, not on the server.
You can only get at information on another Google user's page if you can get that page loaded as the relevant user on a vulnerable system.
Yes, I didn't state this
Yes, I didn't state this clearly in the original post, but I sort of assume everyone knows "upgrade your kernel and consider other general mitigation strategies" as a first step of protecting Drupal sites on the server side.
The angle I thought would be good to cover in this discussion is "As a Drupal site owner who is concerned about the security of the Drupal app being served to browser, and who knows that those browsers are less likely to upgrade in a timely manner, what protections are appropriate?" Whether a site is an e-commerce site or just used to control sensitive information, having sessions or private data exposed by malicious javascript in a browser tab is pretty scary.
knaddison blog | Morris Animal Foundation
Yeah, having thought through
Yeah, having thought through how this can be exploited (both ease of distribution and potential ease of implementation), this is rather scary. Site isolation options and mitigations in browsers help, but it would be a good idea to be forward thinking here to prevent these types of things.
I'm wondering if we need to default
X-Frame-Options: SAMEORIGINmoving forward, and add this to the security hardening page in the handbook (if it isn't on it already).I think we need to open a core issue to add a new route option,
_sensitivethat would append a CRSF token and 403 the page if it it isn't present exist. Could also be handled in contrib.Drupal 7 and 8 already emit
Drupal 7 and 8 already emit
X-Frame-Options: SAMEORIGINby defaultCheck Your Server Environment
Thanks for starting this @greggles - one point that is pretty obvious but probably should be stated is that server environments, and the kernel specifically need to be updated (and the server needs to be restarted).
If you've got root access to the box & the skills to do this, make sure your servers are up-to-date.
If you don't have root access, I think you can still use tools like this to verify if the new kernel has been applied.
https://www.cyberciti.biz/faq/check-linux-server-for-spectre-meltdown-vu...
Even simpler, if you've only got shell access, you should be able to check when the server was last reboot. For the kernel updates to be applied, the server needs to be rebooted.
$ uptime -pThat won't tell you if it's been correctly applied, but at least will give you some sense that someone has looked at it.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Hi Greg.Thank you for
Hi Greg.
Thank you for sharing your thoughts on Spectre/Meltdown.
Let’s admit that none of these could be mitigated on the Drupal level. Thank you for pointing out to some generic security techniques, though.
Imaging a large-scale deployment of shared accounts, whether these are VPS/containers or good old shared hosting.
As long as a single VPS/account/container gets compromised, attackers could exploit Meltdown and Spectre (there are a few variants of those, some of them are covered by the kernel upgrade, others require BIOS upgrade with the rest are still WIP by the Linux vendors) - access to server memory could be gained and information read (including passwords, credit cards and so on). There is NOTHING you could do on your Drupal side to protect against that.
It's true that the
It's true that the server-side Operating System and CPU level issues cannot be mitigated by Drupal. That's something that can only be addressed:
Here I hope to problem-solve about the web-related risks to an HTTP client computer with a vulnerable browser, vulnerable client operating system, where the browser is running malicious javascript. For that I believe there are some recommendations (from the document I linked) of what can be done at Drupal and webserver levels.
knaddison blog | Morris Animal Foundation