Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ruby: Add rb/weak-cookie-configuration query #7313

Merged
merged 15 commits into from Jan 5, 2022
Merged

Conversation

@alexrford
Copy link
Contributor

@alexrford alexrford commented Dec 5, 2021

This PR adds a query to check for potential weak cookie configuration options for Rails - in theory we could extend this to cover other frameworks.

The defaults for Rails seem quite safe here, so we only look for cases where these defaults are overriden. In particular, we check for three settings in non-test configuration:

  • config.action_dispatch.encrypted_cookie_cipher set to a cipher that we believe to be weak
  • config.action_dispatch.use_authenticated_cookie_encryption set to false
  • config.action_dispatch.cookies_same_site_protection set to either :none/"none"/etc. or nil

In the last of these, the option can also be set to a proc that can take a request and behave differently depending on this request - this PR doesn't cover that case.

@alexrford alexrford added the Ruby label Dec 5, 2021
@alexrford alexrford requested a review from as a code owner Dec 5, 2021
@alexrford alexrford force-pushed the ruby/rails-cookie-config branch from b6cd9ae to 3128380 Dec 6, 2021
@alexrford alexrford force-pushed the ruby/crypto-algorithms branch from b80633a to 0481385 Dec 11, 2021
@alexrford alexrford force-pushed the ruby/rails-cookie-config branch from 3128380 to d69e5f1 Dec 13, 2021
Copy link
Contributor

@nickrolfe nickrolfe left a comment

Very nice!

@@ -0,0 +1,2 @@
lgtm,codescanning
Copy link
Contributor

@nickrolfe nickrolfe Dec 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new guidance in #7400 suggests this changenote should go in ruby/ql/src/change-notes.

Copy link
Contributor

@dbartol dbartol Dec 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. Also, note the new format for the metadata at the top of the change note.

Copy link
Contributor Author

@alexrford alexrford Dec 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hopefully in the correct format now.

ruby/ql/lib/codeql/ruby/Concepts.qll Outdated Show resolved Hide resolved
loc.getFile().getStem() = "test"
}

private DataFlow::Node getTransitiveReceiver(DataFlow::CallNode c) {
Copy link
Contributor

@nickrolfe nickrolfe Dec 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this predicate is equivalent to c.getReceiver+().

Copy link
Contributor Author

@alexrford alexrford Dec 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! For some reason I thought that +/* relied on the result type being guaranteed to have a member predicate with the same name and result type, but this doesn't seem to be the case.

Copy link
Contributor

@nickrolfe nickrolfe left a comment

LGTM

@alexrford
Copy link
Contributor Author

@alexrford alexrford commented Dec 16, 2021

I'll hold off on merging this until #7273 is in.

@alexrford alexrford force-pushed the ruby/crypto-algorithms branch from cb516f8 to 3da98ec Dec 22, 2021
@alexrford alexrford requested review from as code owners Dec 22, 2021
Base automatically changed from ruby/crypto-algorithms to main Dec 22, 2021
@alexrford alexrford force-pushed the ruby/rails-cookie-config branch from 38822b6 to 7d3932d Dec 22, 2021
@alexrford alexrford marked this pull request as draft Dec 22, 2021
@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Dec 22, 2021

QHelp previews:

ruby/ql/src/queries/security/cwe-732/WeakCookieConfiguration.qhelp

Weak cookie configuration

Cookies can be used for security measures, such as authenticating a user based on cookies sent with a request. Misconfiguration of cookie settings in a web application can expose users to attacks that compromise these security measures.

Recommendation

Modern web frameworks typically have good default configuration for cookie settings. If an application overrides these settings, then take care to ensure that these changes are necessary and that they don't weaken the cookie configuration.

Example

In the first example, the value of config.action_dispatch.cookies_same_site_protection is set to :none. This has the effect of setting the default SameSite attribute sent by the server when setting a cookie to None rather than the default of Lax. This may make the application more vulnerable to cross-site request forgery attacks.

In the second example, this option is instead set to :strict. This is a stronger restriction than the default of :lax, and doesn't compromise on cookie security.

module App
  class Application < Rails::Application
    # Sets default `Set-Cookie` `SameSite` attribute to `None`
    config.action_dispatch.cookies_same_site_protection = :none

    # Sets default `Set-Cookie` `SameSite` attribute to `Strict`
    config.action_dispatch.cookies_same_site_protection = :strict
  end
end

References

@alexrford
Copy link
Contributor Author

@alexrford alexrford commented Dec 22, 2021

Leaving a note-to-self to double check this, as the merge conflict resolution for Rails.qll was a little bit hairy.

@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Jan 4, 2022

QHelp previews:

ruby/ql/src/queries/security/cwe-732/WeakCookieConfiguration.qhelp

Weak cookie configuration

Cookies can be used for security measures, such as authenticating a user based on cookies sent with a request. Misconfiguration of cookie settings in a web application can expose users to attacks that compromise these security measures.

Recommendation

Modern web frameworks typically have good default configuration for cookie settings. If an application overrides these settings, then take care to ensure that these changes are necessary and that they don't weaken the cookie configuration.

Example

In the first example, the value of config.action_dispatch.cookies_same_site_protection is set to :none. This has the effect of setting the default SameSite attribute sent by the server when setting a cookie to None rather than the default of Lax. This may make the application more vulnerable to cross-site request forgery attacks.

In the second example, this option is instead set to :strict. This is a stronger restriction than the default of :lax, and doesn't compromise on cookie security.

module App
  class Application < Rails::Application
    # Sets default `Set-Cookie` `SameSite` attribute to `None`
    config.action_dispatch.cookies_same_site_protection = :none

    # Sets default `Set-Cookie` `SameSite` attribute to `Strict`
    config.action_dispatch.cookies_same_site_protection = :strict
  end
end

References

@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Jan 4, 2022

QHelp previews:

ruby/ql/src/queries/security/cwe-732/WeakCookieConfiguration.qhelp

Weak cookie configuration

Cookies can be used for security measures, such as authenticating a user based on cookies sent with a request. Misconfiguration of cookie settings in a web application can expose users to attacks that compromise these security measures.

Recommendation

Modern web frameworks typically have good default configuration for cookie settings. If an application overrides these settings, then take care to ensure that these changes are necessary and that they don't weaken the cookie configuration.

Example

In the first example, the value of config.action_dispatch.cookies_same_site_protection is set to :none. This has the effect of setting the default SameSite attribute sent by the server when setting a cookie to None rather than the default of Lax. This may make the application more vulnerable to cross-site request forgery attacks.

In the second example, this option is instead set to :strict. This is a stronger restriction than the default of :lax, and doesn't compromise on cookie security.

module App
  class Application < Rails::Application
    # Sets default `Set-Cookie` `SameSite` attribute to `None`
    config.action_dispatch.cookies_same_site_protection = :none

    # Sets default `Set-Cookie` `SameSite` attribute to `Strict`
    config.action_dispatch.cookies_same_site_protection = :strict
  end
end

References

@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Jan 4, 2022

QHelp previews:

ruby/ql/src/queries/security/cwe-732/WeakCookieConfiguration.qhelp

Weak cookie configuration

Cookies can be used for security measures, such as authenticating a user based on cookies sent with a request. Misconfiguration of cookie settings in a web application can expose users to attacks that compromise these security measures.

Recommendation

Modern web frameworks typically have good default configuration for cookie settings. If an application overrides these settings, then take care to ensure that these changes are necessary and that they don't weaken the cookie configuration.

Example

In the first example, the value of config.action_dispatch.cookies_same_site_protection is set to :none. This has the effect of setting the default SameSite attribute sent by the server when setting a cookie to None rather than the default of Lax. This may make the application more vulnerable to cross-site request forgery attacks.

In the second example, this option is instead set to :strict. This is a stronger restriction than the default of :lax, and doesn't compromise on cookie security.

module App
  class Application < Rails::Application
    # Sets default `Set-Cookie` `SameSite` attribute to `None`
    config.action_dispatch.cookies_same_site_protection = :none

    # Sets default `Set-Cookie` `SameSite` attribute to `Strict`
    config.action_dispatch.cookies_same_site_protection = :strict
  end
end

References

@alexrford alexrford marked this pull request as ready for review Jan 4, 2022
@tausbn
Copy link
Contributor

@tausbn tausbn commented Jan 4, 2022

It's not clear to me why this needs a review from the Python team. Am I missing something?

@alexrford alexrford removed request for Jan 4, 2022
@alexrford
Copy link
Contributor Author

@alexrford alexrford commented Jan 4, 2022

It's not clear to me why this needs a review from the Python team. Am I missing something?

Thanks for noticing this, the Python and JS review requests weren't necessary. They were left over from before the merge conflict was resolved (as this PR included changes to CryptoAlgorithms.qll that were merged in #7273).

}
}

private class LiteralSetting extends Setting {
Copy link
Contributor

@nickrolfe nickrolfe Jan 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed some results for this class are actually reads, not writes. For example: https://github.com/gitlabhq/gitlabhq/blob/6d29831123c8c806dc75d64e29b7691576cbea7f/lib/gitlab/database.rb#L187

It's a private class, and the way it gets used with specific setter method names means it should be ok, but I wonder if we should save ourselves some headaches for future uses, either by restricting the class more, or adding a note in a comment.

Copy link
Contributor Author

@alexrford alexrford Jan 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely makes sense to restrict these classes further - I've restricted Setting nodes to ones that correspond to a SetterMethodCall.

@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Jan 5, 2022

QHelp previews:

ruby/ql/src/queries/security/cwe-732/WeakCookieConfiguration.qhelp

Weak cookie configuration

Cookies can be used for security measures, such as authenticating a user based on cookies sent with a request. Misconfiguration of cookie settings in a web application can expose users to attacks that compromise these security measures.

Recommendation

Modern web frameworks typically have good default configuration for cookie settings. If an application overrides these settings, then take care to ensure that these changes are necessary and that they don't weaken the cookie configuration.

Example

In the first example, the value of config.action_dispatch.cookies_same_site_protection is set to :none. This has the effect of setting the default SameSite attribute sent by the server when setting a cookie to None rather than the default of Lax. This may make the application more vulnerable to cross-site request forgery attacks.

In the second example, this option is instead set to :strict. This is a stronger restriction than the default of :lax, and doesn't compromise on cookie security.

module App
  class Application < Rails::Application
    # Sets default `Set-Cookie` `SameSite` attribute to `None`
    config.action_dispatch.cookies_same_site_protection = :none

    # Sets default `Set-Cookie` `SameSite` attribute to `Strict`
    config.action_dispatch.cookies_same_site_protection = :strict
  end
end

References

Copy link
Contributor

@nickrolfe nickrolfe left a comment

lgtm

@alexrford alexrford merged commit f935df9 into main Jan 5, 2022
28 checks passed
@alexrford alexrford deleted the ruby/rails-cookie-config branch Jan 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants