Here's a template for training and documentation when you are using this method:
#Software wrapper for security code
#Software wrapper for security how to
How to write the training and documentation Just train the developers to use the safe version of your class, rather than the default one for the framework they're using. The above code is a simple example of a safe-by-default class. Public MySafeRegex(string pattern) : base(pattern, RegexOptions.None, defaultTimeout)
make your constructor use the default timeout by default Private static TimeSpan defaultTimeout => TimeSpan.FromSeconds(1) create your default timeout of one second Make the good pattern your defaultįor simplicity's sake, you could just make a safe version of the regex class - let's call it "MySafeRegex." It's going to inherit from the base regex class, have a built-in timeout, and look something like this: This makes the problem difficult and complex for just one type of security bug. Note that there are a lot of other ways to use regex without a timeout, so you'll have to cover each of those as well. If they forget even once, you could have a vulnerability on your hands. Regex good = new Regex("(a+)+", RegexOptions.None, timeout) Safe var timeout = TimeSpan.FromSeconds(1) So the following code would be vulnerable to a ReDoS attack:įor developers to use regex safely, they would have to remember to include a timeout such as the following every time: The bad patternīy default, using the base regex class has no built-in timeout. Although the example that follows is written in C#, this pattern works in Java and other languages or frameworks. Here's how to identify and solve this in a. This holds up a process or thread of an application, consuming resources and making the server unreachable for legitimate customers. Regex denial of service occurs when a regex pattern takes exponential time to evaluate. How to block regex denial of service forever Then you just recommend and enforce the use of the safe wrapper instead of using the library directly. This simple solution involves writing a safe wrapper class around libraries or functionality that has unsafe behavior by default. Developers will then use the default behavior of the library most of the time.
So, instead of having the safe way be the more complicated way, make things safe by default. They rarely have time to do that on top of their regular job, and that training often requires them to retain knowledge that's specific to security and the libraries they are using. But the frameworks are not trustworthy, and that leads to developers shooting themselves in the foot.Įven the worthy goal of training developers to understand security can lead to problems. Security for developers, made simplerĪ lot of security training for developers goes against both common sense and what they have learned, which is to rely on the framework for simple tasks and then build cool things using a framework they can trust. Here's how to standardize how developers use your framework's risky parts. So it comes to pass that the developer who just wanted to use regular expression (regex) or parse XML ends up exposing your application to serious security vulnerabilities, such as ReDoS or XXE. But usually the framework has vulnerabilities in its standard libraries-and developers then use the unsafe, default version. Their job is to build features or complex systems, and they have to build with the framework they are using. Developers just want to get the job done, so they often write insecure code that just works. It's tiring when you have to constantly remind developers to follow secure practices, and this often burns out security teams.