RFC 9205 vs. CL0P

Going back 25 years, I was using Ipswitch software and so were all my Windows-based customers, on my recommendation, but that's how I learned all about failing to secure ports 25, 80, and 443 -- and SQL-injection attacks. Their indifference led to migrating away, on my end, but yeah... here we go again. Is this major ongoing HTTP hack (note FTP still up, lol) seriously because Ipswitch still thinks /endpoint{?SQL} is a REST API? Can we work some language into the BP document which plainly states that, in this day and age, if you're still coding /endpoint/{?SQL} then you're an incompetent idiot?



Don't even get me started about webshell headers (e.g. X-siLock-Step{x}) wouldn't make it to the back-end on any webserver I've coded going back 20 years, sanitize those headers instead of passing 'em through, good grief! Maybe we should explain how to properly recite the alphabet, in detail, in an RFC somewhere? The extent of the incompetence on this one (compromised .aspx and .dll's, srsly?) is staggering. But, and I'll calm down even if this whole thing upsets me, it would be nice to have a BP document (RFC 9205) where I can point to the exact wording says "/endpoint/{?SQL}" is a STUPID THING TO DO.



I wouldn't think it needed to be pedantically spelled out, same with sanitizing headers and maybe return 400 for anything not whitelisted, in 2023. But apparently, simple Kindergarten-level script-kiddie SQL injection attacks (with a couple years planning how to exploit it) are still a problem, particularly with MFT software (ugh, use FTP plz), even if it isn't targeted at some 20-year-old appliance (like last time, where my alma mater didn't cave and all students were compromised). Can this sort of thing be (politely) worked into RFC9205, and if so, how?



-Eric