Play framework vulnerability could lead to CSRF protection bypass

Now-patched issue impacts certain configurations of web app framework

A vulnerability in the Play framework can allow a complete cross-site request forgery (CSRF) protection bypass, researchers have warned.

Play is a framework for building web applications with Java and Scala. It is used by companies including LinkedIn, Verizon, and Walmart.

The open source framework allows users to set up a restricted set of content types it will allow as part of its anti-CSRF mechanism.

However, researchers discovered they were able to bypass this optional functionality by sending malformed Content-Type headers to a target web app.

It was found that an attacker could use a semicolon in the boundary value which does not comply with RFC 2046, therefore circumventing the framework’s blocklist function.

Press Play

The issue was discovered by offensive security researchers from Doyensec during a client engagement, a blog post details.

Lorenzo Stella, application security engineer at Doyensec, told The Daily Swig: “In the 2.8.x migration guide, it was described how users could restore Play’s old default behavior if required by legacy systems or other dependencies.

“The issue was not in the suggested configuration detailed in the Play documentation, rather than in how their anti-CSRF mechanism handled non-compliant content types, not failing safely. So, even if a user specified a blacklist of content-types, it could be bypassed anyway.”

Stella added: “This is possible because most browsers today allow more characters than they should in the boundary value.

“This particular bypass uses a semicolon (;) in the boundary value, not complying with RFC 2046.”

The vulnerability has been patched in version 2.8.2 by the vendor.

The issue only affects Play applications that use the anti-CSRF filter and have configured a blocklist of Content-Types for CSRF protection.

This blocklist is not present in Play’s default configuration, Stella said.

He added: “Rather, all requests have CSRF protection applied regardless of content types, and so this vulnerability does not impact applications that use the default configuration.”

The issue was patched by treating all failed parsings of the Content-Type header as a blocklisted content type, to be sure.