We’ve covered just some of the basics here. If you’d like to dig in deeper, I recommend reading the following:
- “The Basics of Web Application Security” by Martin Fowler: This article is a concise, general guide on how to write secure web- based software.
- Pushing Left, Like a Boss: A great series of blog posts on how to adopt strong security practices earlier in the development cycle.
- DataSploit: If you want to dig into what information is publicly available about the domains that your organization controls, take a look at DataSploit. This is an open-source tool that queries a number of public repositories of information, including Shodan and Censys. It’s designed to be used manually, but it also works nicely when called automatically. Scheduling it to run automatically on a regular basis and saving the output can give you a picture of how your public footprint has changed over time.
As we look back on the vulnerabilities we covered in this chapter, we see two main classes of vulnerabilities. In the first, an attacker is able to inject code of their own choosing into the system. In the second, operators accidentally leave the system in an insecure state.
Interestingly, the defense for both looks fairly similar. First, we make a one-time effort to find the vulnerabilities and fix them. We then layer on automated defenses to prevent mistakes from reintroducing the vulnerability. As teams and systems grow larger and older, we want to have more than vigilance keeping us from introducing vulnerabilities into the system; we want the system to prevent vulnerabilities from being introduced.
In our next chapter, we’ll take a look at how we can use cryptography to secure the systems we build. We’ll also see how seemingly small mistakes can let an attacker break weak cryptography. Just like how a seemingly small flaw in our SQL allowed an attacker to bypass permission checks earlier in this chapter, seemingly small flaws in cryptography can leave our systems unprotected.
Let’s get right into it!