Last update 28/12/2022

CyberSecurity Practices

In this documentation you will find extra information on various practices that will complement your secure development. We invite you to consider them in order to considerably improve the security of your integration.

Log auditing and logging

It is essential to have concrete evidence that allows us to understand what is happening in our application (to alert us) and what happened at a certain time with a certain user, endpoint or resource.


To implement this, we have several possible alternatives:

  • Logging: the term log is used to refer to the record of events that are occurring or have occurred in an application or system. Generally the events are of 5 main types: informational, debugging, warning, error and alert.
  • Audit: is a set of records that provide evidence of the set of activities that affected a resource or event over time.
  • Monitoring: is a diagnostic tool that we use to know the status of the application.

  • Warnings!

    Logging of sensitive data.

    Logging of sensitive information, personal data, secrets or confidential information should be avoided as much as possible.


    Protection against automated attacks

    There are some cases in which we want a user to be able to use some functionality of our application but in a limited way to avoid abuse of the functionality. A clear example of this can be the login: we want the user to be able to enter email and password to validate the credentials but we also want to prevent malicious users from abusing the functionality by sending thousands of passwords and mails to validate users.


    It is important to mention that in this instance we are not trying to defend against denial of service attacks.


    Rate Limiting

    Rate limiting is the practice of limiting traffic to the application or its components based on a certain rate. The idea behind this practice is to establish a finite number of times that the user will be able to access the desired functionality. For example, "a user will be able to make 5 money transfers per hour".

    Reference of Rate Limit strategies and techniques.


    Captcha

    The objective of CAPTCHA is to avoid automation by giving the user an option to "recover" from the detection of anomalous behavior by presenting a challenge that only a human could solve correctly.



    In general, the reCAPTCHA engine is delegated to detect anomalous behavior or thresholds based on which to display the CAPTCHA. There is the alternative of reCAPTCHA v3 in which the service returns a score and we can decide when to show the user the challenge and when not to show it.

    reCAPTCHA Implementation Reference.


    Secrets

    Sometimes it is necessary to use some secret in our applications, for example, access credentials to a database, a key to consume some service or some random value to sign messages.


    In these cases, a bad practice can occur, which consists of leaving the secrets hardcoded in the code. By doing this, the secret becomes available to everyone with access to it.


    How to implement it?

    The best practices for storing secrets or keys indicate that you should use the environment variables to store these secrets or use a host external to the source code of the application, where all the credentials for the operation of the application are stored.


    The same hosting can be configuration files, databases or specialized services for storing secrets such as those available in the services of different cloud providers, and must be strongly protected against access by outsiders, including other local users on the same system.


    Warnings!

    In many occasions, when using versioning systems, we mistakenly leave the secret in the code and when we realize it, we make a new commit. By doing this, the secret is still in the repository.


    We recommend that if a secret was put into code, it should be removed from the code as recommended above and replaced with a new one . In case this is not possible, we recommend you to remove the affected commit guía para Github.


    Third-party software dependencies

    In many occasions the third party dependencies that we include in our software have vulnerabilities or are directly malicious.


    For these reasons, it is very important that we pay attention to the security of the third-party components that we include, so when choosing a dependency, we must choose the most recent version and without reported vulnerabilities.


    Applied Cryptography

    Before applying any cryptographic technique, it is necessary to analyze the type of data to be protected and its status (at rest, in transit or in use) in order to ensure that the technique to be used will meet the required need. In general, if when analyzing the type of data that needs to be protected, it is identified that:

    • It must be reversible (return to its original state) what must be applied is an encryption technique.
    • It must not be reversible, the appropriate technique is hashing.
    • It requires guaranteeing non-repudiation, the appropriate technique is the digital signature.

    • Property Mechanism Entities Implementation
      Confidentiality + Authenticity Encryption Same application or project. AES-GCM-256
      Integrity + Authenticity MAC Same application / Multiple HMAC-SHA256
      Integrity + Authenticity + Non-repudiation Digital signature Multiple applications / External entities Ed25519

      Next: Validations and security requirements.