Refuse to set signed or encrypted cookies with an insecure default secret

[Grinnz]

Summary

Rough attempt at taking the approach of dying if encrypted or signed cookies are requested to be set but the application secret is still set to the default of the application moniker.

This is fairly straightforward to do in the signed_cookie and encrypted_cookie methods, but this also requires a check in the session method, because setting the session cookie occurs too late to error out sensibly.

I'm not satisfied with this check in the session method, because: there still may be instances where this session method is called while a response is already being rendered; and session data can be set by assigning to $c->session->{foo} and there's no way to know that will happen at this juncture.

Additionally, this check does not help cases where the secret has been set to a value that is also insecure but is not the current application's moniker, such as with Mojolicious::Plugin::Mount.

I am not sure if these issues can be solved, but wanted to put this idea into practice for others to review.

This also affects use of features using the session implicitly, such as the flash and csrf_token default helpers.

The MOJO_ALLOW_INSECURE_SECRET env variable is provided as a bypass option for applications that can't be made secure for whatever reason.

Motivation

The risk of insecure secrets being used in applications using signed or encrypted cookies is not sufficiently mitigated by the annoying warning in the logs. But we don't want to cause applications to fail if they are not using these features.

References

Implements a part of #2200 by refusing to set signed or encrypted cookies by default unless the secret has been changed from the default.

[kraih]

It seems a little overengineered, but i also don't know a better solution.

[guest20]

I don't think these secrets are "passphrase"s (and the FAQ doesn't call them that either)

[guest20]

Would it make sense to move this check into $app->session?

[Grinnz]

There is no session method for Mojolicious; that would be calling the session helper, which just forwards to the session method on the controller which is handled above (albeit with some issues as described in the initial comment).

[guest20]

yes, sorry, github threw away my comment, and i crankly re-typed it wrong.

I mean should it be in $app->secrets

[Grinnz]

That attribute may be accessed by applications that don't actually do anything with it, such as Mojolicious::Plugin::Mount. But perhaps we can work around that more easily than the problems with this approach.

[Copilot]

Pull Request Overview

This PR introduces stricter checks to prevent the setting of signed or encrypted cookies when using insecure application secrets by comparing the secret with the application moniker. It also updates several test applications to use dynamically generated secrets.

• Updates tests in multiple files to use generate_secret for secure default secrets.
• Adds runtime checks in the Controller methods (encrypted_cookie, session, signed_cookie) to enforce secret validation.
• Enhances documentation to clearly indicate the security requirement and the bypass option.

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
t/mojolicious/validation_lite_app.t	Updated to use generate_secret for secure defaults
t/mojolicious/session_lite_app.t	Added subtests for insecure secret handling in session contexts
t/mojolicious/rebased_lite_app.t	Updated to use generate_secret for secure defaults
t/mojolicious/longpolling_lite_app.t	Updated to use generate_secret for secure defaults
t/mojolicious/embedded_lite_app.t	Updated to use generate_secret for secure defaults
t/mojolicious/app.t	Updated to use generate_secret for secure defaults
lib/Mojolicious/Controller.pm	Added security checks and documentation updates in cookie methods

Comments suppressed due to low confidence (1)

lib/Mojolicious/Controller.pm:63

• [nitpick] Consider refactoring the duplicate insecure-secret checks (found in encrypted_cookie, session, and signed_cookie methods) into a common helper function to improve maintainability and reduce redundancy.

Carp::croak 'Your secret passphrase must be changed to set encrypted cookies (see FAQ for more)' if !$ENV{MOJO_ALLOW_INSECURE_SECRET} and (!length $secret or $secret eq $moniker);

[Copilot]

[nitpick] The use of double negation (!!) can reduce readability; consider using an explicit boolean expression to check for a set operation.

Suggested change

	my $set_operation = !!(@_ > 1 || ref $_[0]);
	my $set_operation = (@_ > 1 || ref $_[0]) ? 1 : 0;

[Copilot]

[nitpick] For clarity and consistency with other parts of the code, consider using $t->app->moniker instead of app->moniker when setting insecure secrets in tests.

Suggested change

	$t->app->secrets([app->moniker]);
	$t->app->secrets([$t->app->moniker]);

[kraih]

This one is actually good!