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

KTOR-6695 Add configuration warning when nothing is provided for CSRF #3968

Merged
merged 2 commits into from
Jul 18, 2024

Conversation

bjhham
Copy link
Contributor

@bjhham bjhham commented Jan 29, 2024

Subsystem
Server, CSRF

Motivation

  • KTOR-6695 CSRF: The allowOrigin method enables the Origin Header validation

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.

@bjhham bjhham requested a review from Stexxe January 29, 2024 08:01
Copy link
Contributor

@Stexxe Stexxe left a 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?

@bjhham
Copy link
Contributor Author

bjhham commented Jan 29, 2024

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.

@Stexxe
Copy link
Contributor

Stexxe commented Jan 29, 2024

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.

@bjhham
Copy link
Contributor Author

bjhham commented Jan 29, 2024

From what I understood, this issue is twofold: 1) nothing happens with the empty config, and 2) allow phrasing implies that something does happen, i.e. there is an implicit empty whitelist before calling this function. This is to address the first item. I'm open for suggestions on item 2.

@bjhham bjhham force-pushed the bjhham/csrf-default-config branch from e56d8b4 to cc90d8e Compare June 19, 2024 15:39
@bjhham bjhham requested a review from e5l June 19, 2024 15:40
@bjhham
Copy link
Contributor Author

bjhham commented Jun 19, 2024

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.

@bjhham bjhham force-pushed the bjhham/csrf-default-config branch from cc90d8e to 4eb0755 Compare June 19, 2024 15:45
@bjhham bjhham requested a review from Stexxe June 24, 2024 08:49
@@ -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()) {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@bjhham bjhham merged commit 10c8ca6 into main Jul 18, 2024
10 of 16 checks passed
@bjhham bjhham deleted the bjhham/csrf-default-config branch July 18, 2024 08:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants