Cookie attribute injection: name/path/domain unescaped in pp_to_header

Severity: low (requires application cooperation) · Status: reasoned from code

lib/Dancer2/Core/Cookie.pm:51-66:

my $value = join( '&', map uri_escape($_), $self->value );   # value: escaped
my @headers = $self->name . '=' . $value;                    # name:  raw
push @headers, "Path=" . $self->path          if $self->path;    # raw
push @headers, "Domain=" . $self->domain      if $self->domain;  # raw

The value is uri_escaped, but name, path and domain are concatenated raw. A ; in an application-supplied path, domain or name injects arbitrary cookie attributes (Domain=, Path=, Secure, SameSite=).

Reaching it requires the application to build a cookie from user input, hence low.

Suggested fix

Reject rather than silently mangle, since a ; in any of these is always a programming error:

for my $attr (qw< name path domain >) {
    my $v = $self->$attr;
    defined $v && $v =~ /[;,\s[:cntrl:]]/
        and croak "Invalid character in cookie $attr: '$v'";
}

Worth checking alongside

The XS path (xs_to_header, delegating to HTTP::XSCookies::bake_cookie) may already handle some of this. Which path runs depends on whether HTTP::XSCookies is installed, so the two should be made to agree — otherwise this is another install-dependent behaviour difference.

Start with lib/Dancer2/Core/Cookie.pm:51-66 and trace both pp_to_header and xs_to_header, including the HTTP::XSCookies::bake_cookie path. Confirm how name, path, and domain handle semicolons, commas, whitespace, and control characters, then make the two paths reject invalid input consistently. Done means cookie attributes cannot be injected through these fields and both implementations agree.