HTTP Host header attack

[fraenku]

The class UrlUtils is using the methodgetServerName()of the HttpServletRequest.
This method indeed is not secure since it could be manipulated through the host-header

See also: http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html)
or: https://find-sec-bugs.github.io/bugs.htm#SERVLET_SERVER_NAME

See also: https://github.com/ESAPI/esapi-java-legacy/blob/develop/src/main/java/org/owasp/esapi/filters/SecurityWrapperRequest.java
for a list of potential request headers which are manipulable.

[ibaskine]

This issue is detected by Burp Scanner, which makes it difficult selling products based on Spring Security to security conscious customers. Are there any plans fixing this issue or is there any workaround?

[fraenku]

Some progress on this? issue is open since April...
The issue above leaded to an attack where an URL in an e-mail could be manipulated (which can be easily used for phising-attacks)

[ibaskine]

Just wander. Can I use code snippet below for getting server name?

new java.net.URI(request.getRequestURL().toString()).getHost()

[rady66]

What is the progress here? Could hardly believe action has not been taken for such security issue almost two years.

[gjoseph]

FWIW SourceClear reports this as a vulnerability (https://www.sourceclear.com/vulnerability-database/security/incorrect-headers-handling/java/sid-20558) - any chance this could get patched up soon?

[jzheaux]

Since the Host header is untrusted information, we should likely consider whitelisting as a solution. StrictHttpFirewall is the most suitable, so I'd propose adding a method StrictHttpFirewall#setAllowedHostnames(Predicate), which would ensure the hostname in HttpServletRequest is a known good value.

The application would need to set this value like so:

void configure(WebSecurity web) {
    StrictHttpFirewall firewall = new StrictHttpFirewall();
    firewall.setAllowedHostnames(hostname -> hostname.equals("example.org"));
    web
        .httpFirewall(firewall);
}

With this solution, UrlUtils would still invoke request.getServerName(), but it would be a known good value at that point.

@fraenku would this address the issue?

[avodonosov]

Does anyone know a use case where spring-security itself opens a vulnerability due to the Host header manipulation?

Assuming my application code doesn't use UrlUtils for anything sensitive to attacks from the description, is it still dangerous to just use spring-security?

@fraenku , @ibaskine , @rady66 , @gjoseph , @jzheaux

[jzheaux]

Does anyone know a use case

This ticket doesn't describe any attacks. If anyone does know of one, I'd encourage that it be reported responsibly to security@pivotal.io, not here.

is it still dangerous to just use spring-security

No piece of software is perfectly secure, @avodonosov, but there is quite a difference between that and describing a software library as "dangerous". Can you explain a bit more of what you mean here?

[avodonosov]

@jzheaux , I mean is there a real vulnerability if I simply use spring-security functionality, without taking UrlUtils result myself and sending it somewhere. I just mean is it really exploitable, or it's just a general note that the Host is accessed by code, so it smells vulnerable, but no-one can exploit it.

[jzheaux]

I mean is there a real vulnerability

There are always insecure ways to use things, but the main principle here is to not use untrusted information in a security decision.

This ticket was not about closing a reported vuln but instead about adding functionality that allows applications to whitelist the Host header, making it a known-good value. The default behavior of Spring Security is still to allow any Host header, so its default security position hasn't changed either way by merging this PR.

[is it] just a general note that the Host is accessed by code

UrlUtils#buildFullRequestUrl uses request.getServerName, and so if you are using buildFullRequestUrl as part of a security decision, and you haven't previously validated the Host header, then you may be vulnerable somehow as that violates the principle. Spring Security doesn't use UrlUtils#buildFullRequestUrl in any known-vulnerable ways.

It's hard to know the myriad circumstances under which others are calling this method, which is why understanding the security principle is more important.

[avodonosov]

Thank you, @jzheaux

[gjoseph]

This ticket doesn't describe any attacks. If anyone does know of one, I'd encourage that it be reported responsibly to security@pivotal.io, not here.

@jzheaux I think what I'm still a bit confused about is this issue was linked against a Sourceclear vulnerability (https://www.sourceclear.com/vulnerability-database/security/incorrect-headers-handling/java/sid-20558) - it may be a red herring, but neither side is telling us how one relates to the other, or where the relation even comes from. I figured with this SourceClear vuln being reported, the Pivotal folks would already be aware?

[jzheaux]

it may be a red herring, but neither side is telling us how one relates to the other

@gjoseph Sorry that I don't have an update for you on this yet, though I am in the process of reaching out to SourceClear to get more information from them.

[peeyushsurolia]

it may be a red herring, but neither side is telling us how one relates to the other

@gjoseph Sorry that I don't have an update for you on this yet, though I am in the process of reaching out to SourceClear to get more information from them.

@jzheaux I observed that this issue : https://www.sourceclear.com/vulnerability-database/security/incorrect-headers-handling/java/sid-20558 not reported on 5.1.6.RELEASE of spring-security-web but 4.X series is vunerable.

I am currently using 4.X version and can't switch to latest version at this point of time, Are you still in discussion to get details from SourceClear?

[jzheaux]

Yes, @peeyushsurolia, I am still awaiting their response.

[snoopysecurity]

I noticed this has been patched now, shouldn't there be an advisory for this within https://tanzu.vmware.com/security?

[jzheaux]

Thanks, @snoopysecurity, for double-checking. Given that these changes don't resolve any CVE, I'm not sure what we'd report there.