61–67 of 67 posts
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.
Earlier quoted context omitted.
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.
If you're maintaining an old api you can publish new versions of endpoints that don't accept mangled requests. If it's important you can give clients a time limit like let's say a few months to update their software to use your updated endpoints before you remove the old ones.
Earlier quoted context omitted.
The state of HTML parsing should convince you that if you follow postel's law in one browser then every other browser has to follow it in the same way.
> The state of HTML parsing should convince you that if you follow postel's law in one browser then every other browser has to follow it in the same way. No. Your claim expresses a critical misunderstanding of the principle. It's desirable that a browser should be robust to support broken but still perfectly parceable HTML. Otherwise, it fails to be even useable when dealing with anything but perfectly compliant docu…
If browsers had conformed to a rigid specification and only accepted valid input from the start, then people wouldn't have produced all that broken html and we wouldn't be in this mess that we are in now.
Earlier quoted context omitted.
ASP.NET Core: >= 6.0.0 >= 8.0.0 >= 9.0.0 Microsoft.AspNetCore.Server.Kestrel.Core: <= 2.3.0
>= 6.0.0 Fixes are available for .NET 6 from HeroDevs ongoing security support for .NET 6, called NES* for .NET. *never ending support
Earlier quoted context omitted.
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…
I don't know about "not targeting enterprise" being the problem here - it's super common to find "enterprise" .NET APIs that return 200 for every possible condition and put some error text as a JSON blob in the response with "success" = "false" while setting caching headers. Mostly this stuff comes down to skill issues.
I jsonrpc I think 200 OK is correct with an error payload that says “you are not authorized” or similar.
Earlier 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…
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.
Blanket disallowing old HTTP depends on who is calling your web service: I don't think modern browsers need to fall back to HTTP v1; so the risk is if you have a web service that is called by scripts or other programs using old HTTP libraries.
Even then, it's pretty well established that no one remains compatible with old TLS libraries, so I don't see why we need to remain compatible with old HTTP libraries indefinitely.
Earlier quoted context omitted.
I don't know about "not targeting enterprise" being the problem here - it's super common to find "enterprise" .NET APIs that return 200 for every possible condition and put some error text as a JSON blob in the response with "success" = "false" while setting caching headers. Mostly this stuff comes down to skill issues.
If I transmit SOAP or JSONRPC over http, both of which use the response payload itself to contain whether the request was an error or not, what should the status be in case of error ? I jsonrpc I think 200 OK is correct with an error payload that says “you are not authorized” or similar.
> what should the status be in case of error
400 to 500 range status code. You can't ignore the lower level protocol because you're implementing a higher level one.