DEV Community: Michael Rossoni

Building Secure REST API Services with Python

Michael Rossoni — Mon, 09 Mar 2020 21:36:55 +0000

Introduction

In this multi-part secure development guidance series, learn how to develop a lightweight (and secure) REST API using Python and a third-party OAuth service. As we go through this series, it will contain several articles containing a sample project and architecture diagrams that can help you get a good understanding of how to write a secure REST API from scratch using Python.

Let's get some of the background stuff out of the way first. I've used APIs in the past that advertise as RESTful but are everything but that. I want to make sure my readers get the gist of REST before we start making one! If you already know all of this stuff, you can jump to part two of this series (coming soon).

Topics in this series

Introduction to REST (this article)
Common Acrhitecture Patterns
Requirements Guidance (The OWASP API Security Project)
Python Environment Setup and Secrets Management
Setting up Data Models and Interacting with Databases
Testing tools

As much as I'd like to get into AWS Lambda and explaining security around "serveress", we'll save that for another series.

What is REST?

REST is an acronym for REpresentational State Transfer (REST), an architectural guide for creating data services. It is used to help us create scalable, performant, and reliable services to represent our data and our workflows. When this new architecture was introduced by Roy Fielding in 2000, it was introduced around the same time that HTTP 1.1 had become standardized, and much of the REST framework was optimized as part of the HTTP 1.1 roll out.

REST started becoming popular in 2005 and rapidly accelerated to make up about 70% of most web APIs in 2014. Today, it's rare to see SOAP APIs in use unless you're in an enterprise environment where upgrading back-end services is not cost efficient.

REST has six guiding principles:

Client-Server model - keeps the user interface away from the data storage parts
Stateless - Session state is kept entirely on the client - In the realm of security, we would typically rely on the server to provide the session context. But since we're stateless, we need to be creative in how we manage a state-like behavior, maintain security, and not fall into REST anti-patterns! Yikes! Since session state needs to kept strictly client-side, we will be cautious and utilize tokens which contain encrypted payloads between the user interface and the API
Cacheable - The data within a response may be implicitly or explicitly labeled as cachable or non-cachable. If a request is cacheable, then the client must be able to reuse that data later, and has the option to request new data as necessary. Again, in the realm of security, we need to take care that sensitive data is not stored client-side past the time the token expires.
Uniform interface - the principle of generality simplifies the interface and increases the visibility of interactions between components
Layered system - these types of systems are built on top of hierarchical layers which should not be able to see past the immediate layer in which they are interacting
Code on demand (optional) - by default We will prefer to not run code on demand in our secure REST interface because it introduces another layer of uncertainty and scrutiny. While it is convenient there is a possibility that this could be used for malcontent.

If you're interested to see an example of a non-HTTP REST interface, check out the Constrained Application Protocol (RFC 7252), which is meant for constrained devices (low power, low memory CPUs, e.g. 8-bit micro controllers) on constrained networks (lossy connections).

Resources

A good REST API will have resources as endpoints, and resource methods (in most cases, HTTP verbs) that will describe the actions that an API consumer can make on those resources. These are commonly mapped to objects in programming, or entities in databases. Typically, this means that resources should be addressed just with their name, and not with any actions associated with them. A good resource will have three attributes:

Understandability
Completeness
Linkability

Routes

A rule of thumb that I like to follow: keep the API deployed on a separate container as the rest of your application. This will allow you to give the service name a unique hostname in the FQDN instead of relying on your app to route to a separate 'subfolder'. This will allow you to update the API independently from the rest of the application, and will allow you to create multiple apps (web, mobile, thick client, etc.) to access the data.

A good resource route will tell a consumer of the API will be of the following format, replacing the parameters in the handlebars with your own:
https://{{apiUrl}}/api/{{version}}/{{serviceName}}/{{resourceType}}/{{identifier(if used)}}

What about Endpoints?

An endpoint is the URL, including the service name, that hosts access to specific resources. Some use this interchangeably when they mean to say route or resource. In my material, if I mention "endpoint", please be mindful I mean "service endpoint" and not "route" or "resource". While most of the time we're hosting these REST APIs over HTTP, it is also possible to use other protocols like WebSockets. You can have multiple service endpoints with the same resources; you can also have multiple resources at the same endpoints. Sometimes the endpoints appear as application gateways and route to other microservices behind a load balancer/reverse proxy.

Part 1 Conclusion

Now that I've explained some of the principles of REST, we'll talk a bit more about the different layers and architectures commonly used. Start thinking about the terms Transport Layer, Middleware, Service Layer, Data Layer, Separation of Concerns, and what they mean to you.

Until next time!

Hacking the SDLC: Win the Minds of your Developers

Michael Rossoni — Sat, 18 Jan 2020 22:50:31 +0000

How many times have you handed off a test report, or performed a test readout, to have developers say, "eh, we'll fix it when we get a chance" and then it goes unfixed for months? How do we get into their heads and help them modify their software development life cycle to take security into account?

Developing a product security group (or application security group, AppSec) is not an easy process that can be solved with tooling alone. The technical aspects will likely remain the same from company to company, however, the people and business processes do not. Developers are busy writing functional code and can't take the time from developing for their minimally viable product (MVP) to fix normal bugs. Formulas for success should incorporate styles that will win the hearts and minds of your developers. My experience is that friendly chats, camaraderie, empathy, commiseration, and bribery (yes, bribery) work well.

Companies which have a fledgling application security program might experience these symptoms:

Most of the developers want to do the right thing (but aren't enabled to do so)
Stakeholders need an minimally viable product (MVP) right away; security can wait (we need customers!)
Product owners won't prioritize security features (although these are getting easier to implement)
Security vulnerabilities are deprioritized and sit in the backlog, adding to technical debt

The Search for Purpose

As a small part of our large company, we get wrapped up in our work and sometimes lose focus on why our company exists. This is sometimes difficult to believe, but companies have one purpose -- to generate revenue. Who are we to get in the way of generating revenue? We all need to be on the level and be honest with each other: The purpose of the AppSec team is to help the company guarantee that the software they create allows them to continue being profitable. What does that mean? This means, as advisors, we need to help developers identify security issues early in their development process, through architecture reviews and training. Throughout the development process, we need to help them ensure the application fits the confidentiality, integrity, and availability requirements: Does the data need to be protected? Can we be sure the data hasn't been tampered with? Are we meeting the company's availability targets by avoiding performance problems?

That's great. I think I'd be able to do this if I were in the shoes of the engineering director, but how can I be successful in an advisory role?

Developers, Engineers, and SREs are your friends

This is the most impotant part of this job to understand. If you don't read anything else in this article, this should be the section you take away. A program cannot be successful if you're viewed as an adversary towards developers and their teams. This concept seems obvious at first glance, and once you've participated in a product team's Sprint Review / demo and see what their product does, you'll see that developers are where the solutions start and where the problems end. In your first weeks in the role of an AppSec Engineer, make an effort to meet with several team leads to get an understanding of how the company operates. If you've moved into a product security position from within your company, your developer peers might already know you.

The last thing most of us like to do is sit in meeting after meeting, but we all need to eat and drink at some point, right? Get together for beverage of choice, or a meal, and chat about common interests, like the latest version of Angular or React, games, dogs, etc. Keep this as a one-on-one meeting. Introduce yourself as you would meet someone else that's outside your company. It's important to note the tone of this meeting is informal, but you should get to learn as much as you can from this person. Do the same thing with others across different product lines and teams. You should start to build rapport with these people, as you will be working with them on a fairly regular basis as part of your job. Glean as much information about the people they work with so you can build out your portfolio of individuals that you can lean on for information.

Towards the end of your meeting, ask them what bothers them most about security, and listen.

Product Owners and Stakeholders can be your friends, too

In the same vein as working with developers, engineers, and SREs, we need to be on the best terms with the product owners and product stakeholders. Treat them in the same fashion with the initial meeting with our peers.

In most cases, the stakeholder is typically the person (or people) who are driving the requirements of the product. The product owner (PO) is typically the person in charge of making sure the right work is getting done in the proper order, among other important tasks. If the development team is using Scrum, you can also meet with their scrum master.

The product owner is responsible for satisfying the requirements put forth by the stakeholder. In most cases, a product owner will ask their team to prioritize all of the user stories to satisfy the stakeholder, and will typically de-prioritize bug fixees unless they're blockers during the MVP phase of rolling out a product. What sometimes happens is these bugs end up polluting the backlog well past the MVP and will probably be ignored, adding to the team's technical debt. It's important that the product owner and stakeholders understand that new security assessments, pen tests, automated code scans, and integration of security tools into the CI/CD pipeline (DevSecOps), you'll be adding to their backlog of security items to fix on a constant basis.

POs and Stakeholders are the ones to give you the most pushback. If you don't experience any pushback it's likely they're just ignoring you. You will affect their timeline when you find high risk issues, so make sure you negotiate a remediation schedule with them, and engage with your manager at the same time. This way, you can come to an agreement that makes sense for everyone, and you can focus on helping the engineers find a good solution for remediation.

Conclusion

These are two approaches to helping you become successful in an AppSec program. If you find these tips to be helpful, or if you have tips of your own, please leave a comment below!