Introduce default_headers. closes #6311 #6515 #7302

Merged
merged 2 commits into from Aug 9, 2012

Conversation

Projects
None yet
10 participants
@homakov
Contributor

homakov commented Aug 9, 2012

4.0 feature, everybody agreed to merge it.
Default headers are really useful for various security options and mitigations.

discuss: should we add "Sniff content type" header

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Aug 9, 2012

Member

Related with #6311 and #6515 (commenting since github doesn't link issues at the title)

Member

rafaelfranca commented Aug 9, 2012

Related with #6311 and #6515 (commenting since github doesn't link issues at the title)

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Aug 9, 2012

Member

@homakov Thank you. Could you add some tests?

Member

rafaelfranca commented Aug 9, 2012

@homakov Thank you. Could you add some tests?

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 9, 2012

Contributor

@rafaelfranca thanks, here they are

Contributor

homakov commented Aug 9, 2012

@rafaelfranca thanks, here they are

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 9, 2012

Member

So, it's now considered not best practice to use the X-* pattern when minting new HTTP headers: http://tools.ietf.org/html/rfc6648

Member

steveklabnik commented Aug 9, 2012

So, it's now considered not best practice to use the X-* pattern when minting new HTTP headers: http://tools.ietf.org/html/rfc6648

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 9, 2012

Contributor

@steveklabnik yea have seen it and lold :) this 'over standardizing' looks funny.

You sure all browsers support Frame-Options along X-Frame-Options? if yes I will change it.

Contributor

homakov commented Aug 9, 2012

@steveklabnik yea have seen it and lold :) this 'over standardizing' looks funny.

You sure all browsers support Frame-Options along X-Frame-Options? if yes I will change it.

@homakov

This comment has been minimized.

Show comment
Hide comment
Contributor

homakov commented Aug 9, 2012

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 9, 2012

Member

Is 'X-Frame-Options' an existing header, or a new one? I'm not super familiar with security issues.

If it's old, then obviously, we use it verbatim. If 'browser support' means do browsers can handle a new header without the X- prefix, then yes, as far as I know, they all do.

Member

steveklabnik commented Aug 9, 2012

Is 'X-Frame-Options' an existing header, or a new one? I'm not super familiar with security issues.

If it's old, then obviously, we use it verbatim. If 'browser support' means do browsers can handle a new header without the X- prefix, then yes, as far as I know, they all do.

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 9, 2012

Contributor

@steveklabnik yes, both X- headers are extremely old so we hardly can remove 'X-' prefix.
X-XSS-Protection controls built in IE and Chrome anti xss auditor.
X-Frame-Options detects should website be visible in iframes or not. 99% of websites don't need to be shown in iframes.

Contributor

homakov commented Aug 9, 2012

@steveklabnik yes, both X- headers are extremely old so we hardly can remove 'X-' prefix.
X-XSS-Protection controls built in IE and Chrome anti xss auditor.
X-Frame-Options detects should website be visible in iframes or not. 99% of websites don't need to be shown in iframes.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 9, 2012

Member

Ah! Then continue. I thought they were something new you were making. No worries. TIL.

Member

steveklabnik commented Aug 9, 2012

Ah! Then continue. I thought they were something new you were making. No worries. TIL.

@et

This comment has been minimized.

Show comment
Hide comment
@et

et Aug 9, 2012

+1 These are great defaults that everyone will probably want turned on.

et commented Aug 9, 2012

+1 These are great defaults that everyone will probably want turned on.

@aantix

This comment has been minimized.

Show comment
Hide comment
@aantix

aantix Aug 9, 2012

Contributor

+1 We're currently manually adding these defaults for the current client I am working with. It's coupled with complimentary frame busting code, but that's probably a separate story.

Contributor

aantix commented Aug 9, 2012

+1 We're currently manually adding these defaults for the current client I am working with. It's coupled with complimentary frame busting code, but that's probably a separate story.

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 9, 2012

Contributor

@aantix regards framebusting - make sure you use "modern framekiller" when page is hidden by default and then shown if everything is ok. other framekillers don't work.

c'mon, merge or die trying

Contributor

homakov commented Aug 9, 2012

@aantix regards framebusting - make sure you use "modern framekiller" when page is hidden by default and then shown if everything is ok. other framekillers don't work.

c'mon, merge or die trying

@tenderlove

This comment has been minimized.

Show comment
Hide comment
@tenderlove

tenderlove Aug 9, 2012

Member

Seems good. Thanks @homakov!

Member

tenderlove commented Aug 9, 2012

Seems good. Thanks @homakov!

tenderlove added a commit that referenced this pull request Aug 9, 2012

@tenderlove tenderlove merged commit 6794e92 into rails:master Aug 9, 2012

@drogus

This comment has been minimized.

Show comment
Hide comment
@drogus

drogus Aug 9, 2012

Member

Can we have better commit messages next time? As showed here: http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#commit-your-changes

Member

drogus commented on 98c18d0 Aug 9, 2012

Can we have better commit messages next time? As showed here: http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#commit-your-changes

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 9, 2012

Contributor

@drogus my bad, forgot that commit message is what i write in -m and not in title of PR.

@tenderlove Spasibo :)

Contributor

homakov commented Aug 9, 2012

@drogus my bad, forgot that commit message is what i write in -m and not in title of PR.

@tenderlove Spasibo :)

@@ -41,6 +41,11 @@ class Application < Rails::Application
# Configure sensitive parameters which will be filtered from the log file.
config.filter_parameters += [:password]
+ config.action_dispatch.default_headers = {

This comment has been minimized.

@josevalim

josevalim Aug 9, 2012

Contributor

I don't think these configs should be in config/application.rb, but rather in the action dispatch railtie.

@josevalim

josevalim Aug 9, 2012

Contributor

I don't think these configs should be in config/application.rb, but rather in the action dispatch railtie.

This comment has been minimized.

@homakov

homakov Aug 10, 2012

Contributor

IMO this is a perfect place. Developer sees clearly where and how default headers are defined. Also, how is he supposed to remove them if he doesn't need Frame-Options? We cannot "hardcode" these values.

@homakov

homakov Aug 10, 2012

Contributor

IMO this is a perfect place. Developer sees clearly where and how default headers are defined. Also, how is he supposed to remove them if he doesn't need Frame-Options? We cannot "hardcode" these values.

This comment has been minimized.

@josevalim

josevalim Aug 10, 2012

Contributor

config.action_dispatch.default_headers.clear would clear them. Rails has many defaults, we don't list them all on config/application.rb for a reason. Documentation solves the problem of knowing what is on by default and how to clear it.

@josevalim

josevalim Aug 10, 2012

Contributor

config.action_dispatch.default_headers.clear would clear them. Rails has many defaults, we don't list them all on config/application.rb for a reason. Documentation solves the problem of knowing what is on by default and how to clear it.

@spastorino

This comment has been minimized.

Show comment
Hide comment
@spastorino

spastorino Aug 9, 2012

Member

Can we have a CHANGELOG entry for this?

Member

spastorino commented Aug 9, 2012

Can we have a CHANGELOG entry for this?

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 10, 2012

Contributor

@spastorino do we still add changelog changes in PRs? :) You can add it if dont mind

Contributor

homakov commented Aug 10, 2012

@spastorino do we still add changelog changes in PRs? :) You can add it if dont mind

@spastorino

This comment has been minimized.

Show comment
Hide comment
@spastorino

spastorino Aug 10, 2012

Member

@homakov we shouldn't be merging PRs without CHANGELOG entries or we should merge and add CHANGELOG entries later but I prefer asking contributors for that. I have merged things without CHANGELOG entries but I don't consider that a good practice anyway. I'm guilty too ;).

Member

spastorino commented Aug 10, 2012

@homakov we shouldn't be merging PRs without CHANGELOG entries or we should merge and add CHANGELOG entries later but I prefer asking contributors for that. I have merged things without CHANGELOG entries but I don't consider that a good practice anyway. I'm guilty too ;).

@spastorino

This comment has been minimized.

Show comment
Hide comment
Member

spastorino commented Aug 10, 2012

pushed 0b11dbe

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 10, 2012

Contributor

@spastorino thannnkss :)

@josevalim i see your point but cannot do so. Explicit definition here looks like common sense to me.

for example we have config.filter_parameters += [:password] but we also could have it built in and ask developers to write config.filter_parameters -= [:password] if they don't want to filter passwords. It is a bit 'monkey patching'. Please, let's leave it as is, I think it's a better option.

Contributor

homakov commented Aug 10, 2012

@spastorino thannnkss :)

@josevalim i see your point but cannot do so. Explicit definition here looks like common sense to me.

for example we have config.filter_parameters += [:password] but we also could have it built in and ask developers to write config.filter_parameters -= [:password] if they don't want to filter passwords. It is a bit 'monkey patching'. Please, let's leave it as is, I think it's a better option.

@drogus

This comment has been minimized.

Show comment
Hide comment
@drogus

drogus Aug 11, 2012

Member

To confirm how should we deal with CHANGELOG entries, I've pushed a commit describing it to contributing guide: adf3ea3 I'm serial offender, too, and I probably haven't added CHANGELOG entries to a lot of things myself, but just as with commit messages, I would like to hold any PR that needs fixing this - it may make merging harder and this green button is really tempting, but as we have more commiters and more commits in general, it will be much easier to deal with it this way.

Member

drogus commented Aug 11, 2012

To confirm how should we deal with CHANGELOG entries, I've pushed a commit describing it to contributing guide: adf3ea3 I'm serial offender, too, and I probably haven't added CHANGELOG entries to a lot of things myself, but just as with commit messages, I would like to hold any PR that needs fixing this - it may make merging harder and this green button is really tempting, but as we have more commiters and more commits in general, it will be much easier to deal with it this way.

@spastorino

This comment has been minimized.

Show comment
Hide comment
@spastorino

spastorino Aug 18, 2012

Member

Is there a reason for not adding also "X-Content-Type-Options" => "nosniff" ?.
@homakov what about the other headers you proposed in the first place?

Member

spastorino commented Aug 18, 2012

Is there a reason for not adding also "X-Content-Type-Options" => "nosniff" ?.
@homakov what about the other headers you proposed in the first place?

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 18, 2012

Contributor

@spastorino we should add it too. Yet another header to make IE less mad. Go ahead, it can be default :)

Also, if you will write a tutorial, you can find default_headers feature useful for Access-Control-Allow-Origin and X-Content-Security-Policy which are popular headers(http://recxltd.blogspot.com/2012/03/seven-web-server-http-headers-that.html)

@josevalim now I can see values hardcoded inside of ActionDispatcher. It's OK, but i'm afraid that people will get broken framing by updating rails to 4 ver. They will be surprised :(

Contributor

homakov commented Aug 18, 2012

@spastorino we should add it too. Yet another header to make IE less mad. Go ahead, it can be default :)

Also, if you will write a tutorial, you can find default_headers feature useful for Access-Control-Allow-Origin and X-Content-Security-Policy which are popular headers(http://recxltd.blogspot.com/2012/03/seven-web-server-http-headers-that.html)

@josevalim now I can see values hardcoded inside of ActionDispatcher. It's OK, but i'm afraid that people will get broken framing by updating rails to 4 ver. They will be surprised :(

@aantix

This comment has been minimized.

Show comment
Hide comment
@aantix

aantix Aug 18, 2012

Contributor

@homakov @spastorino @josevalim Just submitted a pull request to add the X-Content-Type-Options header.

#7390

Contributor

aantix commented Aug 18, 2012

@homakov @spastorino @josevalim Just submitted a pull request to add the X-Content-Type-Options header.

#7390

@spastorino

This comment has been minimized.

Show comment
Hide comment
@aantix

This comment has been minimized.

Show comment
Hide comment
@aantix

aantix Aug 21, 2012

Contributor

I don't think any of the other headers, (Cache-Control, X-Content-Security-Policy, Strict-Transport-Security, Access-Control-Allow-Origin) should have defaults.

Contributor

aantix commented Aug 21, 2012

I don't think any of the other headers, (Cache-Control, X-Content-Security-Policy, Strict-Transport-Security, Access-Control-Allow-Origin) should have defaults.

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 21, 2012

Contributor

@spastorino they should be per-app configured.. up to developers.

Contributor

homakov commented Aug 21, 2012

@spastorino they should be per-app configured.. up to developers.

@aantix

This comment has been minimized.

Show comment
Hide comment
@aantix

aantix Aug 21, 2012

Contributor

My comment above agrees with @homakov

Contributor

aantix commented Aug 21, 2012

My comment above agrees with @homakov

@spastorino

This comment has been minimized.

Show comment
Hide comment
@spastorino

spastorino Aug 21, 2012

Member

Yeah, so could be nice to document about them and that as a developer you could change default_headers if you want to.

Member

spastorino commented Aug 21, 2012

Yeah, so could be nice to document about them and that as a developer you could change default_headers if you want to.

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 21, 2012

Contributor

@spastorino I will manage it. As those are mostly security-related headers I want to update this document http://guides.rubyonrails.org/security.html

Contributor

homakov commented Aug 21, 2012

@spastorino I will manage it. As those are mostly security-related headers I want to update this document http://guides.rubyonrails.org/security.html

@spastorino

This comment has been minimized.

Show comment
Hide comment
@spastorino

spastorino Aug 21, 2012

Member

@homakov sure, go ahead

Member

spastorino commented Aug 21, 2012

@homakov sure, go ahead

@aantix

This comment has been minimized.

Show comment
Hide comment
@aantix

aantix Aug 21, 2012

Contributor

@homakov Let me know if you want any help.

Contributor

aantix commented Aug 21, 2012

@homakov Let me know if you want any help.

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 27, 2012

Contributor

@spastorino @aantix guys pls have a look at https://github.com/lifo/docrails/pull/108/files
I described the most common headers. if you wish to add some more headers - welcome. (and, yeah, welcome to fix my grammar :) )

Contributor

homakov commented Aug 27, 2012

@spastorino @aantix guys pls have a look at https://github.com/lifo/docrails/pull/108/files
I described the most common headers. if you wish to add some more headers - welcome. (and, yeah, welcome to fix my grammar :) )

@spastorino

This comment has been minimized.

Show comment
Hide comment
@spastorino

spastorino Aug 27, 2012

Member

@homakov 👍 you're free to push that to docrails

Member

spastorino commented Aug 27, 2012

@homakov 👍 you're free to push that to docrails

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 27, 2012

Contributor

@spastorino yes i pushed :) Just want to see it "here":http://guides.rubyonrails.org/security.html

Contributor

homakov commented Aug 27, 2012

@spastorino yes i pushed :) Just want to see it "here":http://guides.rubyonrails.org/security.html

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 27, 2012

Member

Well it won't be out on that page until a release. And since this went into master, that'd be the release of Rails 4.

Member

steveklabnik commented Aug 27, 2012

Well it won't be out on that page until a release. And since this went into master, that'd be the release of Rails 4.

@frodsan

This comment has been minimized.

Show comment
Hide comment
@frodsan

frodsan Aug 27, 2012

Contributor

Also, you will see it "here":http://edgeguides.rubyonrails.org/security.html when docrails changes get merged in master.

Contributor

frodsan commented Aug 27, 2012

Also, you will see it "here":http://edgeguides.rubyonrails.org/security.html when docrails changes get merged in master.

@homakov

This comment has been minimized.

Show comment
Hide comment
@homakov

homakov Aug 27, 2012

Contributor

@steveklabnik @frodsan got it, no rush.
I think mass assignment section also will need to get updated when we get strong_parameters merged.

Contributor

homakov commented Aug 27, 2012

@steveklabnik @frodsan got it, no rush.
I think mass assignment section also will need to get updated when we get strong_parameters merged.

@aantix

This comment has been minimized.

Show comment
Hide comment
@aantix

aantix Aug 28, 2012

Contributor

@spastorino @homakov I added some clarifications to the security documentation surrounding what the default values are and how to clear them.

https://github.com/lifo/docrails/pull/109

Contributor

aantix commented Aug 28, 2012

@spastorino @homakov I added some clarifications to the security documentation surrounding what the default values are and how to clear them.

https://github.com/lifo/docrails/pull/109

@spastorino

This comment has been minimized.

Show comment
Hide comment
@spastorino

spastorino Aug 29, 2012

Member

@aantix as @fxn told you, please push the changes directly to docrails, everyone has commit bit there :)

Member

spastorino commented Aug 29, 2012

@aantix as @fxn told you, please push the changes directly to docrails, everyone has commit bit there :)

@aantix

This comment has been minimized.

Show comment
Hide comment
@aantix

aantix Aug 29, 2012

Contributor

@spastorino Merged in my changes.

Contributor

aantix commented Aug 29, 2012

@spastorino Merged in my changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment