Developers are at the base of any software, and from the very early stages they have to think not only about the performance and effectiveness of the product, but also about its safety.
However, few programmers in their specialty study methods of writing secure code or aspects of cryptography. Keeping cybersecurity techniques and potential vulnerabilities constantly in mind is a daunting task, especially for a beginner.
We have collected 11 common mistakes that can make your application vulnerable. For the most part, these errors involve theft of money or data, remote code execution, denial of service, or elevation of privileges.
1. Lack of escaping, incorrect formatting, as well as incorrect use of the format string and parameters of the printf function
Problem. Data entering the application from an external source is insufficiently validated and filtered, as a result of which the application logic is violated.
A threat. Such errors are associated with a number of vulnerabilities and attacks: SQL Injection, NoSQL Injection, XXE, XSS, format string vulnerability, and others. The consequence of such deficiencies can be the possibility of compromising the organization”s system. Decision. Filter and validate all data from external untrusted sources, and use built-in programming language tools designed specifically to address these issues (for example, Prepared Statements in the case of SQL).
2. Incorrect work with confidential data
Problem. Sensitive data, such as bank card numbers, passwords or personal information, are displayed in logs or transmitted to a third party in clear text. A threat. Due to insufficient care for confidential data, they may become available to a third party.
Decision. Track the chain of work with confidential data: how it is stored, processed, transmitted and at which of these stages something can go wrong. In case of logging or transmission to a third party, apply masking.
3. Deserialization of untrusted data
Problem. The application deserializes data from an untrusted source without sufficiently validating it. This vulnerability is identified as CWE-502 and is ranked eighth in the OWASP Top Ten critical risks for web applications.
A threat. As a result of an attack on deserialization mechanisms, an attacker often gains the ability to remotely execute commands on a compromised system.
Decision. Whenever possible, use simple formats (such as JSON) for transferring data and for saving it to disk or a database. In addition, whitelist the valid classes and sign the serialized data being passed.
4. Storing authentication data in the source code
Problem. Passwords, keys, tokens are stored in the source code or source code repository.
A threat. Information from the code can get to third parties. If authentication data is stored there, an attacker can easily gain access to the system or its components.
Decision. Keep keys, passwords and tokens separate from the main project code. Whenever you need to transfer them to your application, do it, for example, through environment variables or separate configuration files.
5. Using unverified someone else”s code
Problem. It”s always easier to use someone else”s code, but if you haven”t tested it, it”s a big risk. Such code may contain vulnerabilities or deliberately abandoned backdoors.
A threat. An attacker who knows about the existence of a vulnerability or a backdoor could compromise the system.
Decision. Do not risk unnecessarily: be sure to check someone else”s code, and it is better to always refer to already proven libraries, such as GSON, Apache Commons, Bouncy Castle, and so on.
6. Using outdated versions of libraries and software
Problem. Outdated versions of libraries and software contain vulnerabilities, information about which is in the public domain.
A threat. Attackers are well aware of such vulnerabilities. Therefore, outdated libraries, plugins and software can become an entry point when a system is compromised. Even an inexperienced user can exploit the vulnerability, using publicly available exploits.
Decision. Update the versions of the libraries and software you use regularly. Also specify in the configuration files specific versions of the libraries: in the future this will help to avoid compatibility problems.
7. Illiterate use of cryptography
Problem. The principles of cryptography are very unclear and inexperienced developers use their “crutches” instead of proven tools in an attempt to invent a better solution.
A threat. With untested algorithms, cryptographic strength is reduced: vulnerabilities can appear anywhere. Built-in protection does not work and it is easy for attackers to bypass it.
Decision. 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 coding will be enough.
8. Using default passwords or no authentication at all
Problem. The default settings remain in the configurations of various services and software products (databases, CMS, etc.).
A threat. Weak passwords or lack of authentication are a direct route for an attacker to gain access to the system and its components.
Decision. 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
Problem. In the process of product development, recommendations and practices from the official documentation were not taken into account.
A threat. If you do not set certain properties on objects, the quality of the code in general will decrease and vulnerabilities may arise.
Decision. 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 study the documentation and possible settings.
10. Client side checks
Problem. Input validation is performed exclusively on the client side.
A threat. Unvalidated data can get into the server part of the application, which often leads to vulnerabilities (see item 1) or violations of business logic.
Decision. 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
Problem. The system implements an insufficient number of methods for logging and monitoring of occurring events and parameters.
A threat. When blind spots remain in the system, there is a danger of missing the anomalies occurring in it and not noticing the attacker.
Decision. The necessary amount of logging and monitoring is when you can at any time get an idea of how this or that system component functions 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.