Protegendo sua API NodeJs contra ReDos Attack[Parte 2]

/^([a-zA-Z0-9])(([\-.]|[_]+)?([a-zA-Z0-9]+))*(@){1}[a-z0-9]+[.]{1}(([a-z]{2,3})|([a-z]{2,3}[.]{1}[a-z]{2,3}))$/"gm"

/^(([a-z])+.)+[A-Z]([a-z])+$/

{
    "email":"emailvalido@gmail.com",
    "password":"a.b.Cz"
}
```


Tudo flui normalmente. 
Porém se enviamos um payload malicioso, por exemplo:


```
{
    "email":"email-valido@gmail.com",
  "password":"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
}
```


Isso é o que ocorre:

![Server not responding](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/19y09duwg7iq99kjpv4h.PNG)
Consultando o endpoint **/test-server** verificamos que nossa API simplesmente não funciona mais 🙂.


![server offline](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/98f76jeoaol1zoesbnhq.PNG)

**Mas afinal, o que aconteceu ?**
Bem, vamos analisar o código atrás de respostas. A função que utiliza regex para validar, de forma errada, é essa:


```
function unsafeValidateForm(email, password) {
  const isEmailValid = validadeEmailRegex.exec(email) !== null;
  const isPasswordValid = validadePasswordRegex.exec(password) !== null;
  return isEmailValid && isPasswordValid;
}
```


O fato de essas expressões estarem sendo avaliadas na thread principal que é o problema. Pois dessa forma, devido ao comportamento de **catastrophic evaluation (Avaliação catastrófica)** ou **catastrophic backtracking( Retorno catastrófico)** o nodeJs fica stagnado alí sem conseguir avançar, com isso ele não consegue atingir as outras fases do EventLoop, não conseguindo processar as requisições que chegam, causando assim a interrupção dos serviços. Lembrando que explico mais detalhes sobre o que é o EventLoop, quais são suas fases e porque não podemos bloqueá-lo de forma alguma no meu outro artigo aqui da dev.to, [clique aqui para acessá-lo](https://dev.to/r9n/entendendo-e-solucionando-o-bloqueio-do-event-loop-no-nodejs-parte-1-3nec)

**Solução**
Bem, e o que podemos fazer para resolver isso ?
Vamos usar um recurso muito bacana para isso que são as node vm's
Caso você não saiba o que é isso, aqui vai uma explicação bem sucinta:

**vm** é um mecanismo através do qual o NodeJs consegue compilar e executar código javascript em um contexto totalmente separado do escopo atual de onde ele é chamado mantendo utilizando o motor da v8, que é sobre o qual ele própio é executado, ainda assim, a capacidade de acessar e modificar variáveis locais. Cada vm possui sua própria thread de execução, executando de forma independente da thread principal.

[Mais sobre vm's](https://nodejs.org/api/vm.html#vm-executing-javascript)

A seguir temos a versão repaginada da nossa função de validação de senha.


```
async function safeValidateForm(email, password) {
  try {
    validateData(email, password);

    const vmVariables = {
      regexResult: false,
    };

    const context = vm.createContext(vmVariables);

    const regexScript = new vm.Script(
      `regexResult = new RegExp(${validadePasswordRegex}, "gm").exec("${password}") !== null &&
     RegExp(${validadeEmailRegex},"gm").exec("${email}") !== null`
    );

    regexScript.runInContext(context, {
      timeout: maxRegexEvaluationTimeoutInMillissecons,
    });
    return vmVariables.regexResult !== null;
  } catch (error) {
    if (error.code == InternalErrorMessages.TIMEOUT) {
      throw new TimeoutError("ValidateForm");
    }
    throw error;
  }
}

```


Essa abordagem tem por princípio executar essa verificação em uma thread separa, por isso usamos aqui uma vm para tal, para assim não corrermos o risco de termos a nossa thread principal bloqueada, levando assim a um completo travamento da nossa API.

Vamos analisar a função nova e verificar o que ela faz. Logo no inicio temos o seguinte trecho de código:


```
  try {
    validateData(email, password);

    const vmVariables = {
      regexResult: false,
    };

   const context = vm.createContext(vmVariables);
```


Aqui nós estamos criando um novo contexto de execução para ser utilizado na vm que vamos utilizar. Caso quiséssemos passar algum valor do contexto atual para a vm seria nessa etapa que deveríamos inserir no contexto criado a informação que quiséssemos injetar.

**!!!ATENÇÃO!!!**

Inputs recebidos do usuário **NUNCA** devem ser passados diretamente para o sistema sem antes receber algum tratamento. A função **validateData** que fiz aqui está vazia pois ela é apenas para lhe lembrar que em produção você deve **sempre** tratar os inputs recebidos, ok ? 
Aqui não vou me ater a isso pois o foco é outro.

A seguir temos o seguinte código:



```
  const regexScript = new vm.Script(
    `regexResult = new RegExp(${validadePasswordRegex}, "gm").exec("${password}") !== null &&
     RegExp(${validadeEmailRegex},"gm").exec("${email}") !== null`
  );

```


Aqui passamos para a vm em forma de string o script que será executado. Repare que esse scrip é justamente a avaliação das expressões regulares que precisamos, justamente com os parâmetros de **email** e **password** que recebemos do usuário e precisamos avaliar.
Repare que no script temos o seguinte trecho "regexResult = new Re..." esse **regexResult** é o mesmo que declaramos no contexto e é ele quem vai receber o valor do resultado da nossa operação. Quando o processamento dessa micro vm terminar nós poderemos acessar esse resultado fazendo **vmVariables.regexResult**, legal né ? 🙂

Por fim temos o trecho de código:



```
 regexScript.runInContext(context, {
      timeout: maxRegexEvaluationTimeoutInMillissecons,
    });
    return vmVariables.regexResult !== null;
  } catch (error) {
    if (error.code == InternalErrorMessages.TIMEOUT) {
      throw new TimeoutError("ValidateForm");
    }
    throw error;
  }
```


Aqui nós executamos o script criado logo acima na micro vm utilizando o contexto criado e então podemos acessar o resultado da execução das regex's fazendo **vmVariables.regexResult**.
O importante aqui é notar a propriedade **timeout** que é justamente o que nos faz conseguir continuar processando coisas, mesmo que essa micro vm acabe travando pois ao se chegar ao tempo limite definido em **maxRegexEvaluationTimeoutInMillissecons**, que no nosso caso está configurado para 50, a vm é morta e um erro é lançado. Esse erro lançado e capturado no bloco de catch  e então fazemos o tratamento dele, lançando um erro personalizado de timeout.

E basicamente é assim que podemos tratar uma regex que não sabemos se irá travar ou não, ou até mesmo outra task que poderia comprometer nossa aplicação.

Agora que vimos como podemos resolver esse problema vamos testar nossa solução e ver se ela de fato funciona. 
Mas isso fica para a parte 3 pois por aqui já foram muitas informações. Abaixo você encontra o link para a terceira e ultima parte desse artigo. Te espero lá 🙂.

[TerceiraParte](https://dev.to/r9n/protegendo-sua-api-nodejs-contra-redos-attackparte-3-40g7)