Building a website without bugs

A few years ago, I wanted to build a site that hosted up-to-date information that would be pulled from a datastore and provided to clients. The first solution that comes to mind is a simple php codebase that pulls data from a sql database and dynamically displayed to the user, but as well documented for decades now, it's hard to write secure code and new attacks come out all the time to exploit webapp vulnerabilities.

The extreme avenue here, swinging heavy on the security side, is to provide static content. Generally if there's no inputs, there's no injection attacks. But especially when you want to keep content up to date, even real-time, editing HTML and manually inserting new data is impractical.

So I decided to try something slightly in the middle, which didn't sacrifice security and was much more practical. One can write a python script that sits in on the server, pulls fresh data from the database at regular intervals and then generates and places the static content created on the fly in the webroot. Writing code that writes code is often messy, so that won't be fun, but it's really a short-term sacrifice for long-term security with usability. Now obviously this isn't going to be the best option if you want users to actually be able to interact with your site (other than click links or email you), but if you just want to share information, it works great.

How do you attack that website? There's no attack surface at the webapp layer. The database server is sitting on the localhost with only the script authenticating and talking to it. Just keep your webserver and certs up to date, clean data going into the database and fundamentally, you've got a solid setup with no need to worry about vulnerabilities in the website. Welcome to the 0.0001%.

Exploits are not weapons

An exploit demonstrates a vulnerability, either by simply showing that a given impact is possible or adding nice features, logic and ingenuity to make exploitation more comfortable or reliable.

Notice that nothing about that description has a single thing to do with weapons, or anything being weaponized. That's why it's extremely annoying to logic-minded folks when others, some of which are actual security experts and others who couldn't spot a security bug from an oreo cookie, conflate the two. When entire industries and even countries are built on the principle that there's a difference between using something for good and evil, it becomes a problem when a fundamental topic becomes stigmatized for either lack of logical reasoning, profit to be gained or just pure anarchy.

Just as a fancy car can be used to run someone over, or just to drive to work, or how a knife is essential to half your sandwich, but can also be used to stab or stick, practically everything in the world is dual-use, for good or for evil. Banning exploits because evil can be done with them is the same logic as banning lighters or rope.

So sure, an exploit could technically be included in a weapon. We could imagine this just as easily as someone writing with a pen and only seconds later deciding to jab it into skin. There's a big difference and we can see the intent in each. Popping a shell on a box isn't a weapon. Crashing a mail server isn't a weapon. Redirecting your calls via malformed SMS message isn't a weapon unless you use it as one. And most folks are not using it in any relation to one (unless you're the government as has been well documented via years worth of leaks).

Honor the expression of free speech in code: exploits are not weapons and are generally never a component of one. Stop saying the ugly and misrepresented word weaponized in the context of computer security, because you're probably wrong. Remove it from your vocabulary if not only because it's illogical, but because it's offensive to those who have spent sweat, blood and tears staying up all night for years and years coding beautiful ways to travel unintended paths. Consider regulating obvious things which are almost always weapons, but not weird machines.