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

Rack no longer unescapes cookie keys, so these tests no longer make sense. #2030

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

ioquatix
Copy link
Contributor

@ioquatix ioquatix commented Jul 11, 2024

Fixes #2017.

@ioquatix ioquatix force-pushed the fix-rack-protection-cookie branch from 27f5fbd to fd0c323 Compare July 11, 2024 02:42
if (k == session_key && Array(v).size > 1) ||
(k != session_key && Rack::Utils.unescape(k) == session_key)
if k == session_key && Array(v).size > 1
Copy link
Member

Choose a reason for hiding this comment

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

I think the point of this middleware is to deny requests with both rack.session and rack.%73ession cookie keys. If we don't unescape, we fail to detect that. Right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Those cookie keys don't collide in Rack either, as we don't unescape cookie keys so they are distinct keys.

Copy link
Member

Choose a reason for hiding this comment

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

In Rack <3.1 they do collide?

Copy link
Contributor Author

@ioquatix ioquatix Jul 11, 2024

Choose a reason for hiding this comment

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

It looks okay to me, IOW, it can't collide.

This was a security bug, and was fixed in various stable branches, e.g.

I understand this is an important issue, so feel free to do your own investigation and add appropriate tests to confirm the behaviour. From the logs, it was fixed about 4 years ago, so anything since then should be good.

Copy link
Member

Choose a reason for hiding this comment

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

So what this change does it having the CookieTossing middleware accept more requests, but it should be safe to do so.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, the previous key collisions can no longer occur.

@dentarg
Copy link
Member

dentarg commented Jul 11, 2024

On the topic of unescaping, I guess this isn't great?

key = Rack::Utils.unescape(key)

@ioquatix
Copy link
Contributor Author

ioquatix commented Jul 11, 2024

That definitely looks like the same security issue.

However, it's parsing set-cookie, i.e. the return value from the application/server? Then it might not be so problematic.

@dentarg
Copy link
Member

dentarg commented Jul 11, 2024

I'm going with the more conservative approach to start with (9e07d4f)

@ioquatix
Copy link
Contributor Author

Would you like to rework this PR? Or should we close it?

@dentarg
Copy link
Member

dentarg commented Oct 30, 2024

I hope to get to it

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.

Rack::Protection::CookieTossing test fail with Rack 3.1.3
2 participants