Pricing
Contact
Login
Start Free Trial
Back

Code security and safety tips when writing guidelines

Nov 17, 2022

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

Tags

  • #vicarius_blog

users/photos/cl6niebam1ye50joc8lsmaiql.jpg

Written by

Jenny R

Recent Posts

  • 1

    CVE-2023–23752: Joomla Unauthorized Access Vulnerability

    Mohammad Hussam Alzeyyat March 24, 2023
  • 2

    Apache Zero Days - Apache Spark Command Injection Vulnerability (CVE-2022-33891)

    Mudassar Zafar March 22, 2023
  • 3

    CVE-2022-44666: Microsoft Windows Contacts (VCF/Contact/LDAP) syslink control href attribute escape vulnerability

    j00sean (https://twitter.com/j00sean) March 01, 2023
  • 4

    KeePass Passwords Theft CVE-2023-240550

    Youssef Muhammad March 01, 2023
  • 5

    CVE-2022–44267: Denial Of Service in ImageMagick

    Mohammad Hussam Alzeyyat February 28, 2023

Related Posts

By Mohammad Hussam Alzeyyat
Mar 24, 2023

CVE-2023–23752: Joomla Unauthorized Access Vulnerability

In this blog, we are going to analyze the information disclosure in Joomla that allows an attacker to exploit it to gain unauthorized access. we will dive deep inside the flow of Joomla, how it works, and how the vulnerability happened.
By Mudassar Zafar
Mar 22, 2023

Apache Zero Days - Apache Spark Command Injection Vulnerability (CVE-2022-33891)

The Apache Spark command injection vulnerability (CVE-2022-33891) was discovered by the Sangfor FarSight Labs team and reported to the Apache Spark project team on July 18, 2022. The vulnerability was classified as high severity, with a CVSS (Common Vulnerability Scaling System) Base Score of 8.8, indicating a high potential impact.
By j00sean (https://twitter.com/j00sean)
Mar 01, 2023

CVE-2022-44666: Microsoft Windows Contacts (VCF/Contact/LDAP) syslink control href attribute escape vulnerability

My thoughts and more on this bug!
last_chanse_02.png

Start Closing Security Gaps

  • Risk reduction from Day 1
  • Fast set-up and deployment
  • Unified platform
  • Full-featured 14-day trial
Get a Demo
Start Free Trial!

Have questions?

By submitting this form, you agree to be contacted about TOPIA and other Vicarius products.

Vicarius develops an autonomous vulnerability remediation platform to help security teams protect their assets against software exploitation. Consolidating vulnerability assessment, prioritization, and remediation, Vicarius strengthens cyber hygiene and proactively reduces risk.
We're hiring!

Support

support@vicarius.io

Sales

sales@vicarius.io

Marketing

info@vicarius.io
Product
Product Overview
Vulnerability Management
Patch Management
Patchless Protection
Auto Actions
Network Scanner
xTags
0-Day Detection
Solution
Solution Overview
Case Studies
Knowledge
Research Center
Apps & OS Patch Catalog
Videos
Articles
Docs
Company
About
Investors
Partners
Trust
Careers
Pricing
Pricing
Compare
TOPIA vs. Automox
TOPIA vs. ManageEngine
TOPIA vs. Rapid7
TOPIA vs. Tenable
TOPIA vs. Tanium
TOPIA vs. RMMs
TOPIA vs. Vulcan
TOPIA vs. PDQ
TOPIA vs. Qualys

Copyright © Vicarius. All rights reserved 2022. Privacy Policy and Terms of Use