3 ms·
Well, you can achieve the desired behavior in all situations by ignoring CR and treating any seen LF as NL. I just don’t see why you’d not want to do that as t
by Aeolun 2y ago
Well, you can achieve the desired behavior in all situations by ignoring CR and treating any seen LF as NL.
I just don’t see why you’d not want to do that as the implementer. If there’s some way to exploit that behavior I can’t see it.
- immibis 2y agoThe exploit is that your request went through a proxy which followed the standard (but failed to reject the bare NL) and the client sent a header after a bare NL which you think came from the proxy but actually came from the client - such as the client's IP address in a fake X-Forwarded-For, which the proxy would have removed if it had parsed it as a header. This attack is even worse when applied to SMTP because the attacker can forge emails that pass SPF checking, by inserting the end of one message and start of another. This can also be done in HTTP if your reverse proxy uses a single multiplexed connection to your origin server, and the attacker can make their response go to the next user and desync all responses after that.