11 newbie mistakes, which can lead to serious security issues
Software engineers build all kinds of software you may see and use, but on the very beginning of any project we need to think not only about performance and usability, but about it’s security too.
But there are not a lot of software engineers who learn and use best practices to build more protected software. Some of them just don’t care or find excuses to not implement them in their own project — like “I don’t have enough time for this, I’ll do it later…”. For a fresh engineer it’s not easy to keep in mind all those security-related techniques and best practices.
Below are the list of 11 most common mistakes, that may make your product vulnerable. Most of them lead to money or data theft, remote code execution, denial of service or escalation of privileges.
You’ll see results of most common mistakes and how to avoid them.
1. Lack of escaping, wrong formatting, also invalid usage of formatted strings and parameters of the printf function
MISTAKE: Data, that comes from the external source, are not filtrated or validated correctly, as a result it breaks the logic of the program.
THREAT: These mistakes are related to the numerous vulnerabilities and attacks: SQL Injection, NoSQL Injection, XXE, XSS, format string vulnerability and others. As a result it may be a cause of compromising the system.
SOLUTION: Never trust the data coming to your code. Filter and validate everything, use built-in functions and methods in your programming language, that are designed to prevent such vulnerabilities. Like Prepared Statements in SQL.
2. Incorrect processing and storing of confidential data
MISTAKE: Sensitive data, as credit card numbers, passwords or PII. Are transmitted and written to logs and are given to the third-party in open format.
THREAT: Due to insufficient care for confidential data protection, it may become available to a third party.
SOLUTION: You should track all points where sensitive data may be: how it stored, processed, transmitted and where something may go wrong way.
In case of logging or transmitting to the third-party — mask all sensitive data: +1 (555) 123-4567 should be +1 (555) ***-***7.
3. Deserializing untrusted data
MISTAKE: Application deserializing data from the untrusted source without filtering, escaping and validation. This vulnerability has and id CWE-502 and is on 8th position in OWASP Top 10.
THREAT: As a result of attack to the deserialization mechanisms attacker may get an opportunity to execute the code or commands remotely in a compromised system.
SOLUTION: Try to use simple formats (JSON for example) to transmit the data, to store it on disk or in database. Besides, you can have a list of allowed classes and assign serialized data.
4. Keeping credentials in the source code
MISTAKE: Passwords, token, access keys are stored in the source code or in the VCS repository.
THREAT: These credentials can be accessed by third-party. If there are real credentials attacker may easily get access to the system and it’s components.
SOLUTION: Store credentials outside the source code. Use protected parameters storage, configuration files or environmental variables. Here’s a good example why it’s a very bad idea to store credentials in the source code — https://geekflare.com/github-credentials-scanner/.
5. Using unverified someone else’s code
MISTAKE: Use someone else’s code is always easier, but if you didn’t check it — it’s a big risk. Such code may have vulnerabilities or backdoors left there for the purpose.
THREAT: Attacker who knows about the vulnerability or backdoor, can easily compromise the system.
SOLUTION: You should always check the code you want to use in the project, or use only well recommended libraries, for example GSON, Apache Commons, Bouncy Castle etc…
6. Use of outdated libraries or software
MISTAKE: Outdated libraries and software contain vulnerabilities that already described on public, some of them also have step-by-step instructions how to reproduce.
THREAT: Attackers usually familiar about such vulnerabilities. That’s why outdated libraries, software or plugins may be the entry point to compromise the system. Even an inexperienced user can exploit the vulnerability: public exploits help in this.
SOLUTION: Regularly upgrade libraries and software you use. Also specify exact version of library in configuration files — it will help you to avoid compatibility issues in the future.
7. Illiterate use of cryptography
MISTAKE: Cryptography principles aren’t always obvious and unexperienced engineers can “reinvent the wheel” trying to solve some cryptography problems instead of use already proven solution from the community.
THREAT: With untested algorithms, cryptographic strength is reduced: vulnerabilities can appear anywhere. Built-in protection does not work as expected and it’s easy for attackers to bypass it.
SOLUTION: You don’t have to dive deeply into cryptography. But it will be useful to learn the general principles of this science in order to understand when it is necessary to use one or another algorithm, in which situations it is necessary to use encryption, in which — a digital signature, and in which encoding will be enough.
8. Using default passwords or no authentication at all
MISTAKE: The default settings remain in the configurations of various services and software products (databases, CMS, etc.).
THREAT: Weak passwords or lack of authentication are a direct route for an attacker to gain access to the system and its components.
SOLUTION: Do not forget to enable authentication everywhere and change the default configurations to more secure ones. According to cybersecurity best practices, there are two things to take care of first: complex passwords and restricting network access to components.
9. Ignoring official documentation
MISTAKE. In the process of product development, recommendations and practices from the official documentation were not taken into account.
THREAT: If you do not set certain properties on objects, the quality of the code in general will decrease and vulnerabilities may arise.
SOLUTION: All objects that you work with require careful handling and meticulously set properties. The official documentation is a great help in this: it contains a huge amount of practical advice. We regularly encounter situations where the Secure by default approach does not work at all even in very popular open-source solutions. In such cases, the only way to safely use the component is to carefully learn the documentation and possible settings.
10. Client side checks
MISTAKE: Input validation is performed exclusively on the client side.
THREAT: Unvalidated data can get into the server side of the application, which often leads to vulnerabilities (see item 1) or violations of business logic.
SOLUTION: Perform all checks on the server side of the application. Client side checks are not a security measure, but a user experience enhancement.
11. Insufficient logging and monitoring
MISTAKE: The system implements an insufficient number of methods for logging and monitoring of occurring events and parameters.
THREAT: When blind spots remain in the system, there is a danger of missing the anomalies occurring in it and not noticing the attacker attack.
SOLUTION: The necessary amount of logging and monitoring is when you can at any time get an idea of how a particular system component is functioning and what problems arise in it. To avoid blind spots in your data collection mechanisms, it is better to plan uniform logging mechanisms at the stage of system architecture design.
Everyone makes mistakes. But the difference between experienced developers and beginners is the ability to anticipate at least some of them. Thinking about safety, which means thinking strategically, is a sign of a professional. This approach is worth striving for in development.
Good luck!
