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

HTTP Host header attack #4310

Closed
fraenku opened this issue Apr 26, 2017 · 14 comments

Comments

@fraenku
Copy link

commented Apr 26, 2017

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 comment has been minimized.

Copy link

commented Oct 2, 2017

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

This comment has been minimized.

Copy link
Author

commented Dec 8, 2017

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

This comment has been minimized.

Copy link

commented Jun 4, 2018

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

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

@rady66

This comment has been minimized.

Copy link

commented Jan 22, 2019

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

@rwinch rwinch added this to the 5.2.0.M2 milestone Jan 22, 2019

@jgrandja jgrandja modified the milestones: 5.2.0.M2, 5.2.0.RC1 Apr 15, 2019

@eleftherias eleftherias modified the milestones: 5.2.0.M3, 5.2.0.RC1 Jun 14, 2019

@gjoseph

This comment has been minimized.

Copy link

commented Jul 18, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2019

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?

eddumelendez added a commit to eddumelendez/spring-security that referenced this issue Jul 27, 2019

Add support for allowedHostnames in StrictHttpFirewall
Introduce a new method `setAllowedHostnames` which perform the validation
against untrusted hostnames.

Fixes spring-projectsgh-4310

eddumelendez added a commit to eddumelendez/spring-security that referenced this issue Jul 31, 2019

Add support for allowedHostnames in StrictHttpFirewall
Introduce a new method `setAllowedHostnames` which perform the validation
against untrusted hostnames.

Fixes spring-projectsgh-4310

jzheaux added a commit to jzheaux/spring-security that referenced this issue Aug 1, 2019

Add support for allowedHostnames in StrictHttpFirewall
Introduce a new method `setAllowedHostnames` which perform the validation
against untrusted hostnames.

Fixes spring-projectsgh-4310

eddumelendez added a commit to eddumelendez/spring-security that referenced this issue Aug 3, 2019

Add support for allowedHostnames in StrictHttpFirewall
Introduce a new method `setAllowedHostnames` which perform the validation
against untrusted hostnames.

Fixes spring-projectsgh-4310

@jzheaux jzheaux closed this in #7158 Aug 4, 2019

jzheaux added a commit that referenced this issue Aug 4, 2019

Add support for allowedHostnames in StrictHttpFirewall
Introduce a new method `setAllowedHostnames` which perform the validation
against untrusted hostnames.

Fixes gh-4310

jzheaux added a commit that referenced this issue Aug 4, 2019

Polish setAllowedHostnames
Added JavaDoc to method, including @SInCE attribute

Issue gh-4310
@avodonosov

This comment has been minimized.

Copy link

commented Aug 6, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 6, 2019

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

This comment has been minimized.

Copy link

commented Aug 6, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

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

This comment has been minimized.

Copy link

commented Aug 9, 2019

Thank you, @jzheaux

@gjoseph

This comment has been minimized.

Copy link

commented Aug 12, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

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.

@avodonosov

This comment has been minimized.

Copy link

commented Aug 19, 2019

@ibaskine, you say it was detected by Burp Scanner. Can you provide a link, or more details?

This means there is a real use case - Burp Suite is not a static code analyzer, it performs queries on a real alive system. trying various exploits (shell commands in request parameters, SQL; various XSS techniques).

So Burp Suite has sent a malicious Host header and detected insecure use (e.g. received the value passed embedded literally in HTML response).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.