-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
KTOR-6695 Add configuration warning when nothing is provided for CSRF #3968
Conversation
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.
Can you explain how the fix is related to the https://youtrack.jetbrains.com/issue/KTOR-6695?
Yes, my assertion is that the default behaviour not enabling any validation is important, but we ought to inform the developer that it's not a valid configuration for CSRF. As for the phrasing of "allow", I don't have any ideas atm. The current choice was just to maintain some similarity with CORS, but I understand the behaviour is different. |
It might be important, but I don't see how the current changes fix the problem from the linked YouTrack issue. |
From what I understood, this issue is twofold: 1) nothing happens with the empty config, and 2) |
d389737
to
e56d8b4
Compare
e56d8b4
to
cc90d8e
Compare
After discussing with @e5l, I've updated the default behaviour for this to block any non-local origins - so when the configuration is empty, you'll only be able to connect to localhost, 127.0.0.1, and 0.0.0.0. There's an informative log message when this happens. |
cc90d8e
to
4eb0755
Compare
@@ -38,6 +38,19 @@ public val CSRF: RouteScopedPlugin<CSRFConfig> = createRouteScopedPlugin("CSRF", | |||
val headerChecks = pluginConfig.headerChecks | |||
val onFailure = pluginConfig.handleFailure | |||
|
|||
if (!checkHost && allowedOrigins.isEmpty() && headerChecks.isEmpty()) { |
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.
Just to clarify, are the local host origins always allowed?
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.
No, when you provide some configuration it's exactly what you provide. I don't think allowing them all the time would expose any vulnerabilities, unless the attacker manages to get a server running on the victim's local machine or something, though it's probably safer to leave it like this.
Subsystem
Server, CSRF
Motivation
Solution
After thinking about how to provide some default behaviour for the CSRF plugin, I am of the opinion that it would be unwise to select one of the mitigations automatically for the user. Instead, we ought to report an error for when it is an empty configuration. Personally, I'd rather throw an exception, but logging a warning should be enough.