It has been in the making for at least ten years, the problem for me has been that that production environments and test environments are not the same when you use proxys. So you need to check both, and you need to have the same type of connection that your customers use.
> And as a final reminder, even though request smuggling is typically described and demonstrated using a proxy in front of your server, just not using a proxy does not mean you're automatically safe. If you're reading, manipulating, or forwarding request streams directly in ASP.NET Core, as opposed to just relying on the built-in model binding, then you might be at risk to request smuggling attacks.
I'm probably missing something, but I still don't get how this would work without a proxy unless my own code manually parses the request from scratch. Or maybe that is what the author means.
The vulnerability, as far as I understand it, relies on two components interpreting these chunks differently. So one of them has to read \r or \n as valid markers for the chunk end, and the other one must only allow \r\n as specified.
Kestrel used to allow \r and \n (and the fix is to not do that anymore). So only if my own code parses these chunks and uses \r\n would I be vulnerable, or?
The proxy version of the vulnerability seems quite clear to me, and pretty dangerous as .NET parses non-compliant and would thereby be vulnerable behind any compliant proxy (if the proxy is relevant for security aspects).
But the single application version of the vulnerability seems to me to be very unlikely and to require essentially having a separate full HTTP parser in my own application code. Am I missing something here?
Isn’t the problem comes down to proxy not rejecting a request with two Content-Length headers? If proxy and upstream parse HTTP correctly they would either won’t touch data past the Content-Length or they would never see two HTTP requests even if content is chunked and contain bytes similar to a HTTP request.
Many moons ago, we used to run a full application level http proxy firewall. It didn't last the year. False positives were a headache and sites would just send shit down the pipe and browsers would happily power through.
I don't hate postel's law, but I admit I try not to think about it lest I get triggered by a phone call that such and such site doesn't work.
On a related note, I would recommend readers using the affected .NET 8/9 runtime in containerized applications to consider rebuilding their container images
using the patched base images and redeploy them. Unlike Azure App Service, the .NET runtime is embedded within container images and is not automatically patched by Microsoft's platform updates. It has to be rebuild and redeploy to
receive security fixes.
12 comments
[ 3.0 ms ] story [ 28.2 ms ] threadhttps://www.youtube.com/watch?v=B2qePLeI-s8
From the HTTP must die thread a month ago. https://news.ycombinator.com/item?id=44915090
I'm probably missing something, but I still don't get how this would work without a proxy unless my own code manually parses the request from scratch. Or maybe that is what the author means.
The vulnerability, as far as I understand it, relies on two components interpreting these chunks differently. So one of them has to read \r or \n as valid markers for the chunk end, and the other one must only allow \r\n as specified.
Kestrel used to allow \r and \n (and the fix is to not do that anymore). So only if my own code parses these chunks and uses \r\n would I be vulnerable, or?
The proxy version of the vulnerability seems quite clear to me, and pretty dangerous as .NET parses non-compliant and would thereby be vulnerable behind any compliant proxy (if the proxy is relevant for security aspects).
But the single application version of the vulnerability seems to me to be very unlikely and to require essentially having a separate full HTTP parser in my own application code. Am I missing something here?
I don't hate postel's law, but I admit I try not to think about it lest I get triggered by a phone call that such and such site doesn't work.