Code security and safety tips when writing guidelines

Better safe than sorry! That is my motto and the motto of any person practicing web application security!

Preventing cyber-attacks starts at the very beginning of the development of the application by writing secure code.

Following secure coding standards helps developers to prevent common vulnerabilities in the code. Secure coding standards are a set of best practices and guidelines.

It is essential to have secure code standard implementation from the beginning because it will reduce future costs resulting from an exploit or the leak of sensitive data.

In this article, I wrote some practical tips you can use when creating your security code guideline for a simple web application. 

When creating the guideline, it is best to check out as much eligible documentation on the internet about the secure code topic. The complexity of the guideline will, of course, depend on your web application's complexity and requirements.

You can check out these links: OWASP guidelines and/or OWASP Security Knowledge Framework, SEI CERT, Microsoft-Writing Secured Code, and many more. 

I would divide this topic into two parts. One would be about choosing a framework and programming language for your application, and the second would be error handling, logging, and monitoring.  

As for the second part, you can check out the Error handling article I wrote. And I will not cover logging and monitoring topics because I plan to cover them in my future articles. After all, they are essential topics that would need special attention.

Selecting a framework for the application

There are two cases when you would need to choose the framework and programming language: when starting development of the application and when rewriting the application.

When starting to plan the application development and choosing the framework, this decision is often based on the experience of the team who will work on the product. 

The final decision is often to use some old framework because of developers' lack of knowledge and time to learn a new one. Also, when choosing an old framework, its vulnerabilities are not checked. 

I will not focus on that case because the management team probably made a decision. I will focus on developers' decisions, and I will mention that you should choose the framework that is the latest one or one of the latest. That would be the best practice because you will not need to migrate when you have a lot of source code already written. You will have the support of the new framework because it will not be deprecated (that is good because the framework will be tested for the latest vulnerabilities, and new updates with patches will be available). You will be in sync with the technologies!

If you have some older web applications, you can scan them with SCA tools and find all older versions if they have security vulnerabilities. You can check out one article which compares Software Composition Analysis Tools in 2022. This approach will help you with the migrations. You can create a grid of all insecure versions of SCA (Software Composition Analysis) found and suggest the newer versions without vulnerabilities. SCA tools should also be used to scan the repository weekly and in your pipeline on every build.

All frameworks have integrated security features, and it is important to check them out to see if they cover all the security features you want in your product. And keep in mind that by using fewer types of technologies, frameworks, languages, libraries, components, etc., you are reducing the maintenance of systems and the attack surface, which is always good. 

List of security steps

Handling of data

• Validate input: type, size, format, source.

• Verification is performed on the server side. If the input is invalid, reject it and give the user an error message with a description of what you expect.

• If you must accept special characters, you must escape them.

• If an input triggers some CRUD operations such as add, delete, update, verify this is not a CSRF attack by checking the token, captcha, or some other re-authentication

• If the input is presented to the user, input needs to be output encoded.

• If the input is part of the query in the DB, use parametrized queries. So, use parameterized queries (place input in them) with stored procedures to prevent DB injection attacks.

• If you need redirection to a different site in the app, create a list of pre-approved links and check the link when redirecting

HTTP verbs

Most web applications only use GET, POST, OPTIONS, and HEAD. All unused are unrequired and should be disabled to reduce the attack surface.

For more info on how to disable dangerous HTTP methods, you can check out this link.

Identity

You should never create your own system for identity. Always buy a pre-made system unless you have unique business requirements that force you to create your own—in which case, use a well-established protocol such as OAuth. If it is a system within a network, you can use the most common network identity system, Active Directory. Many other identity systems on the market can also perform this functionality, such as some public cloud providers.

Session management

If your chosen programming framework has session management features, use them. Do not write your own from scratch.  

• Session IDs should be at least 128 characters long.

• Use unpredictable IDs.

• Use the built-in session management implementation in your framework,

• The session ID should have an expiration date and/or time.

• The session ID should only be passed over encrypted channels.

• The session should be destroyed after a user logs out.

• Web applications must never accept a session ID they have never generated. 

I already covered all the best practices in session management series parts one and two. Check them out!

Memory safe code

If you are using a programming language that is not memory safe:

• Migrate to the new memory-safe language. The Rust programming language is an example of a memory-safe alternative to C and C++. Examples of memory-safe languages include Java, .Net (VB and C#), and Ruby on Rails.

• Perform bounds and type-checking on every input every single time.

• If your language has a framework overlay available or dependency you can add that can test bounds for you, use it.

• Create unit tests for your bounds checking to make a regressive testing system run on every new code check-in.

• Perform a code review and verify every input has proper testing.

• If available, add compilation options to detect these types of issues.

Authentication

You shouldn't write your own authentication system from scratch. A lone software developer on a project team should always use existing tried-and-true systems. That system can be eighter pre-existing internet identity online service from a third party to verify your users or a free library or software system to become part of your system to perform the identity functionality for you.

Authorization

Role Based Access Control, or RBAC for short is the most popular methodology for determining access. It means "determine someone's access based on the role assigned in your system."

There are three other widely accepted access control models:

• Discretionary Access Control (DAC)

• Mandatory Access Control (MAC)

• Permission Based Access Control (PBAC)

Based on the requirement of the system, you would choose the access control model.

Conclusion

I hope I have given you some direction on creating your own secure coding standard. There are plenty of tips on best practices on the internet regarding secure coding, so you should gather as much as possible before developing your own model. 

You should take initiative to create your secure coding standard and if it was not required to explain to others why it is important to have one.

Cover photo by Matthew Waring