Comment by simonw 17 hours ago
I miss the days when "implement your own blogging engine" was one of the most popular learning projects for engineers.
We should bring that back! Its such a great way to play around with client- and server-side development options in an almost zero-risk environment.
Still a good project when one learns a new programming language.
yep. What makes it good is that it's an easy concept to imagine the use cases, but contains subtle details that covers the breadth and depth to gain the experience you need/want. Getting it wrong is not a death sentence (as long as you quarantine the project to it's own, rather than make it part of your home setup...).
Everything web-facing, if it's not a static website delivered by a well-tested web server, happens in a high-risk environment. And doubly so, if, like in this case, stuff like custom cgi libraries are involved. One has to be either very confident in their skills to do that or very, very brave.
My point here is that if someone breaks your blog, they've broken your blog. The blast radius of that should be strictly limited.
Obviously don't go rolling your custom CGI scripts on a server that also hosts your personal email - but these days we are spoiled for choice in terms of isolated hosting strategies for a blog.
Heroku, Vercel, Cloudflare Workers, Fly.io, GitHub Pages, a $5/month VPS...
Philosophically: L'État, c'est moi, build your crappy cgi scripts with nginx or apache all from the CLI and all in vim and you will understand.
Practically: Ports 22, 80, and 443 open and directly accessible from 0.0.0.0/0 is extremely manageable.
Yes, if they do it for fun.
If they do it for money they will install something else and run it in parallel with the blog of the owner of the server. If they are good they'll be lean with resources and not get noticed for months or years. Example: I don't run ps -ef on my server very often and even if I did there are things that can be hidden from ps. It can get complicated.
In any web application all data that comes from the outside world is potentially hostile. A decent web framework takes care of basic security measures, does input sanitation, provides referer checking and csrf for forms, etc. When you roll your own, your _are_ on your own to do that all properly yourself, if you even know all the potential pitfalls. And if you write your own cgi library like the op even more so. I'm not advocating for using WordPress either. I'm advocating for either having a static blog or using a decent, tested web framework or the the very least cgi module that provides tested implementations of common security features that in my experience are typically missed in self-made cgi scripts.
Nah. There are ways to mitigate the blast radius of experiments like this.
You can't utterly wrap developers up in cotton wool. Ultimately, people learn strong lessons from screwing up. You can at least make sure they're doing this learning within a sandbox in which the damage is contained. Like, maybe containerising it so it has limited access to anything that could do any real damage. If somebody builds a blogging app and the worst thing that happens is that they learn the value of sanitising your input, preventing SQL injection, that spam is an unfortunate fact of life, and that you should be very careful with how you manage cookies, I would consider that a _very_ big win for that novice developer.
Because we're talking about _developers_ here.
When I was a teenager I wrote my first "CMS" and was very proud. A few months later someone called my parents and asked for me. He said he was a developer and found some issues with security. He gave me a few tipps and suggested me some books and left for good. Never talked to hm again but this was so kind and I learned a lot about secure coding after that.