Putting It All Together for a Robust Defense

Layers of defenses

Adding database permissions to the widespread use of stored procedures leaves us with a layered defense that can serve as a model for how we want to defend other parts of our system. We start by defending as much as we can with a nearly bulletproof defense like prepared statements. We then expand the scope of our defense with ongoing diligent development. Finally, we minimize the impact of development mistakes with the one-time application of a broadly effective defense like database permissions. We also set up our system so that attacks will be noisy.

Alerts

Noisiness here means that attempts to carry out these attacks can be made to stand out. When we build alerting into our system, we can’t allow many false positives because that won’t scale, will burn out employees, and will lower urgency around responding to alerts. The alerts we’ve discussed should never happen under well-meaning use of the system, so if we detect these attacks, we have a high-quality indication that an attack is underway. With built-in alerting, the system can notify support staff and possibly take defensive action, such as locking accounts.

Diligence when coding

This defense requires a lot of ongoing diligence during development. The problem is that diligence is scarce. So if we can’t easily increase the amount of diligence we’ll be able to bring to bear, let’s try to minimize the number of places where we need to use diligence. It’s a good idea to introduce some kind of shared framework code to minimize the number of places where diligence is required. Make it easy for application developers to do the right thing and make it clear which parts of the code should access the database and which shouldn’t. Don’t overlook the importance of examples. Future developers who haven’t joined your team yet will draw heavily on the code they’ve inherited when they write code. Make it easy for them to find good examples in your codebase.

Ending intro to SQL injections with a joke!

We started the chapter with an explanation of software vulnerabilities by way of a knock-knock joke. Now that we’ve taken a good look at SQL injection, let’s reward ourselves with a software vulnerability joke that’s actually funny. Check out Bobby Tables by Randall Munroe.

---

In the next lesson, we’ll get an introduction to cross-site scripting.