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' 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.
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.
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:
sk_live_ followed by random alphanumeric characterspk_live_ followed by random alphanumeric characterspk_test_ followed by random alphanumeric characterssk_test_ followed by random alphanumeric charactersThis setup makes it easy to detect incorrect key usage by the libraries leveraging their API.
The Ruby library Psych, used for loading YAML files, has two methods: Psych.load() and 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: load and 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, yaml.safe_load().
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."