LAST UPDATED May 03, 2022
I’m not a security professional; I’m an engineer. But when you work at a startup, you often need to be both. I’ve worked at several startups over the years, and have discovered ways to shift my engineering mindset to include a security focus and to incorporate security into my coding. In this post, I’ll explain how I discovered an idea at the beginning of my security journey and how to use this concept to help your engineering teams build secure software.
About a decade ago, I found a need for application and API security experience in startups. In a small organization (10-50 people), you probably don’t have dedicated API/AppSec resources. If you are lucky, you’ll have an InfoSec contractor.
It turns out that an engineering organization can significantly contribute to API and app security, but how we think about software makes it difficult to get started. When working on security, there is an alternative perspective, and I call it:
The Road Not Taken
We create and optimize applications to solve problems for real users. Engineering time is in short supply, so we optimize the speed at which we can write those applications. To achieve velocity, we simplify problems and find reusable patterns or techniques. Add a bit of glue, and you have software.
This perspective is constructive. Thoughts come first, and the software comes next. And when refactoring software, we need to think this way. It is necessary to separate “behavior we want” from “behavior that exists.” But utility comes at a cost: If the software works, we only see what it should do. The real story can be much more complex.
I have an example from many years ago. I was working with an engineer on new endpoints for an authorization API. We were working out an issue in the implementation: I could call the endpoints out of order and bypass a challenge. We worked through the example, and he said, “but they are supposed to be called in 123” order.
Attackers don’t share this perspective. Instead, they want to manipulate the software to act in their interest. They ask, “what is possible?” and find ways in which the system fails. To an attacker, the glue is more interesting than the design.
Ah, the password reset endpoint is on v2? Is v1 still running? What happens if I skip the verify endpoint? What happens when I pass null in the challenge? Empty string? SQL injection?
If the software works, we only see what it should do. The real story can be much more complex.
As creators, we’ve converged on this constructive perspective. To build secure software, we need to consider The Road Not Taken.
Playing Defense
When you are defending software, your limited time is your disadvantage. There are many engineers, and some have been writing software for many years. That means you have a lot of code to defend. Each application depends on hundreds or thousands of open-source projects, from libraries to deployment tools to server operating systems.
Security tools help. ThreatX’s API Protection platform can help you think from both perspectives. Our API Discovery features profile the software you run in production (without any agents). We discover endpoints and track response statistics. You can use this data to understand how code maps to your public API surface. Our Threat Entity views correlate activity observed from an attacker. We track where, when, and how the attacker interacts with your software.
In addition to tools, here are several suggestions for on the ground techniques that you could try out.
Read the Code
Pick an application. Find out where the authentication and authorization code is, and go read it. Even if you aren’t a strong coder, you can learn something interesting. Take the attacker’s perspective, and look for ways you can make the code work for you:
- SQL injection might be possible in this area … I might be able to extract information about other accounts …
- Authorization is complex and confusing in this area … I might be able to use my standard user account to execute actions on other accounts …
- Logging is very weak in this sensitive area … I might be able to hammer this endpoint without being noticed …
- Code or comments indicate the developer assumes the application is secure for a particular reason … Can I break those assumptions with an external request?
This knowledge is priceless. You can use it to guide the rest of your API/AppSec work (pen testing, scan remediation, etc.). And you’ll often find logical vulnerabilities that scans couldn’t detect.
Read Code Reviews
Engineers make decisions in Pull Requests. Content in past PRs and review comments have tons of context. Look through the history. Then, think through some security-focused review questions:
- If the code tries to enforce security constraints, can I think of a way around them?
- Are there obvious security mechanisms that should be part of this change but are missing?
- Would unusual attacker behavior appear in logs?
You might find a sensitive action without any authorization logic. Or ways a user account can access data owned by other users. Or a path through the password reset flow without a valid challenge token.
Work With Engineers
If your engineers are working on security-relevant code, ask for some time to talk. Find out what they are working on (and why). Help them think like an attacker, and explain some of the techniques an attacker might use to break their app. And make it fun!
Thanks for reading! If you are interested in more, my colleague Sam Placette wrote a great post More Simple = Less API Attack Vectors, which dives deeper into API defense.
