Security and How to Have More of it

It is necessary to pay attention to security from the very beginning. One major source of insecurity I observed was complacency: it is easy for project contributors to simply assume that a system is secure unless it has been proven otherwise; but if no one is trying to prove that it is insecure then problems will never be revealed. I have found that people and teams become skilled at things that they practice, and which form a part of the team’s habit. Teams that don’t write tests, won’t want to write tests, because its members aren’t good at writing tests. Similarly, teams which are not in the habit of actively considering security requirements and reviewing code with that in mind will produce insecure code; features will be developed only with the functionality in mind. An example of a security flaw I recognized and helped to correct is that our GraphQL endpoint was completely unsecured. Securing an endpoint by sending and processing auth headers is not complex, but this was not configured by the individual who initially setup up the endpoint, and subsequent developers did not think to check. The approach I used to identify this flaw, and others, which I think is generally applicable is a form of lateral thinking. Instead of asking “how can I make this feature secure?” I find it useful to instead ask “How can I make this feature insecure?” and then do the opposite, or to ask generally “How can I use the information available to attack my employer, to cause the greatest harm possible?”.

This mindset causes a developer to think about and investigate what sorts of information are available in different architectural components and how that information can be used if that component is compromised. This naturally leads to principles like least privilege and network isolation, since these approaches limit the information available and its utility. In the case of the unsecured endpoint, I was investigating what information could be viewed from the browser dev tools, which I noticed that the request for Physician information did not include an auth header, but returned the physician’s details anyway. It then occurred to me that by examining all of the GraphQL requests being sent, an attacker could easily discover the complete structure of the database, and could thus query or mutate any data they desired. There was another case where it I realized that I was executing a script that used the AWS CLI for operations that I myself didn’t have authorization to perform. Upon investigation, it turned out that although every developer had an AWS account with limited roles, the key we used for AWS API access was the root account key. In other words, every developer had the ability to delete the production database!

In addition to actively considering security during design and review and in using lateral thinking, it is also necessary to use all available tools for security, especially including static scanning. Test-driven development is also useful here; API tests should not only test the happy path, but should also make invalid requests, and verify that the correct “unauthorized” error occurs.