Application Security Tips for New Developers–Series Introduction

  • The global financial messaging system, SWIFT, was the victim of an $81 million cyber heist from a Bangladeshi bank due to shoddy security.
  • LinkedIn had 117 million accounts stolen from its databases.
  • Tumblr got hacked and had 65 million accounts leaked.
  • The browser company Opera had its synchronization server hacked, leaking the passwords of 2 million active users.
  • Yahoo had over 500 million accounts compromised.
  • 400 million accounts were leaked from AdultFriendFinder, with many passwords revealed in plain text. They also weren’t really deleting accounts when users asked for it.

(source for all of these: zdnet)

I can keep going, but I’m sure you get the idea. Actually, I’m sure you already know this (unless you are living under a rock). The point I’m making is that security should be a top concern of all developers, whether new or experienced. These stories also illustrate the incredible amount of damage that can be done if security is not taken seriously.

The piece of these stories that is often hard for me to understand is the fact that so many of these incidents are caused by completely preventable vulnerabilities. Of course, the truth is that no system is 100% safe and there are always vulnerabilities that you may not know exist. However, many common vulnerabilities can be easily mitigated with the right tools. Also, even if a vulnerability is missed and exploited, there are other measures that could have been taken that would have greatly reduced the impact in case data is exposed.

Security Controls

The unfortunate truth is that many developers focus solely on getting functionality out the door and don’t pay any attention to properly securing their applications. When the development team has this attitude, it leads to incidents such as the ones listed above. I don’t want any developers, especially those new to software development, to make a major mistake that leads to a vulnerability that gets exploited. The best way to prevent these vulnerabilities is to bake them directly into the development life cycle from the start by using security controls. These controls provide a baseline against which an application can be tested and possible risks and vulnerabilities can be found.

Normally, security controls span across an enterprise and don’t stop at just an application being built. However, web applications in particular tend to touch many different pieces of an overall information systems architecture of an enterprise. For instance, how an end user interacts with your web application will reveal possible ways to attack you. How many third party APIs are in use by your site? Are there any companies with which you have a relationship and therefore need to exchange information with in a secure way?

Obviously, just having a set of controls in place does not guarantee safety. That is why other avenues of an information security program are important, such as penetration testing, static code analysis, and scanning tools that can find vulnerabilities you may have missed. Like I said, security controls can provide a solid baseline. They can be decomposed into security requirements that have to be implemented for your applications as a matter of course. I hope to show by this series that these preventable vulnerabilities can be taken care of by careful planning and the use of solid security controls (along with a solid risk management framework).

The purpose of this series of posts is to introduce many of these preventable vulnerabilities and teach you how to prevent them. We will focus mainly on web applications. The posts will follow this format:

  1. Describe the vulnerability (with some examples)
  2. Describe what controls should be in place to prevent or mitigate the vulnerability.
  3. Investigate what specific .NET tools and libraries can be used to implement the controls.

Below are the list of specific topics this series will cover:

  1. Threat Modeling
  2. SQL Injection
  3. Protect Your Passwords (my post here)
  4. The Client is Evil!
  5. Insecure Deployment
  6. Client-Side Attacks

I look forward to this series and I’m sure it will be full of practical techniques to ensure your application won’t lead to the next big headline.

Leave a Reply

%d bloggers like this: