backend security series

All developers need to know about using OCSP and CRL for validating TLS certificates in Go apps. Things we’ve learnt while building our own OCSP/CRL validation tooling: design, implementation and security tips, example code and popular mistakes.

In this article we observe security responsibility of cloud providers: where it ends, what are the gaps and grey areas, and what risks security teams should take into account when using “as a service” platforms. So, you’re planning your new business in an area where security matters, and you start thinking about choosing your cloud provider to build your application on. Typically, you start juggling with a combination of all the nice building blocks you need and financial aspects you’re facing.

Intro # When companies move their infrastructures into the cloud, provisioning resources and configuring them to emulate their initial infrastructure — a practice called “lift and shift” — or migrate the existing solutions from one platform to another, something inevitably migrates together with all the code and assets: their security assumptions . The security assumptions affect the major security bottleneck — security team’s time and priorities. And the on-premises threat model and security priorities are very different from cloud-based.

Intro # Any set of security controls deployed in your infrastructure may fail. Given enough pressure, some controls will certainly fail. No surprises here, but the question is – how to build our systems to make security incidents less damaging in case of a failure of some components? How to prevent data leaks even in case of a successful data breach? Building security tools , we strive towards defense in depth approach.

Intro What is the biggest threat to a tool that prevents unauthorised database access? Requests from the application side that trigger data leakage. Namely, SQL injections and other application attacks that allow attackers to craft custom SQL queries. How can we prevent that? The standard industry response is obvious — input sanitization, web application firewalls (WAFs), and prepared statements are typically used for addressing these concerns. We’re shipping a product which aims to intervene into application logic as little as possible but as it turns out, input sanitization is rarely done well, WAFs are not always efficient, and prepared statements are a question of app developer’s choice.

Article updated in 2019. Previously in the series... Previously, we’ve talked about classic design patterns in backend data security, then about key management goals and techniques.  It is important to understand that database security evolved with system administration techniques and programming demands, with cryptography and access controls being complementary features, rather than cornerstones. In classic designs, there are two important drawbacks: Trust tokens: they rely on storing trust tokens somewhere inside the infrastructure;

Intro Frequently overlooked, much less hyped than quantum computers breaking trapdoor functions, managing keys is actually the most important part of building a security system. Secret keys, public-private key pairs, passwords and other factors of authentication are the control vessels within security system. In this article, we will go through basic key management concepts, explain some important ideas for next articles and provide some practical advice you can start implementing within your application tomorrow.

This article was revisited and updated in August 2018. In the modern client-server applications, most of the sensitive data is stored (and consequently leaked) on the backend. At Cossack Labs, we’re working on different novel techniques for helping to protect the data within modern infrastructures. We talk to engineers across industries about these techniques quite a lot, too. However, it is still not uncommon to see infrastructures without even the basic classic database defence patterns.