Developing With An Eye on Security

In this article, I am going to talk about building software with a conscious of security. Which may lead to building software that not only works but is secure too.

Not often do developers pay attention to security when building applications, mostly, the focus is on developing a functioning application.

I will be addressing technics that can be used or coupled into your organization’s development pipeline. And most example will be given in Node JS.

Getting started

In the world of security, the first thing that you will need is to formulate a security policy.

Now, this sounds like more work, doesn’t it? Yeah, it does!!! However, it is work worth practising. Before we jump into details of a software development policy, let try to understand the three words that are cardinal in the world of security which are;

• Availability
• Integrity
• Confidentiality

The questions to ask are on these three objectives are;

• can I use it every time I need to use it?
• can I trust this?
• and lastly, is it just me or has anyone else seen this too?

when these three are achieved, then you can say the system or the application is secure, cause security forms the intersection part if it is to be illustrated in a Venn diagram.

4

The idea is to find the balance when you make the application too available you will hinger on confidentiality and it might loose its integrity. When you dew much on confidentiality the application might not be available. Hence, one needs to find balance between these three.

Now that we have identified the three main objectives that that make up a secure system or application, I feel like we can dive into great practices when developing secure software or systems.

The question to ask is very simple since security is relative. You only get to secure that which is important or of great value. So, what I may consider important and need to be secured may turn out to be not important to you hence you will not try to secure it.

Now that you understand, the first step is to identify what is important to you or your clients?

Below are tips on how to get started with secure software development

Using secure protocol (HTTP/HTTPS)

Most applications utilise TCP’s HTTP protocol when communicating over the Internet. However, ordinary HTTP is only good at one thing, which sending data form sending machine to receiving machine. It does not account for data security. Thus, applications developed on this protocol will risk exposing data that is being sent over the network. If one launches a man-in-middle attack they will be able to see what is being sent and God be with you if this is a financial application.

To address this problem, you may need to opt for HTTPS which is secure. and regardless of the type of application you are developing, just jump on HTTPS other than HTTP.

WIRESHARK SCREENSHOT OF COMMUNICATION OVER HTTP PROTOCOL

This is an example of a dummy man in the middle attack with wireshark on localhost. The server was using HTTP and one can clearly see the data that was being sent.

However, when the connection was changed to HTTPS the data in the JSON array would not be seen as it was encrypted as shown in the image below. Hypertext header is visible when using HTTP and is not visible when using HTTPS

WIRESHARK SCREENSHOT OF COMMUNICATION OVER HTTPS PROTOCOL

Whitelisting Over Blacklisting

In systems security the terms whitelisting and blacklisting both hold a certain meaning, they are the first thing one does if they are trying to create a network and security policy and they are too the first things you may need to look at.

To define these terms and understanding them is important. To define these with an example would be.

Think of this as a grocery list, the things you write down on the list means they are the things you are going to buy. That is what whitelisting is.

On the other hand, blacklisting would mean the opposite, using the same concept of a grocery list. This would mean, the things on the list are the things you are not going to buy.

From this, you can clearly see that is is harder and costly to come up with the list of things you will not buy than what you are going to buy. I

t means you must know all the possible attacks that can occur and provide remediation for them. However, it becomes easier to only have a list of what to allow and broke anything that is not in the list or listed.

In development, this means binding access to your database to connect only from a list of listed IP addresses. Maybe also allowing your backend server to connect to a list of listed IP-address that is hosting your frontend. e.g in Node js this could be archived with the use of cors package like this.

const cor = require("cors");
const express = require("express");
const app = express();
const options = {
      origin: “https://your App IP address: App port",
       optionsSuccessStatus: 200
};
app.use(cor(options));

NOTE: adding an upper sand in the origin of cors option would mean that your server is accepting connections from every IP-ADDRESS. :)

Whitelisting could help too in preventing domain walk attacks as opposed to blacklisting. You can check up domain walk attacks on the Internet to get more knowledge on it and how it is perpetrated.

This can also mean, binding your database to only accept connections from your server that has a particular IP-ADDRESS other than from any IP-ADDRESS

Exposing application development tools and packages

One of the first things attackers look for when they embark on an attack is to find out the tools used to build a system, this includes packages too. Since there is a need to speed up the software development process and one of the ways to do that is adhering to the notion of Don’t Repeat Yourself (DRY).

As developers, we tend to use other people’s already written software which is bundled as a package that can be imported.

For example, if the application that am building needs a login feature, other developers have already written a package that does this, all that I need to do is to just integrate it into my application workout all needed compatibility issues and I will be up and running in no time. This is great, right!!! However, it comes with its own cost and consequences.

Mostly you are not the one maintaining all the packages that you import into your project (mostly are open sourced) that means you are only as secure as the guys who own and maintain the packages.

The questions to ask are ;

1. How often do they update discovered vulnerabilities?

2) How long does it take to produce a patch for those vulnerabilities and make it available?

3) And lastly, what is the estimated damage you are likely to incur if one was to hack your application through this package’s vulnerabilities and what is the cost?

To remediate such instances, hide your development tools and packages, your application should not expose such information when it's in production.

An example in Node js would be using helmet package to hide that you are using express package for creating server APIs. There should be other ways and concept that can do other than this on the internet.

Below is an example of how you can go ahead and do this in Node JS and helmet package.

const helmet = require("helmet");
const express = require("express");
const app = express();
app.use(helmet());

you can go further and configure helmet for some of its advanced use cases. You can search the Internet for more information on the use of helmet and other related packages.

Avoiding typosquatting

Typosquatting is when a malicious package that has the same name as a legitimate package is pushed into package repositories like npm. This is usually not noticed and not easy to combat cause the package will still provide the same capabilities as the original one.

This happens and I am sure has happened to every developer, imagine you want to install body-parser package from npm package manager like this.

npm install body-parser

Now since you are fast, you misspell the package name instead or body-parser to body-parser

npm install bodyparser

You may find that this will go ahead and install. If this is a malicious package, it will still provide the capabilities of body-parser but also sniff out data to attackers. This is just because you did not pay attention to install the correct package. And since it provides its functionalities, it may go without notice for years.

Know the packages to install and check for there correct spelling before going ahead and install them. NPM package manager takes an effort to catch such packages but you are better of being safe

Terming the regular expression engine

Regular expression engine is one of the most powerful engine in a programing language. For those that do not know what it is. It's an engine that is used to recognise patterns in a string or search a string for certain words, phrase or letters. It does this very fast. However, denial of service attacks can be caused when the engine is given a string and pattern that forces it to be in an infinite loop. This could be, a string that is carefully constructed to force the engine to move back and forth in a loop and never reaching an end.

To avoid such, sanitize you input data such that they do not trigger a regular expression engine and also initialising variable to there right data type.

Find out more from the Internet on how you can best avoid denial of service attacks through regular expression.

Vulnerability disclosure policy

This might sound out of the box but it's mostly effective once implemented. A vulnerability disclosure policy is one process that has kept most of the huge companies afloat in the midst of cyberattacks.

So, what is a vulnerability disclosure policy if we are to ask?

this is a procedure that stipulate what one should do in the case that they find a vulnerability in our product. It is not mostly exercised but it reduces the damage on the product.

Some companies require those that find proven vulnerabilities in there product to report through a stated channel and letter own can gain recognition or given incentives after confirming that the vulnerability is true.

By doing so, this prevents anyone who finds a vulnerability not to disclose off to the public before the company develops a patch and announce it to either virus totals and National Vulnerability Database.

If it was so, most users that use your product will be vulnerable to anyone that perpetrates the attack on them. This is mostly known as zero day attack, cause software maintainers would have had no time to patch the vulnerability

A simple vulnerability disclosure would be a phone number and added or attached incentives on anyone that reports a vulnerability.

Remediation plan

No system is secure at some point someone will manage to break into you system or product at some point. It is important to have a remediation plan.

What actions do you take when your system is attacked, this includes steps?

It is better to have a remediation plan in place if you are maintaining a software product that you developed and in some extent reduce the damage impact once infiltration occurs.

Read up on best remediation concepts on the Internet and how to implement them.

Thanks for the read and enjoy practicing.

Happy Coding!!!