Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the Worst .NET Vulnerability

andrewlock.net

Post reply on HN
Print view View original

21–30 of 67 posts

Re: Understanding the Worst .NET Vulnerability

#21

Post by jen20 »

radicalbyte wrote: post #8
pastage wrote: post #5

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. 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…

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.

Re: Understanding the Worst .NET Vulnerability

#23

Post by jen20 »

giancarlostoro wrote: post #20
pixl97 wrote: post #18

Earlier quoted context omitted.

This tends to be huge in enterprise. Development, test/UAT, and production will all have different proxy methods and requirements. Devs may have a proxy with NTLM. Test may have something like proxy auto detect. Prod may be manually defined. It's really fun trying to test connectivity issues like this.

In a high quality setup you have a staging server that is a carbon copy of PROD. Bonus points if you make it so staging and PROD are 100% interchangeable, to the level that you can point PROD to staging, and then turn PROD into staging, and do the same next deployment. If you can do that, you have a stronger change of at least reproducing production issues. Dev, UAT / QA, Staging, PROD. This is the ideal setup in my…

To be any use staging environments should be scientific tests. They should prove that a given change, if it goes to production, will work.

You cannot do this if you're changing more than that one thing. The only way to make this work really is either dynamic environments that completely mirror everything, which tends to be time consuming or expensive or continuous delivery to a production-like environment via feature flags and so forth.

Having a staging server that is a mirror of production[1] improves things a bit over doing nothing. You need the entire environment, including all your dependencies, to have a real test of anything, and that includes things that corporate IT departments typically hate.

[1]: Why is it so common to see "PROD" written as if it were an acronym?

Re: Understanding the Worst .NET Vulnerability

#26

Post by giancarlostoro »

jen20 wrote: post #23
giancarlostoro wrote: post #20

Earlier quoted context omitted.

In a high quality setup you have a staging server that is a carbon copy of PROD. Bonus points if you make it so staging and PROD are 100% interchangeable, to the level that you can point PROD to staging, and then turn PROD into staging, and do the same next deployment. If you can do that, you have a stronger change of at least reproducing production issues. Dev, UAT / QA, Staging, PROD. This is the ideal setup in my…

To be any use staging environments should be scientific tests. They should prove that a given change, if it goes to production, will work. You cannot do this if you're changing more than that one thing. The only way to make this work really is either dynamic environments that completely mirror everything, which tends to be time consuming or expensive or continuous delivery to a production-like environment via feature…

I always write it that way maybe for the same reason others do it, to emphasize how critical PROD is, so you don't overlook it if you just read prod, or production. If you see PRODUCTION you might slow down and go "oh crap" so it is definitely an emphasis I always add when talking about production in text. PROD is just shorter to write, but all caps makes the emphasis stick.

If you staging environment is pointing to the exact same databases PROD is, and other similar dependencies, there's no reason you can't hotswap it with PROD itself, I mean I've done something like this before.

It's much easier if your production deployment pipeline is setup for it though. You'd want to scale down drastically for staging, but in my eyes, if you're not going to have staging be as carbon copy of PROD as you humanely can have it, you might as well not have that fourth environment and just suffer when you cannot reproduce bugs. The real gem of staging is that if it would break in PROD, it would definitely break in staging. In the few companies where we had a carbon copy of PROD setup as a staging environment where key things are pulled from PROD itself, we've had way less bugs promoted to PROD when QA tests them in staging.

In theory the ROI is worth it, if you care about quality. Sadly most places do not care about quality nearly enough.

Re: Understanding the Worst .NET Vulnerability

#28

Post by ahoka »

capitol_ wrote: post #27
colseph wrote: post #25

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.

If "A billion dollar mistake" wasn't already taken by 'null', then this would be a good candidate.

Oh null is fine, but "everything is nullable" is the devil.

Re: Understanding the Worst .NET Vulnerability

#29

Post by teddyh »

giancarlostoro wrote: post #26
jen20 wrote: post #23

Earlier quoted context omitted.

To be any use staging environments should be scientific tests. They should prove that a given change, if it goes to production, will work. You cannot do this if you're changing more than that one thing. The only way to make this work really is either dynamic environments that completely mirror everything, which tends to be time consuming or expensive or continuous delivery to a production-like environment via feature…

I always write it that way maybe for the same reason others do it, to emphasize how critical PROD is, so you don't overlook it if you just read prod, or production. If you see PRODUCTION you might slow down and go "oh crap" so it is definitely an emphasis I always add when talking about production in text. PROD is just shorter to write, but all caps makes the emphasis stick. If you staging environment is pointing to…

But it makes the text look like it was written by a schizophrenic: https://web.archive.org/web/20231122160401/https://prestersp...>

Re: Understanding the Worst .NET Vulnerability

#30

Post by giancarlostoro »

teddyh wrote: post #29
giancarlostoro wrote: post #26

Earlier quoted context omitted.

I always write it that way maybe for the same reason others do it, to emphasize how critical PROD is, so you don't overlook it if you just read prod, or production. If you see PRODUCTION you might slow down and go "oh crap" so it is definitely an emphasis I always add when talking about production in text. PROD is just shorter to write, but all caps makes the emphasis stick. If you staging environment is pointing to…

But it makes the text look like it was written by a schizophrenic: https://web.archive.org/web/20231122160401/https://prestersp... >

I guess, but its consistently the same word being capitalized.
Post reply on HN