Over the past few months, we have witnessed the growth in the trend for generating awareness programs about secure application development.
Security in software products constitutes an emerging property dictated by the cohesion of multiple factors throughout the development process, from its very conception to the death of the product. When we talk about evaluating the security of computer programs, we refer to a set of activities throughout the development cycle that is born with the idealization of the system and extends over the design, codification, and strengthening of it.
We must not fall into the mistake of confusing system security with its characteristics, such as the use of certain protocols such as SSL. Nor should we confuse it with the security components that are embedded in the system architecture, such as the presence of firewalls, or limit it to compliance with a particular regulation or certification.
How do we guide secure development?
To help assess security maturity in the software development process, the exhibitors at paceap.com presents a list of common problems when designing applications, which may affect security in the final product. Let’s see what these tips are for safe design.
- No component is reliable until proven otherwise
A common mistake in software development is to encompass sensitive functionality in a runtime environment over which we have no control. It should not be assumed that system components are reliable until this can be demonstrated.
For example, if we have a client-server environment, precautions should be taken against adulterated potential clients by deploying verification mechanisms. We must think that it is in the domain of the user who will not always have the best intentions.
- Outline authentication mechanisms difficult to circumvent
Authentication is the process that allows us to prove the identity of the user and assign him a unique identifier. The development of centralized authentication methods that cover every possible path of entry is one of the pillars in the construction of secure applications.
If it is web pages, we must think about which sites will require the management of authenticated users, and take care that undue third parties do not intrude on the system from unprotected URLs. The use of multiple authentication factors will allow us to strengthen the system by checking not only what the user knows but, for example, also what the user has.
- Authorize, in addition, to authenticate
Authorization is the process that designates whether or not an authenticated user can take an action that changes the state of the system. Authorization processes for authenticated users must be thought through design and prevents sessions that have fallen into the wrong hands.
- Separate data from control instructions
- Validate all data explicitly
Entries to the system should be evaluated with a whitelist over blacklist philosophy: determine what will be allowed, and deny anything that does not correspond. We must think that an attacker interprets the data as possible programming languages, with the intention of manipulating the state of the system. Therefore, it becomes necessary to inspect these input data, generating automatic procedures to bring them into well-known canonical forms.
Furthermore, this validation of inputs must take place close to the moment in which the data is actually used since the gap between validation and use provides a window of opportunity for the generation of attacks.
To implement this, you can design common components that centralize both syntactic –structural– and semantic –meaning– validations and take advantage of the data types present in the programming language you are working on.