Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[HttpKernel] [FrameworkBundle] Introduce Rails-like default response headers to control browser-side security features#8515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
…assign necessary-everywhere headers
…with X-Content-Type-Options support by default)
co3k commentedJul 18, 2013
Additional informations: I strongly think we should add I know good (bad?) example about such a vulnerability, theCVE-2013-1297, is NOT fixed in IE9 and IE10. (In IE6, IE7 and IE8, this vuln has been fixed byMS13-037) The reporter, Yousuke Hasegawa, says "In Internet Explorer 9 and 10, attacker can read remote JSON array yet." inhis blog entry (sadly there are no English informations). This attack is that the vulnerable IE reads remote JSON content as VBScript by using And according to Hasegawa, "About IE9 and IE10 needs X-Content-Type-Options to avoid this problem, Microsoft says this behavior is based on its specification." I thinkCVE-2013-1297 itself is not really big problem, in my opinion, a truly big problem is Microsoft looks like standing "the response with a valid Content-Type, as a matter of course, it must send X-Content-Type-Options too"... If so, bad, this is bad, but this problem is really exist, so adding Nonetheless, for the good web frameworks or applications like symfony, there is no reason for relying MIME-type sniffing because they always send a valid Content-Type. |
lsmith77 commentedJul 18, 2013
@Seldaek you probably have some comments on this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This will replace any custom header set in the controller.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I don't think so, this method call sets false as the third argument ($replace), and it is already tested the existing header wouldn't be overwritten.
stof commentedJul 18, 2013
NelmioSecurityBundle already allows setting these security headers for you, and it provides a semantic configuration instead of asking the developer to know the exact syntax of each header in the config file. and for the CORS header,NelmioCorsBundle allows configuring it fully (which cannot be done by hardcoding some header values in the config file). Thus, your default config for |
co3k commentedJul 18, 2013
Oh I didn't know about the NelmioSecurityBundle bundle. It seems better than my implementation (give the code a once-over), but it doesn't provide Adding some supports for My default header config misleading. You're right. But it is difficult problem because this configuration shouldn't overwrite user defined headers, of course... |
Seldaek commentedJul 25, 2013
@ebihara there is a PR open on NelmioSecurityBundle for CSP support, which one merged will make the bundle cover most things you mentionned here. As for X-Content-Type-Options, I wouldn't be against a pull request to add it to the bundle as well. I don't know if this really belongs in the framework itself because having smart defaults that fit everyone is a bit hard. It's good to make it easy to enable these features, but I don't necessarily agree that forcing them on everyone is a good thing. |
fabpot commentedJul 25, 2013
As there is already a good bundle that covers most of these things and because@Seldaek is fine with adding some missing stuf, I'm closing this PR in favor of improving the bundle. |
Rails 4 provides new
default_headersto send some security headers by default. Such headers control browser-side security features.It is also good for Symfony because it provides transparent security to users like output escaping and CSRF protection.
TODO
(NOTE: adding this feature is finished, I think, but we should consider about default configurations as I discuss later)
Security headers?
Modern web browsers provide some security features (to mitigate effects of frequent vulnerabilities, or to avoid new attack methods e.g. Clickjacking). To use them, setting via response headers like the followings:
About browser support situations, you can get information fromhttp://www.browserscope.org/?category=security
Configuration
User can configure default response header like the following:
Default Configuration
I think about the default configuration is very important and we need to discuss since it may affect existing projects. (Currently, only
X-Content-Type-Options: sniffis defined as default header)X-Content-Type-Options: sniffis almost essential because Symfony always sends a valid Content-Type so it keeps current behaviours.And also
X-XSS-Protection: 1; mode=blockdoes not break anything, but in false-negative situation, the end-user will see a white-screen-of-death (by block-mode of XSS filter) instead of corrupt HTML string (by default-mode).X-Frame-Optionsis the missing protection against Clickjacking but it damages iframe-embed page so we cannot adopt this as default but we should recommend use this.Content Security Policy is a very powerful feature but it might be difficult for many users to control.
A preferred value of
Strict-Transport-Security,X-UA-CompatibleandAccess-Control-Allow-Origincannot be decided without user's judgment.FYI, here is the default configuration of Rails 4:
References