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

[Security] [Throttling] Hide username and client ip in logs #51434

Merged
merged 1 commit into from Aug 23, 2023

Conversation

Spomky
Copy link
Contributor

@Spomky Spomky commented Aug 20, 2023

Q A
Branch? 6.4
Bug fix? yes
New feature? yes
Deprecations? no
Tickets Fix #46362
License MIT
Doc PR symfony/symfony-docs#... TODO

This PR is a proposal for fixing #46362. It appears the username and IP address may be both available in the log or the caching system.
The proposed feature uses the already existing kernel secret to hash the data.

@Spomky Spomky requested a review from chalasr as a code owner August 20, 2023 12:10
@carsonbot carsonbot added this to the 6.4 milestone Aug 20, 2023
@carsonbot carsonbot changed the title [Security][Throttling] Hide username and client ip in logs [Security] [Throttling] Hide username and client ip in logs Aug 20, 2023
@Spomky Spomky force-pushed the noip-in-cache branch 2 times, most recently from e67079c to be0e24c Compare August 21, 2023 12:11
{
if (!$secret) {
trigger_deprecation('symfony/security-http', '6.4', 'Calling "%s()" with an empty secret is deprecated. A non-empty secret will be mandatory in version 7.0.', __METHOD__);
// throw new \InvalidArgumentException('A non-empty secret is required.');
Copy link
Contributor

Choose a reason for hiding this comment

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

This will be for 7.0, but maybe it'll be better to use Symfony\Component\Security\Core\Exception\InvalidArgumentException instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct. I changed the line

@Spomky Spomky force-pushed the noip-in-cache branch 3 times, most recently from 589e497 to ff8a8ab Compare August 22, 2023 18:15
@nicolas-grekas
Copy link
Member

Thank you @Spomky.

@nicolas-grekas nicolas-grekas merged commit 394d52c into symfony:6.4 Aug 23, 2023
5 of 9 checks passed
@Spomky Spomky deleted the noip-in-cache branch August 23, 2023 07:09
This was referenced Oct 21, 2023

private function hash(string $data): string
{
return strtr(substr(base64_encode(hash_hmac('sha256', $data, $this->secret, true)), 0, 8), '/+', '._');
Copy link
Member

Choose a reason for hiding this comment

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

I came here to check as I was worried I'd have to complain about a massive cache size increase, but I'm happy to see that it was taken into account and this will actually probably even reduce the cache storage requirements. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Honestly, I fell into the trap 😅🤦‍♂️. But there are people here who are very quick-witted and who paid attention to that 😊. #bestcommunityever 👌

nicolas-grekas pushed a commit that referenced this pull request Nov 26, 2023
The `secret` parameter has been added in #51434 with a default value of
`''` and a deprecation message that it is required / may not be empty.
Which is fine and doesn't hurt backwards compatiblity.

The later ticket #52469 changes the deprecation into an exception, as it
is undesirable that no secret is used (in any scenario). This leads to
the unintended side effect that there is a BC breakage when a developer
manually creates a `DefaultLoginRateLimiter` as it is now actually
required to provide a (non empty) value due to the check and exception.

Allowing the service / class to be used without providing the secret
parameter, in a backwards compatible manner, but then still breaking the
backwards compatibility by throwing due to the default value is
confusing. So making the `secret` required makes more sense from a
developer perspective as it is clear in that the parameter must be
provided.
nicolas-grekas added a commit that referenced this pull request Nov 26, 2023
…r (RobertMe)

This PR was merged into the 6.4 branch.

Discussion
----------

[Security] make secret required for DefaultLoginRateLimiter

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | yes/no
| New feature?  | no
| Deprecations? | yes/no
| Issues        |
| License       | MIT

This tickets results from the discussion here: #52469 (review) and `@nicolas`-grekas requested a PR for it.

The `secret` parameter has been added in #51434 with a default value of `''` and a deprecation message that it is required / may not be empty. Which is fine and doesn't hurt backwards compatibility.

The later ticket #52469 changes the deprecation into an exception, as it is undesirable that no secret is used (in any scenario). This leads to the unintended side effect that there is a BC breakage when a developer manually creates a `DefaultLoginRateLimiter` as it is now actually required to provide a (non empty) value due to the check and exception.

Allowing the service / class to be used without providing the secret parameter, in a backwards compatible manner, but then still breaking the backwards compatibility by throwing due to the default value is confusing. So making the `secret` required makes more sense from a developer perspective as it is clear in that the parameter must be provided.

Commits
-------

ecbf0e9 [Security] make secret required for DefaultLoginRateLimiter
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.

[Security][Throttling] Hide username and client ip in logs
6 participants