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

bpo-46075: Allow for explicit domains in CookieJar #30108

Merged
merged 6 commits into from Apr 19, 2022
Merged

Conversation

Copy link
Contributor

@keddad keddad commented Dec 14, 2021

@the-knights-who-say-ni
Copy link

@the-knights-who-say-ni the-knights-who-say-ni commented Dec 14, 2021

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

CLA Missing

Our records indicate the following people have not signed the CLA:

@keddad

For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@github-actions
Copy link

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

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale label Jan 14, 2022
@kraktus
Copy link

@kraktus kraktus commented Jan 16, 2022

@keddad gentle bump 👀

@github-actions github-actions bot removed the stale label Jan 17, 2022
@JelleZijlstra JelleZijlstra self-requested a review Apr 12, 2022
Copy link
Member

@JelleZijlstra JelleZijlstra left a comment

A few comments. I want to be very careful here because I'm not that familiar with cookie processing and I feel like getting something wrong here is a CVE waiting to happen.


interact_netscape(c, "http://localhost", "foo=bar; domain=localhost;")

self.assertEqual(len(c), 1)
Copy link
Member

@JelleZijlstra JelleZijlstra Apr 13, 2022

Choose a reason for hiding this comment

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

Can you also test that the cookie in the jar is what you expect it to be?

Copy link
Contributor Author

@keddad keddad Apr 13, 2022

Choose a reason for hiding this comment

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

I've written such a test, and it looks like it saves the cookie under ".localhost". Without "domain" attribute present, it saves them under "localhost.local". I'm not so familiar with cookie processing as well, so I'm not really sure if "domain" attribute should affect this in such a way. I've commited the tests in cec78ed.

Copy link
Member

@JelleZijlstra JelleZijlstra Apr 16, 2022

Choose a reason for hiding this comment

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

Yes, that's a bit odd. It might be fine though as long as it behaves consistently. The public interface doesn't expose the domain names as far as I can see.

@@ -1044,12 +1044,13 @@ def set_ok_domain(self, cookie, request):
else:
undotted_domain = domain
embedded_dots = (undotted_domain.find(".") >= 0)
if not embedded_dots and domain != ".local":
if not embedded_dots and not erhn.endswith(".local"):
Copy link
Member

@JelleZijlstra JelleZijlstra Apr 13, 2022

Choose a reason for hiding this comment

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

Previously this checked a domain that came from the cookie, and now it checks the hostname from the request. Can you explain why this is changed and why the change is safe?

Copy link
Contributor Author

@keddad keddad Apr 13, 2022

Choose a reason for hiding this comment

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

This check considers localhost to be a non-local domain. It also doesn't have any embedded_dots, so it doesn't process it, which really shouldn't happen. My change should be safe because for local domains effective request hostname would end with ".local" (ERHN will end with .local if it ls clearly specified as part of the domain (foo.local), or if the domain consists of only one level (localhost has EHRN of localhost.local)).

Copy link
Member

@JelleZijlstra JelleZijlstra Apr 16, 2022

Choose a reason for hiding this comment

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

Thanks! I'm still worried about cases where the domain and the ERHN don't match (e.g. a malicious website evil.com sets a cookie for localhost). I see there are some checks for that and a test in test_wrong_domain, but it's not very thorough. Could you add more tests for similar cases (request to non-local domain setting a local cookie, and vice versa)?

Copy link
Contributor Author

@keddad keddad Apr 16, 2022

Choose a reason for hiding this comment

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

I've added some tests for those cases in a31fa40. Looks like everything is fine.

Lib/http/cookiejar.py Outdated Show resolved Hide resolved
keddad and others added 2 commits Apr 13, 2022
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
@JelleZijlstra JelleZijlstra self-requested a review Apr 13, 2022
@JelleZijlstra JelleZijlstra self-assigned this Apr 16, 2022
@JelleZijlstra JelleZijlstra removed their request for review Apr 16, 2022
@JelleZijlstra JelleZijlstra self-requested a review Apr 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants