Erik Romijn

An appeal for security for the ordinary developer

A few days ago, I noticed #truebugswait on twitter. A parody of American sex education campaigns, endless jokes were made about ill advised coding practices that can trigger nasty bugs. Many of these related to security issues:

I have a lot to look forward to in life. That’s why using strcat isn’t an option. Only abstaining from strcat can 100% protect me from overflows and memory disclosures. — @natashenka

They told me that timing channel was not exploitable due to the large block size of existing MACs. They were wrong. #truebugswait — @matthew_d_green

Now, I am aware that tweets are only 140 characters, and that part of the joke was to follow an existing style. However, it made me think about how we communicate about security, and why I think we can improve this significantly.

I’ve always had an interest in security, since the first time a friend exploited a command injection vulnerability in my PHP script, a long long time ago. However, a lot of code is being written by developers with not nearly as much knowledge and insight into security as I have. And that’s not because I know so much: there are so many others out there with so much more knowledge and experience.

There are developers that simply don’t care. They have such a disinterest in the security of their systems and their users, that nothing we will ever do will change that. But, I am convinced there are many more developers that are most eager to learn, but frightened by a perceived high learning curve. And this is where we can make a great leap forward.

Secure cookies should be as common as unit testing

In the last few years, I’ve specifically focused on bringing basic security knowledge to as many ordinary developers as I can. I’ve spoken about Django security at Djangocon, built a tool that helps Django developers find basic externally visible security concerns, and I’m doing similar things for iOS security. My goal is simple: every developer should have a basic understanding of security issues might apply to their work, how to find or work around them, and also have a better understanding of what they don’t know, so that they involve a professional timely. Knowing about secure cookies should be as common as knowing about unit testing.

An inspiration in this is the Django community, where all sorts of activities are undertaken to welcome newcomers, make them feel comfortable and help them grow continuously. And that is precisely what I would like to see in security as well. But I can only do so much on my own: we need to do this together.

A feeling of helplessness

So what should we do? I started by mentioning the #truebugswait tweets, and how it made me think about our communication about security. This style of communication, which I see quite often in security topics, makes it very easy for newcomers to feel utterly helpless. You are told that a particular practice is bad security-wise, but do not know how to improve, and it’s too abstract to figure it out on your own. I happen to know that strncat is safer than strcat because the latter can cause buffer overflows, and otherwise the manpage of strcat is quite vocal in explaining this. I have only a vague idea of how the block size of MACs influences timing channels. In other words, if we help developers discover what is wrong, it is most vital that we show them a clear path towards improvement. If we fail in the latter, as I see very often, we’re actually making it worse: we are reinforcing the idea that security is something abstract and frightening, and something the ordinary developers can not even begin to understand. And therefore not worthy of any of their time or consideration.

Now, it would be most unfair to judge the entire security community on a single twitter topic. Allow me to stress that I’m not blaming anyone, and don’t believe any of these habits have malicious intent. But I am convinced there is a great opportunity for improvement.

Another example where I see helplessness as an issue, is the Qualys Labs SSL server test. This is an absolutely magnificent tool for testing SSL server settings, and I run this past anything I build. However, if it tells me there’s an issue with my ciphers, like forward secrecy not being supported in all browsers, there’s not enough information for me to actually do anything. I wish they would just tell me which ciphers to prefer in which order. Instead, I google for someone else who has done this, copy their cipher configuration, and rerun the test. If that does not work, the most tempting is to simply give up. I should add that they did write an extensive best practices document that covers many basics, but not nearly all.

In Erik’s Pony Checkup I try to be very clear and explicit in my explanations. Do you have Django debug mode enabled? Then the issue is your DEBUG = True setting. And here’s a link to the documentation about debug mode. X-Frame-Options not enabled? Add this line to this setting, here’s a link to further Django documentation, and a link to generic info on this header and clickjacking attacks. In every explanation, I aim to clarify the seriousness of the issue, but most importantly, also offer something actionable on which the user can move forward. If you feel any of the text can be improved, please create an issue or a pull request.

Making security as simple as possible

(Even better than awareness is prevention. As Alex Gaynor raised recently: instead of writing a library with methods like parse and parse_safe, call these parse_insecure and parse. Help developers use the secure default. Instead of sending developers to PyCrypto with a long story about high quality random initialisation vectors, proper HMACs and a lecture on block cipher modes, let’s build a library that does the right thing, like RNCryptor. I particularly like RNCryptor because it already includes simple serialisation and works cross-language. I am in no way suggesting that PyCrypto is a bad library, but a library like RNCryptor can make common use cases, like “I want to encrypt these bytes with this password”, much simpler and safer, compared to every developer having to configure PyCrypto correctly on their own. Django follows this already in many areas: the default password hasher, session management, and so on, should always be completely safe. Sometimes improvements in that area are even prioritised over keeping backwards compatibility.

Although there are many security professionals, so many projects are being built by independent developers or small groups on their own. But even with little effort, there is often a lot they can accomplish regarding security. The more inclusive and accessible our communication is, the more we can help all these developers to increase their basic understanding of security, show them how it doesn’t have to be frightening, and help them grow. That way, I believe we can make great leaps for the security of the average software or system, of which we have so many out there.

Update: tweets are 140 characters, not 160 :)

Further reading

From this blog, you may also like A basic guide to when and how to deploy HTTPS, But where is the decryption key? and Proof of concept: arbitrary remote code execution through pickle-backed cookie-based sessions

For more details on how to configure your ciphers and other SSL settings correctly, you can have a look at the Qualys Labs SSL server test, their best practices document, and the Mozilla TLS documentation, although that last one can be a bit daunting for the inexperienced. Applied Crypto Hardening is also very promising, but still in draft, offering both directly usable config snippets, and extensive explanation of rationale behind the choices.