Security Related Headers check failed, to fix or not to fix and how?

[thesp0nge]

Security Related Headers check failed, to fix or not to fix and how?

[thesp0nge]

Hi guys, I'll double check how rails 4 handle those headers and eventually I'll disable the check for rails version >=4

[intinig]

Same problem here, and same question.

[intinig]

thx :)

On Thu, Mar 6, 2014 at 1:41 PM, Paolo Perego [email protected]:

Hi guys, I'll double check how rails 4 handle those headers and eventually
I'll disable the check for rails version >=4

Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-36884018
.

[intinig]

Still here in latest update :)

[thesp0nge]

Because I didn't disable check family for rails 4.x automagically yet.
In next version, 1.1.0 you can disable the family with --disable-owasp-ror-cheatsheet

[jcoyne]

It's not the whole family that should be ignored, right? Just this one check in particular?

[thesp0nge]

With --disable-owasp-ror-cheatsheet you disable (or you should :-)) all
Owasp RoR Cheatsheet checks. So the whole family

On 4 April 2014 14:30, Justin Coyne [email protected] wrote:

It's not the whole family that should be ignored, right? Just this one
check in particular?

Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-39559513
.

$ cd /pub
$ more beer

The Application Security blog you really want to read:
http://armoredcode.com

[shaneog]

If you disable all you miss certain other ones. For example a Rails 4 app I am working on fails 2 checks (only one of which is Owasp Ror CheatSheet: Security Related Headers check failed) but if I use --disable-owasp-ror-cheatsheet then it fails none.

[thesp0nge]

Very strange @shaneog... I turn this from "question" to "bug" so and I'll investigate furher. Can you provide me a skeleton of this app (just the gems) in order to replicate?

[shaneog]

Sure, I'll create a sample app with the same gems very shortly and post a link here.

[shaneog]

I used a previous Rails 4 sample app. Same problem.
https://github.com/shaneog/c3-puma-test

Output below:

$ dawn .
14:06:03 [*] dawn v1.1.0 is starting up
14:06:04 [$] dawn: scanning .
14:06:04 [$] dawn: rails v4.0.4 detected
14:06:04 [$] dawn: applying all security checks
14:06:04 [$] dawn: 171 security checks applied - 0 security checks skipped
14:06:04 [$] dawn: 2 vulnerabilities found
14:06:04 [!] dawn: Owasp Ror CheatSheet: Session management check failed
14:06:04 [$] dawn: Severity: info
14:06:04 [$] dawn: Priority: unknown
14:06:04 [$] dawn: Description: By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.
14:06:04 [$] dawn: Solution: Use ActiveRecord or the ORM you love most to handle your code session_store. Add "Application.config.session_store :active_record_store" to your session_store.rb file.
14:06:04 [$] dawn: Evidence:
14:06:04 [$] dawn:  In your session_store.rb file you are not using ActiveRercord to store session data. This will let rails to use a cookie based session and it can expose your web application to a session replay attack.
14:06:04 [$] dawn:  {:filename=>"./config/initializers/session_store.rb", :matches=>[]}
14:06:04 [!] dawn: Owasp Ror CheatSheet: Security Related Headers check failed
14:06:04 [$] dawn: Severity: info
14:06:04 [$] dawn: Priority: unknown
14:06:04 [$] dawn: Description: To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter). Rails 4 provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases.
14:06:04 [$] dawn: Solution: Use response headers like X-Frame-Options, X-Content-Type-Options, X-XSS-Protection in your project.
14:06:04 [$] dawn: Evidence:
14:06:04 [$] dawn:  {:filename=>"./app/controllers/application_controller.rb", :matches=>[]}
14:06:04 [*] dawn is leaving
$ dawn . --disable-owasp-ror-cheatsheet
14:06:09 [*] dawn v1.1.0 is starting up
14:06:09 [$] dawn: scanning .
14:06:09 [$] dawn: rails v4.0.4 detected
14:06:09 [$] dawn: applying all security checks
14:06:09 [$] dawn: 164 security checks applied - 0 security checks skipped
14:06:09 [*] dawn: no vulnerabilities found.
14:06:09 [*] dawn is leaving

[jprince]

These are default headers in Rails 4 - how has this not been fixed in two years? I would prefer not to have to disable all of the ror cheatsheet checks just because of this one warning. Any suggestions?

[jcoyne]

@jprince with OSS projects you don't get to demand that other people do work for free. If you want it, why don't you submit a pull request, or fund a developer to do it?

[thesp0nge]

Hi @jprince this is not fixed in 2 years because from a security perspective, those are not a priority. I receive very few pull requests, so I have to dedicate myself to high priority issues that, at this stage, are adding CVE to the library.

Please note that the cheatsheet is pretty unmaintained too.

[jprince]

@thesp0nge understandable. I was thinking about opening a PR over the weekend that would ignore a particular check if the user's MVC version is above the version in which the vulnerability was addressed. So essentially something where the check's initialization function would have an additional attribute:

...
:applies=>["rails"],
:fix_version=>'4.0',
...

Then the applies_to? function could be modified to take the MVC version in addition to the name, and only run checks that are not know to be fixed in the user's installed version. Let me know if you think that'd be worthwhile.