CRLF injection

[chadwhitacre]

https://gratipay.freshdesk.com/helpdesk/tickets/2305

== CRLF Injection (Chrome, Internet Explorer) ==
http://gratipay.com/%0dSet-Cookie:csrf_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;

Response:
Location: https://gratipay.com/\r
Set-Cookie:csrf_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;\r\n

[chadwhitacre]

Really it's header injection:

$ curl -I http://localhost:8537/%0dFoo:%20Bar
HTTP/1.1 302 Found
Server: gunicorn/18.0
Date: Mon, 29 Jun 2015 13:15:41 GMT
Connection: close
Transfer-Encoding: chunked
X-Gratipay-Version: 1860
X-Frame-Options: SAMEORIGIN
Foo: Bar/ /
Set-Cookie: csrf_token=[]; expires=Mon, 06 Jul 2015 13:15:41 GMT; Path=/
Cache-Control: no-cache

$

[chadwhitacre]

I believe the bug is in how we handle redirects.

[chadwhitacre]

I put a set_trace in aspen.http.Request.redirect and I don't hit it! Following up on gratipay/gratipay.com#2138 (comment):

Yeah, looks like we have some code that manually performs redirection.

[chadwhitacre]

I'm finding four places outside of Request.redirect where we construct redirect responses:

• the dispatcher, twice
• canonicalize, which is called from get_{participant,team} to redirect, e.g., /~Foo/ to /~foo/
  • not to be confused with canonize, which acts on the netloc to redirect, e.g., http://www.gittip.org/ to https://gratipay.com/
• the Response.redirect monkey-patch
• elsewhere JSON endpoints

[chadwhitacre]

Really it's header injection:

Sorry, I misread "CRLF injection" in the title as "CSRF injection."

[chadwhitacre]

For the test case above, we're hitting the second dispatcher redirect (to trailing slash).

[chadwhitacre]

Okay! What's the best fix?

[chadwhitacre]

Seems like a safe, low-level place to fix this bug would be in Response.__init__ or possibly even in Mapping.{__set_item__,add}. Note that the latter is shared with the body parsing machinery, where we don't want to clobber \r.

[chadwhitacre]

Or is now the time to migrate Aspen to Werkzeug? Cf. AspenWeb/pando.py#357.

[chadwhitacre]

Here's Werkzeug's protection against this.

[chadwhitacre]

Hah! We already have LF injection protection. We just need to add CR injection protection. ;-)

The other limitation with our current implementation is that adding a second value for the same header doesn't go through BaseHeaders.__setitem__.

[chadwhitacre]

Ping @pjz.

[chadwhitacre]

@pjz I just added you to the Gratipay security team so you can help me land the fix for this. You available? :)

[chadwhitacre]

Fixed in Aspen 0.39.

[techtonik]

Niiice. Did you find any real threats for CRLF injection in GP?

[chadwhitacre]

Fix deployed in gratipay/gratipay.com#3588, but gratipay/gratipay.com#3594 is causing a 500. Still considering this fixed tho:

$ curl -I http://gratipay.com/%0dSet-Cookie:csrf_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
HTTP/1.1 500 Internal Server Error
Connection: keep-alive
Server: gunicorn/18.0
Date: Thu, 02 Jul 2015 21:46:59 GMT
Transfer-Encoding: chunked
Via: 1.1 vegur

$

[chadwhitacre]

@techtonik Yes: gratipay/security-flh0cu#1.

[chadwhitacre]

To: researcher

The CRLF Injection and CSRF Protection Bypass bugs should be fixed now. Please confirm.

I've added you to our legacy Halls of Fame for Aspen (for the CRLF injection) and Gratipay (for the CSRF protection bypass):

http://aspen.io/security.txt
https://gratipay.com/about/security/hall-of-fame

We've now migrated our security program to HackerOne. If you would like acknowledgement on HackerOne feel free to re-file the bugs there and I will resolve them.

Thanks for the reports! :-)

[chadwhitacre]

https://hackerone.com/reports/79552