Comment by ganamadaduun a day ago
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.
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.
I am not exactly sure about using containers (most likely you mean docker/podman) as sandboxes...
Please correct me wrong but for a better form of sandboxing, I would recommend something like microvm and the bottlefire thing which was recently shared if that might pique your interest as I found it to be interesting and then using it with something like https://github.com/Zouuup/landrun
There is also tinykvm and other projects too which can simply take a binary and run it and I think that maybe developers should also try out all the different sandboxes and different things just for understanding as well I suppose too. To me, I really like playing with different form of sandboxes or such technologies in general.
Also do note that I am not sure if bottlefire provides sandbox/isolation by default as they mention Sandbox with Landlock seperately so I am now a bit confused if they provide sandbox by default or not as I previously thought it might have.
Sure, there are many ways to achieve the same end of limiting blast radius, but that's not really the point here: the point is that we should dismiss projects like this solely because something might go wrong, especially when there are ways to mitigate against real damage.
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...