Fix early error handling

[chadwhitacre]

I believe all three four of these are related:

1. https://sentry.io/gratipay/gratipay-com/issues/82062971/
2. https://sentry.io/gratipay/gratipay-com/issues/83182753/
3. https://sentry.io/gratipay/gratipay-com/issues/184941452/
4. https://sentry.io/gratipay/gratipay-com/issues/199760784/

[chadwhitacre]

In all three of those cases, in the context of the delegate_error_to_simplate frame, request is the empty string(!). (BTW, this is displayed better under the new client, as '' instead of ; #4200.) This surprised me. There is a test at the top of that function for request is None, but how can request be the empty string?

Well, it turns out that we do initialize Request thus, so that some sort of other error could—and seemingly does—result in request as the empty string inside delegate_error_to_simplate.

I think the fix here in Gratipay is probably a function immediately before delegate_error_to_simplate that converts '' to None, with a reticket in Aspen (Pando). However, we should write a test first. Towards that: (1) and (3) are both CRLF injections, and (2) is a bad redirect location, as indicated by the err key in the /app/error.spt frame context.

[chadwhitacre]

And I still don't quite understand how request is ending up the empty string. If Request.from_wsgi were to raise, I'd expect request to go missing from the context.

[chadwhitacre]

tfw google for curl crlf injection and find gratipay/security-qf35us#1 😁

[chadwhitacre]

I'm trying:

curl -I http://localhost:8537/%0dSet-Cookie:Xsrf_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;

[chadwhitacre]

I am triggering the CRLF protection, but I'm not seeing the empty string request behavior.

[chadwhitacre]

Skunked. :-/

[chadwhitacre]

Rebased, was b32bc05.

[chadwhitacre]

Only the last of the original four errors is still available in Sentry:

https://sentry.io/gratipay/gratipay-com/issues/199760784/

[chadwhitacre]

I give up. 😞