Excellence in Software Engineering
Secure Coding
06 April 2021

Author: Kani YARAR, SW Expert – Application Development and Management Group

It is hard to withstand ever-expanding attacks with old coding habits. Many attacks on corporate applications come from inside the network, thus rendering such protection mechanisms as firewalls useless. It has become imperative that the application is capable of protecting itself. All security issues are rooted in the code itself. The starting point of the secure coding concept is based on the idea of avoiding security errors in the first place instead of fixing them. So, what should be done to gain secure coding skills?

Increase Awareness

Lack of awareness of security risks causes developers to introduce such risk into source code. The reason for making these mistakes unintentionally, especially among junior developers, is the lack of security-oriented software training in universities. Unfortunately, the security concerns are gained through self-learning during work experience.

You cannot take protective actions to attacks without knowing the attack vectors. For that reason, the first thing that needs to be done is increasing your awareness of known methods of cyberattacks. Do your research, there are various types of attacks have been using by attackers to exploit application vulnerabilities. Knowing these methods will navigate you to mitigate your application vulnerabilities.

You can find so many sources regarding the issue but I can suggest one source for a start – Open Web Application Security Project (OWASP). They are publishing Top 10 security risks such as injection, XML External Entities, Cross-Site Scripting, etc. Also, providing detailed documents for developers on how to mitigate them

Learn and Apply Secure Coding Practices

Secure coding practices may vary depending on the programming language you use. For instance, while you don’t worry about memory management in Java, you should be dealing with C / C ++. Since the subject is broad, I want to focus on one of the secure coding practice, which is valid for all.

Input Validation: Unvalidated inputs cause a fairly broad type of vulnerabilities. Input validation, a method used to detect intrusion before the input is being processed by the application. Many vulnerabilities fall under this umbrella, including SQL injection, command injection, buffer overflow, XSS, etc. To better understand the importance of the issue, SQL injection has been the number one vulnerability for over 15 years, although it can be prevented by applying input validation techniques. Input validation should be applied on both semantic and syntactical level.

  • Identify all data sources and classify them as Trusted and Not Trusted. Verify all data from untrusted sources. (e.g. user input)
  • Encode data to a common character set before validating (Canonicalize).
  • Use Whitelisting instead of Blacklisting.
  • Validate for expected type, data range, data length.
  • Be careful about potentially hazardous characters like < > \ “ ‘ % ; ( ) + \’ \”
  • All validation failures should result in input rejection.

 

Take Assistance from Automatized Security Tools

Errors are inherent in coding. Even the most conscious and well-trained developers still make mistakes, so relying on them to write safe code isn’t enough. You need tools to help them detect and correct their mistakes. For this purpose, there are two kinds of tools to help developers: SAST and DAST.

Static Application Security Testing (SAST) also known as static analysis, is a testing methodology that analyzes source code before the code is compiled to point out potential software vulnerabilities. Analyzes the whole code, which is nearly impossible to do with code review. SAST tools can provide guidance on how to fix issues, without requiring security expertise.

Dynamic Application Security Testing (DAST) analyzes the application without accessing the source code, so DAST is considered as black-box testing. DAST scans application at runtime independently from its underlying technology. DAST tools could be helpful for detecting: Server configuration mistakes, Cross Site Request Forgery, SQL injection, XSS, Memory corruption, Buffer overflow, etc.

Being aware of security vulnerabilities and writing code with this awareness will surely increase the quality of the product. In an environment where the variety of attacks are constantly changing, saying that you will write safe code by giving technical hints will only save the day. When you apply them, they will only be valid for a period of time. It would be a much more accurate approach to know all current or old attack types and to take preventive measures against attacks that your application may be exposed to. Continuous research and learning should never end to stay on the safe side. We should ask ourselves how much we are aware of old and current attacks and do we constantly update ourselves on this?

Past Articles

Why Built-Operate-Transfer (BOT)?

Why Built-Operate-Transfer (BOT)?

“ In the last months we have received some BOT demands from some large enterprises especially from Europe and we had several negotiations with them. Below we want to share with our followers our impressions regarding the concerns, feelings and the alternative searches of any CEO of any enterprise in case of expanding their production into other countries.”

Common Criteria provides a wealth of information about IT security

Common Criteria provides a wealth of information about IT security

Setting up a multilingual full functional support team in a short timeframe is not easy. It requires well-planned transition and efficient team selection process. There are more incompetent support advocates compared to excellent ones and also transition process planning requires unique experience and has lots of technical and business risks to overcome.

How we set up a multilingual full functional support team in a short timeframe – while transferring years long operation

How we set up a multilingual full functional support team in a short timeframe – while transferring years long operation

Setting up a multilingual full functional support team in a short timeframe is not easy. It requires well-planned transition and efficient team selection process. There are more incompetent support advocates compared to excellent ones and also transition process planning requires unique experience and has lots of technical and business risks to overcome.

Navigation