Re: RFC 9205 vs. CL0P

We could. But I doubt it would help.

Frankly, I suspect less than 1% of working software developers have ever actually read any RFC (or BCP) published by the IETF. And the people who read specs aren't the people who need to be told not to run unauthenticated SQL queries on port 80.

I was invited a few times to give guest lectures about computer science at General Assembly. For those who don't know, they run a 3 month "coding bootcamp", where they teach people just enough information about software development to get their foot in the door in the industry. Of their 60 classroom days, 0 of them are devoted to security. Their program seems to teach the philosophy of "If it seems to work, ship it". Needless to say, their students have no idea what the IETF is. They don't read any BCP documnets in their course. And despite writing web software, students graduate without really knowing HTTP.

If you want to stop these ridiculous security vulnerabilities with education, it is those students you need to reach somehow. We could change some of the 9000 or so words in BCP56 to teach some information security. But it won't stop MoveIt from shipping insecure code. If they hired the sort of people who read BCP documents, I doubt they would have made these sort of mistakes in the first place.

For my money, as an industry I think we need to solve this via the legal system. Harm caused by insecure software should be treated the same way that we treat harm caused by negligent builders, or negligent handling of food resulting in food poisoning. There should be much stricter penalties for data breaches like this. And companies shouldn't be able to wish away their liability with a EULA. If data security was an existential risk for companies, you bet security would become an essential part of their product development processes.

But I think campaigning for this isn't part of the IETF's remit. We could change the BCP document, but I doubt it'll stem the tide of sloppy, insecure code.

-Seph

On Tue, 22 Aug 2023, at 2:38 AM, Eric J Bowman wrote:
> Ransomware gangs are targeting MFT (Managed File Transfer) software, these days. What makes MoveIt different, is the wide-open front door is HTTP all the way from unauthenticated SQL POST queries on Port 80, to passing "mystery headers" to a webshell. I'm wondering if we can do a better job in the Best Current Practices document, of moving away from spec-speak to more Hemingway-esque (as phk put it) speak. Here's a bunch of boxes to check. If you don't think you need to check one of 'em, here's a deep link into HTTP backing up this best practice.
> 
> I appreciate your response and perspective. While I agree the problem is not with HTTP protocol per se, I do believe it's in scope to the WG to attempt to mitigate the sort of naive implementations which have led to the recent theft of all my health and financial records.
> 
> -Eric
> 
> 
> 
> ---- On Sat, 19 Aug 2023 01:33:05 -0700 *Willy Tarreau <w@1wt.eu>* wrote ---
> 
>> Hi Eric, 
>> 
>> On Fri, Aug 18, 2023 at 06:51:46PM -0700, Eric J Bowman wrote: 
>> > Hundreds more companies and millions more users affected by the MoveIt breach 
>> > since my last post, which continues to reverberate globally. Yet still, 
>> > crickets from the HTTP world. Yeah, we're all "experts" at online privacy, 
>> > but at some point ya gotta share your info with an insurer, hospital, 
>> > homeowner's association, or whatnot. Even if they aren't using MoveIt, 
>> > they're probably outsourcing something to someone who does. 
>> > 
>> > This isn't me whining about not getting a +1 on updating the best-practices 
>> > document, I get that I have an abrasive online persona. But I am very 
>> > disappointed that nobody else in the HTTP world has anything to say about 
>> > this? I hate being a lone voice in the wilderness, and wonder if I'm the only 
>> > one free to speak out because my career path has long since diverged from 
>> > HTTP. Is everyone else in ostrich mode, because their employer/client is 
>> > breached, or they signed an NDA covering this? Bueller? 
>> 
>> It's not this. It's that I don't see the relation between HTTP and the 
>> thing you shared. I had never heard about that "moveit" thing, apparently 
>> it's file transfer software affected by an SQL injection attack, how is 
>> this any relevant to the HTTP protocol ? 
>> 
>> These days people share lots of data because: 
>> - they're required to by incompetent and lazy services that pretend 
>> that it's easier for everyone ("our offices are open tuesdays and 
>> thursdays from 11:30 to 15:30, but no need to get there in person, 
>> just send us a copy of your ID card"). 
>> 
>> - they're marginalized as annoying people when they don't want to 
>> (e.g. try to disable contactless payment on your card in post-covid 
>> era) 
>> 
>> - tools are incitating to share a lot (how many times a day do I have 
>> to click on "block" in my browser because it asks me to share my 
>> location or to record a password for me; how hard is it to add an 
>> option that says "never ask any the following questions encouraging 
>> morons to share their whole life online") 
>> 
>> - because it makes them famous and gets them a life. 
>> 
>> It's just human nature and nothing at all related to anything that can 
>> technically be solved in a communication protocol. 
>> 
>> I know there are idealists who think that security issues are a thing 
>> of the past that will disappear in the future. History has proven the 
>> exact opposite, and as frameworks and languages become more and more 
>> accessible, the need for a certain experience and software culture for 
>> starting a new project is vanishing, implying that instead the basic 
>> security issues will become more and more common. So it's a total 
>> illusion to imagine that we can do something to prevent a data leak in 
>> software in general. Once the data is stored, it's accessible, either 
>> by the expected means or by unexpected ones. The rule is: do not share 
>> what you don't want to leak (which is an important rule for passwords 
>> by the way). 
>> 
>> But nothing in this discussion concerns HTTP at all. HTTP is just 
>> one of the many vectors used to access, transfer, steal the private 
>> information and there's nothing it can do against it because the 
>> problem is elsewhere. 
>> 
>> Regards, 
>> Willy