I wonder how many vulnerabilities have been accidentally created by adherence to postel's law rather than just being strict in what's accepted too.
[deleted]
Understanding the Worst .NET Vulnerability
41–50 of 67 posts
Re: Understanding the Worst .NET Vulnerability
#42Earlier quoted context omitted.
I frequently get into this argument with people about how Postel's law is misguided. Being liberal in what you accept comes at _huge_ costs to the entire ecosystem and there are much better ways to design flexibility into protocols.
> Being liberal in what you accept comes at _huge_ costs to the entire ecosyste Why do you believe that? Being liberal in what you accept doesn't mean you can't do input validation or you're forced to pass through unsupported parameters. It's pretty obvious you validate the input that is relevant to your own case, you do not throw errors if you stumble upon input parameters you don't support, and then you ignore the…
The problem with Postel's law is that people apply it to interpreting Postel's law. They read it as encouraging you to accept any input, and trying to continue in the face of nonsense. They accept malformed input & attempt to make sense of it, instead of rejecting it because the fields they care about are malformed. Then the users depend on that behavior, and it ossifies. The system becomes brittle & difficult to change.
I like to call it the "hardness principle". It makes your system take longer to break, but when it does it's more damaging than it would have been if you'd rejected malformed input in the first place.
Re: Understanding the Worst .NET Vulnerability
#43> 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 miss…
Basically, if you handle the request at the stream level, there's a small chance you might be vulnerable. For example, let's say you have an HTTP API that checks a few headers and then makes another outgoing HTTP request. You might just send the stream along, using incomingHttpRequestStream.CopyTo(outgoingHttpRequestStream) / (or CopyToAsync). ( https://learn.microsoft.com/en-us/dotnet/api/system.io.strea... ) That m…
I think the big reason this escalates to such a high score is because the Middleware abstraction common in a lot of HTTP server designs today (including Kestrel, ASP.NET being sometimes viewed in its modern implementation as entirely a stack of Middleware in a single trenchcoat) can also be a series of nesting doll "micro-proxies" manipulating the HTTP request in various ways before passing it to code that trusts the Middleware did its job. With Middleware doing all sorts of jobs but especially various steps of Authentication and Authorization, there can be a lot of security risks if there were vulnerable middleware.
It wouldn't surprise me if Microsoft found a first-party or second-party (support contract) or open source/nuget Kestrel/ASP.NET Middleware somewhere in the wild that was affected by this vulnerability in a concerning way. In that case, it also somewhat makes sense that Microsoft doesn't necessarily want to victim blame the affected Middleware given that they recognized that Kestrel itself should have better handled the vulnerability before it ever passed to Middleware.
Re: Understanding the Worst .NET Vulnerability
#44It 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. https://www.youtube.com/watch?v=B2qePLeI-s8 From the HTTP must die thread a month ago. https://news.ycombinator.com/item?id=44915090
The problem is that we have a culture of accepting mangled requests on the web. This happens in application code too - because web developers are sloppy it's common to either disable or not use strict input validation. In a pure .Net world it's the norm to use strict input validation and tell clients to fix their bad requests and this looks like one of those cultural blindspots. "We" wouldn't naturally consider a cas…
We have to accept mangled requests when there are clients out there that send mangled requests, which they will continue to do as long as servers accept them. Postel's law was good for prototyping but created a security nightmare in production.
Re: Understanding the Worst .NET Vulnerability
#45> 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 miss…
Basically, if you handle the request at the stream level, there's a small chance you might be vulnerable. For example, let's say you have an HTTP API that checks a few headers and then makes another outgoing HTTP request. You might just send the stream along, using incomingHttpRequestStream.CopyTo(outgoingHttpRequestStream) / (or CopyToAsync). ( https://learn.microsoft.com/en-us/dotnet/api/system.io.strea... ) That m…
There's actually a near 100% chance you're vulnerable if you handle HTTP - or any other non-binary protocol allowing connection reuse - at the stream level, and don't parse strictly (close connection on duplicate content-length, on chunked encoding with content-length, on duplicate transfer-encoding, on bare CR or LF, etc).
If you blanket disallow old HTTP, clients will fail to reach you.
Re: Understanding the Worst .NET Vulnerability
#46Earlier quoted context omitted.
I frequently get into this argument with people about how Postel's law is misguided. Being liberal in what you accept comes at _huge_ costs to the entire ecosystem and there are much better ways to design flexibility into protocols.
> Being liberal in what you accept comes at _huge_ costs to the entire ecosyste Why do you believe that? Being liberal in what you accept doesn't mean you can't do input validation or you're forced to pass through unsupported parameters. It's pretty obvious you validate the input that is relevant to your own case, you do not throw errors if you stumble upon input parameters you don't support, and then you ignore the…
It sounds like you didn't read the article. The vulnerability occurs precisely because a request parser tried to be lenient.
Re: Understanding the Worst .NET Vulnerability
#47Earlier quoted context omitted.
> Being liberal in what you accept comes at _huge_ costs to the entire ecosyste Why do you believe that? Being liberal in what you accept doesn't mean you can't do input validation or you're forced to pass through unsupported parameters. It's pretty obvious you validate the input that is relevant to your own case, you do not throw errors if you stumble upon input parameters you don't support, and then you ignore the…
The problem with Postel's law is that people apply it to interpreting Postel's law. They read it as encouraging you to accept any input, and trying to continue in the face of nonsense. They accept malformed input & attempt to make sense of it, instead of rejecting it because the fields they care about are malformed. Then the users depend on that behavior, and it ossifies. The system becomes brittle & difficult to cha…
> They accept malformed input & attempt to make sense of it, instead of rejecting it because the fields they care about are malformed.
I don't think that's true at all. The whole point of the law is that your interfaces should be robust, and still accept input that might be nonconforming in some way but still be possible to validate.
The principle still states that if you cannot validate input, you should not accept it.
Re: Understanding the Worst .NET Vulnerability
#48Isn’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.
Re: Understanding the Worst .NET Vulnerability
#49Earlier quoted context omitted.
Basically, if you handle the request at the stream level, there's a small chance you might be vulnerable. For example, let's say you have an HTTP API that checks a few headers and then makes another outgoing HTTP request. You might just send the stream along, using incomingHttpRequestStream.CopyTo(outgoingHttpRequestStream) / (or CopyToAsync). ( https://learn.microsoft.com/en-us/dotnet/api/system.io.strea... ) That m…
I think the big reason this escalates to such a high score is because the Middleware abstraction common in a lot of HTTP server designs today (including Kestrel, ASP.NET being sometimes viewed in its modern implementation as entirely a stack of Middleware in a single trenchcoat) can also be a series of nesting doll "micro-proxies" manipulating the HTTP request in various ways before passing it to code that trusts the…
But the middleware would usually not work on the raw http request, but the version already parsed by Kestrel. So everything should see the same version of the request, the one with the non-spec-compliant parsing by Kestrel.
Re: Understanding the Worst .NET Vulnerability
#50Many 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.