SEC-1271: headernames still case sensitive #1521

Closed
spring-issuemaster opened this Issue Oct 14, 2009 · 4 comments

1 participant

@spring-issuemaster

Arnljot Arntsen (Migrated from SEC-1271) said:

According to SEC-308 and SEC-315, this issue is supposedly fixed. But code is not in the distribution.

See attatched ntlm sample of how it failes in org.springframework.security.ui.ntlm.NtlmProcessingFilter.doFilterHttp line 328:
final String authMessage = request.getHeader("Authorization");

This returns null as the header is "authorization" as it's the normalized name Tomcat stores headers.

@spring-issuemaster

Arnljot Arntsen said:

As far as I can read from the current release candidate 3.0 and the stable release 2.0.8, the issue is present in both code trees.

@spring-issuemaster

Luke Taylor said:

The implementation of SavedRequest uses a case-insensitive comparator to store the headers and we have unit tests which show that header matching is case-insensitive.

If you are sure that headernames are still being compared in a case-insensitive manner, please provide clear evidence that this is the case.

NTLM is no longer supported in the codebase (it isn't in 3.0 RC1) and it seems more likely that this is a artifact of the NTLM implementation.

@spring-issuemaster

Arnljot Arntsen said:

Yes, it seems like a side effect of the NTLM filter. It tries to access the request, which is a SavedRequest inside a SavedRequestAwareWrapper, the new headers which has been set by the client(browser) is not available in the second request.

So this issue may be closed.

@spring-issuemaster

Luke Taylor said:

OK, thanks for confirming.

@spring-issuemaster spring-issuemaster added this to the 3.0.0.RC2 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment