Error Proofing in Application Security
Hello everyone, and welcome back to AppSecSchool! Today, we're diving deep into a crucial part of application security - error proofing, or 'poka-yoke' as it is known in the manufacturing sector.
Poka-Yoke: A Brief Overview
'Poka-yoke' is a Japanese term, coined by Shigeo Shingo in the 1960s as part of the Toyota Production System. It translates roughly to 'mistake-proofing'. Essentially, it is a mechanism that helps prevent mistakes by focusing on preventing errors before they occur.
A classic example of 'poka-yoke' is the design of IKEA furniture assembly. The components are designed to fit together in only one way, minimizing the chance of errors.
Applying Poka-Yoke to AppSec
In the context of application security, error proofing involves creating a system that helps developers prevent and catch security errors. It acts as a guide, ensuring each piece of our 'security furniture' fits correctly, minimizing the creation of vulnerabilities.
Examples of Error Proofing
Example 1: Stripe Payment Gateway
Stripe, the payment gateway, has a set of keys for production and testing, each containing a publishable key (public) and a secret key (confidential). The roles of the keys are embedded in their values, simplifying error prevention. For instance:
- Secret key in production:
sk_live_ followed by random alphanumeric characters
- Publishable key in production:
pk_live_ followed by random alphanumeric characters
- Publishable key in testing:
pk_test_ followed by random alphanumeric characters
- Secret key in testing:
sk_test_ followed by random alphanumeric characters
This setup makes it easy to detect incorrect key usage by the libraries leveraging their API.
Example 2: Function Naming in Psych Library
The Ruby library Psych, used for loading YAML files, has two methods:
Psych.unsafe_load(). This naming convention helps developers or reviewers understand that one method may not be as safe as the other. It contrasts with the Python library PyYAML's function naming:
safe_load, which doesn't make the safety distinction as apparent to someone unfamiliar with the library. Reading code with
yaml.load(), you would have to check the library's documentation to find the safer function,
Example 3: Using 'except' in Ruby on Rails
In Ruby on Rails, controllers have filters to ensure proper authentication and authorization. These filters allow you to specify a list of actions the filter applies to (for example, with the keyword "only"), or exclude a list of actions you don't want your filter to apply to (for example, with the keyword "except"). It is best to use "except" when applying these filters, as this forces developers to opt-out of the check instead of relying on them remembering to opt-in.
The goal of error proofing is not to create an infallible system, but to make it easier for developers to write secure code and harder to make security mistakes. Just like IKEA makes it simple for us to assemble furniture without errors, we want to construct our applications and libraries in a similar manner. As appsec professionals often recommend: "Make secure the default and insecure obvious."