From Automating Administrative Tasks to Testing API Security

Back in 2007, I decided to pursue the MCSA and MCSE certifications. I was convinced these were the standard requirements for getting into Windows Server administration, much like the CCNA was for getting an IT networking job.

I started with the Microsoft Certified Professional (MCP) certification for Windows XP. The exam was a breeze. I found the material easy to understand and passed without much difficulty. I assumed the remaining certifications required for MCSA and MCSE would be much the same.

My next choice was a certification covering Active Directory Users and Computers (ADUC).

As part of the preparation, I found myself working through tasks involving the creation, modification and deletion of multiple users and security groups. Most of these exercises required navigating the Microsoft Management Console (MMC).

I soon grew tired of repeating the same operations through the graphical interface. I wanted a quicker way to get things done.

🔗My first encounter with automation

I started looking for ways to automate Active Directory administration and came across examples using VBScript.

I had never used VBScript. Looking at the code, I wasn't particularly interested in learning it either. The syntax and approach didn't appeal to me, and I eventually abandoned my attempts to pursue the MCSA/MCSE certifications. Much of the certification material simply wasn't making sense to me at the time.

A few years later, I found myself working in IT security administration at a bank.

One of my everyday responsibilities was managing Active Directory users and security groups. The same tasks I had struggled through during my certification preparation were now part of my actual job.

There was one important difference: PowerShell was available.

I was immediately drawn to it. Operations that previously required navigating multiple MMC screens or writing lengthy VBScript code could now be accomplished with relatively simple PowerShell commands.

Creating users, modifying group memberships, disabling accounts and performing bulk administrative operations became much easier.

🔗From Windows to UNIX

My next move was to the UNIX team.

Our environment relied on KornShell (ksh) for scripting, while access administration was handled through Keon/BoKS.

The underlying systems and tools were different, but the repetitive work was familiar. There were manual commands that needed to be executed repeatedly, and I started scripting those operations as well.

I learned to work with KornShell and gradually became comfortable automating administrative tasks in a UNIX environment.

KornShell was my preferred shell for quite some time. I don't use it nearly as much anymore, but it remains a part of my technical background.

🔗From scripts to building tools

Initially, I was scripting individual administrative commands. Eventually, I started building tools that brought multiple operations together, allowing users to perform tasks through an application rather than execute individual commands.

I began working with what are commonly known as CRUD operations:

• Create
• Read
• Update
• Delete

I had been performing these operations for years without knowing the terminology.

I started building tools that used these principles within applications. Later, I began connecting applications so they could exchange information and trigger operations in one another.

This was where APIs entered the picture.

Rather than having someone manually move information between different systems, one application could retrieve information or perform an operation through another application's exposed functionality.

🔗The tools along the way

My choice of scripting and programming languages evolved with the environments I worked in.

PowerShell is no longer limited to Windows. I also use it on Linux and FreeBSD.

Python has become another important part of my toolkit, particularly when building applications, working with data and integrating different services.

🔗Fast-forward to API security

Today, my primary focus is testing API security.

Having spent years building tools and connecting applications, I now spend much of my time examining those same interactions from a security perspective.

An API exposes functionality and data to other applications, services and users. Consider a banking application. Its APIs might provide:

• Account information and transaction history.
• Money transfers and payment authorisation.
• Beneficiary management.
• User profile management.

A successful authentication does not automatically mean that a caller is authorised to perform every operation.

A customer who can view their account should not be able to view someone else's account. Permission to view an account should not automatically grant permission to initiate a transfer. Similarly, being allowed to update a profile does not mean every property within that profile can be modified.

These are some of the fundamental questions I look at when testing API security.

🔗What constitutes API security?

I generally look at API security across six areas:

1. Authentication and identity: OAuth 2.0, OpenID Connect, JWT, API keys, mTLS and token validation. Establishing who or what is making a request.

2. Authorisation and access control: Object-level, function-level and property-level authorisation, role-based access control and tenant isolation. Establishing what the caller is permitted to do.

3. API infrastructure security: API gateways, reverse proxies, TLS, request validation, rate limiting, secrets management and configuration security.

4. API vulnerability assessment: BOLA, broken authentication, mass assignment, injection, SSRF, unrestricted resource consumption and business logic flaws.

5. API security monitoring: Authentication patterns, authorisation failures, anomalous requests, unusual resource access and indicators of data exfiltration.

6. API governance and lifecycle security: API discovery, inventory, OpenAPI specifications, security testing in CI/CD, version management and decommissioning.

🔗The OWASP API Security Top 10

The OWASP API Security Top 10 provides a useful reference for understanding common API security risks.

The 2023 edition identifies ten categories. Three particularly important ones are:

• API1:2023 - Broken Object Level Authorization (BOLA): Accessing resources belonging to other users.
• API2:2023 - Broken Authentication: Weaknesses that allow authentication mechanisms to be bypassed or identities compromised.
• API3:2023 - Broken Object Property Level Authorization: Accessing or modifying object properties without the required permissions.

An API can authenticate a user correctly and still expose another user's information because its authorisation checks are inadequate. It can also allow a user to modify properties they should only be able to view.

These are the kinds of distinctions that make API security testing interesting.

🔗Closing Thoughts

I didn't set out to work in API security when I was preparing for the MCSA and MCSE exams in 2007. At the time, I was simply looking for a way to avoid repetitive work.

The journey took me through PowerShell, KornShell, Python, application development and integrations. Each introduced me to a different way of working with systems.

Today, I find myself examining the same interactions that I once worked to build and automate, except now I'm looking at them from the other side.

Looking back, it was a natural progression from automating systems to building them, connecting them and eventually testing how secure those connections really are.