Impact
http4s is vulnerable to response-splitting or request-splitting attacks when untrusted user input is used to create any of the following fields:
- Header names (
Header.name
å
- Header values (
Header.value
)
- Status reason phrases (
Status.reason
)
- URI paths (
Uri.Path
)
- URI authority registered names (
URI.RegName
) (through 0.21)
The following backends render invalid carriage return, newline, or null characters in an unsafe fashion.
|
blaze-server |
ember-server |
blaze-client |
ember-client |
jetty-client |
header names |
⚠ |
⚠ |
⚠ |
⚠ |
⚠ |
header values |
⚠ |
⚠ |
⚠ |
⚠ |
|
status reasons |
⚠ |
⚠ |
|
|
|
URI paths |
|
|
⚠ |
⚠ |
|
URI regnames |
|
|
⚠ < 0.22 |
⚠ < 0.22 |
|
For example, given the following service:
import cats.effect._
import org.http4s._
import org.http4s.dsl.io._
import org.http4s.server.blaze.BlazeServerBuilder
import scala.concurrent.ExecutionContext.global
object ResponseSplit extends IOApp {
override def run(args: List[String]): IO[ExitCode] =
BlazeServerBuilder[IO](global)
.bindHttp(8080)
.withHttpApp(httpApp)
.resource
.use(_ => IO.never)
val httpApp: HttpApp[IO] =
HttpApp[IO] { req =>
req.params.get("author") match {
case Some(author) =>
Ok("The real content")
.map(_.putHeaders(Header("Set-Cookie", s"author=${author}")))
case None =>
BadRequest("No author parameter")
}
}
}
A clean author
parameter returns a clean response:
curl -i 'http://localhost:8080/?author=Ross'
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Set-Cookie: author=Ross
Date: Mon, 20 Sep 2021 04:12:10 GMT
Content-Length: 16
The real content
A malicious author
parameter allows a user-agent to hijack the response from our server and return different content:
curl -i 'http://localhost:8080/?author=hax0r%0d%0aContent-Length:+13%0d%0a%0aI+hacked+you'
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Set-Cookie: author=hax0r
Content-Length: 13
I hacked you
Patches
Versions 0.21.29, 0.22.5, 0.23.4, and 1.0.0-M27 perform the following:
- If a status reasoon phrase is invalid, it is dropped. Rendering is optional per spec.
- If a header name is invalid in a request or response, the header is dropped. There is no way to generically sanitize a header without potentially shadowing a correct one.
- If a header value is invalid in a request or response, it is sanitized by replacing null (
\u0000
), carriage return (\r
), and newline (\n
) with space (
) characters per spec.
- If a URI path or registered name is invalid in a request line, the client raises an
IllegalArgumentException
.
- If a URI registered name is invalid in a host header, the client raises an
IllegalArgumentException
.
Workarounds
http4s services and client applications should sanitize any user input in the aforementioned fields before returning a request or response to the backend. The carriage return, newline, and null characters are the most threatening.
Not all backends were affected: jetty-server, tomcat-server, armeria, and netty on the server; async-http-client, okhttp-client, armeria, and netty as clients.
References
For more information
If you have any questions or comments about this advisory:
Impact
http4s is vulnerable to response-splitting or request-splitting attacks when untrusted user input is used to create any of the following fields:
Header.name
åHeader.value
)Status.reason
)Uri.Path
)URI.RegName
) (through 0.21)The following backends render invalid carriage return, newline, or null characters in an unsafe fashion.
For example, given the following service:
A clean
author
parameter returns a clean response:curl -i 'http://localhost:8080/?author=Ross'
A malicious
author
parameter allows a user-agent to hijack the response from our server and return different content:curl -i 'http://localhost:8080/?author=hax0r%0d%0aContent-Length:+13%0d%0a%0aI+hacked+you'
Patches
Versions 0.21.29, 0.22.5, 0.23.4, and 1.0.0-M27 perform the following:
\u0000
), carriage return (\r
), and newline (\n
) with space (IllegalArgumentException
.IllegalArgumentException
.Workarounds
http4s services and client applications should sanitize any user input in the aforementioned fields before returning a request or response to the backend. The carriage return, newline, and null characters are the most threatening.
Not all backends were affected: jetty-server, tomcat-server, armeria, and netty on the server; async-http-client, okhttp-client, armeria, and netty as clients.
References
For more information
If you have any questions or comments about this advisory: