I am not a security professional; I am an engineer. But when you work at a startup, you often need to be both. I have worked at various startups over the years and have found ways to change my engineering mindset to include a focus on security and build security into my coding. In this post, I’ll explain how I discovered an idea early in my security journey and how to use this concept to help your engineering teams build secure software.
About a decade ago, I discovered the need for API and application security expertise in startups. In a small organization (10-50 people), you probably don’t have dedicated API/AppSec resources. If you’re lucky, you’ll have an InfoSec contractor.
It turns out that an engineering organization can contribute significantly to API and application security, but the way we think about software makes it hard to get started. When working in security, there is an alternative perspective, and I call it:
the road not taken
We create and optimize applications to solve real user problems. Engineering time is at a premium, so we optimized the speed at which we can write those apps. To achieve speed, we simplify problems and find reusable patterns or techniques. Add some glue and you have the software.
This perspective is constructive. Thoughts come first and software comes next. And when refactoring software, we should think this way. It is necessary to separate the “behavior we want” from the “behavior that exists”. But utility comes at a cost: if the software works, we only see whatshouldmake. The real story may 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 solving a problem in the implementation: I could call the endpoints out of order and avoid a challenge. We worked through the example, and he said, “but they’re supposed to be called in order 123.”
The attackers do not 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, is the password reset endpoint on v2? Is v1 still running? What happens if I skip the verification endpoint? What happens when I pass null in the challenge? Empty string? SQL injection?
If the software works, we only see whatshould make. The real story may be much more complex.
As creators, we have converged on this constructive perspective. To build secure software, we need to considerthe road not taken.
When you defend 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. Every application relies on hundreds or thousands of open source projects, from libraries to deployment tools to server operating systems.
Security tools help. ThreatX API Protection Platform can help you think from both perspectives. Our API Discovery features profile the software you run in production (without any agent). We discover endpoints and track response statistics. You can use this data to understand how code maps to your public API surface. Our views of threat entities correlate the observed activity of an attacker. We track where, when and how the attacker interacts with your software.
In addition to the tools, here are several suggestions foron the floortechniques you could try.
read the code
Choose an app. Find out where the authentication and authorization code is, and go read it. Even if you are not a strong programmer, you can learn something interesting. Take the attacker’s perspective and look for ways to make the code work for you:
- SQL injection could be possible in this area… It could extract information about other accounts…
- Authorization is complex and confusing in this area… I may be able to use my standard user account to perform actions on other accounts…
- The record is very weak in this sensitive area… You may be able to hammer this endpoint without being noticed…
- The code or comments indicate that the developer assumes the app is safe 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 (penetration testing, scan remediation, etc.). And you’ll often find logical vulnerabilities that the scans couldn’t detect.
Read code reviews
Engineers make decisions on Pull Requests. Past PR content and review comments have tons of context. Look through the story. Then think of some security-focused review questions:
- If the code tries to enforce security restrictions, 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 show up in the logs?
You might find a sensitive action without any authorization logic. Or the ways a user account can access data belonging to 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 time to talk. Find out what they’re working on (and why). Help them think like an attacker and explain some of the techniques an attacker could use to break your application. And make it fun!
Thank you for reading! If you’re interested in more, my colleague Sam Placette wrote a great post.Simpler = Fewer API Attack Vectorswhich delves into API defense.
The charge Think Like an Attacker: How to Add Security to API and Application Development first appeared in ThreatX.
*** This is a syndicated Security Bloggers Network blog from Web Application and API Protection Blog written by Austin Jones. Read the original post at: https://www.threatx.com/blog/think-like-an-attacker-how-to-add-security-to-api-and-application-development/