FLUIG - SQL Injection.

Utilizar datasets em formulários são situações que podem ser necessárias, e inclusive é uma abordagem que é implementada em soluções da própria totvs, como é o caso do processo padrão de aprovação de compras do FLUIG X RM.

Esta abordagem permite que o formulário esteja sempre atualizado com informações em tempo real.

Aparentemente os patchs das versões 1.7.0 e 1.7.1 do dia 25 de maio de 2021 apresentam inconsistências em acessos aos datasets realizados pelo frontend ( HTML ou javascript do formulário ).

Isso significa que se em seu processo o acesso ao webservice da plataforma é realizado diretamente pelo formulário, então o sistema poderá gerar um erro ao executar o acesso aos dados do dataset, resultando nas mensagens: “Error getting Dataset (nome do dataset): Invalid Value to parameter: _finalValue. Possible SQL Injection.”

De certa forma este erro nos dá um alerta, sobre a importância de um risco real, e pode até ser algum recurso de segurança implementado pela plataforma, entretanto ainda não consegui localizar nenhuma documentação que diz a respeito dessa situação, nem como contorna-la.

Como resolver

Aparentemente o erro só acontece quando há uma tentativa de acessar o dataset utilizando as propriedades do constraint.

Sabemos que o desenvolvimento de datasets customizados dependa de nós, Para desenvolvermos os recursos de constraint, fields e order by.

Muitas vezes é prático utilizar o constraint como forma de filtros, porém em outros são utilizadas abordagens mais diretas, como o envio de uma consulta SQL diretamente pelo dataset.

Uma alternativa para resolvermos problema é reajustar o dataset, enviando as informações pela opção dos valores em campos fields, em vez de constraint.

Isso porque o valor de fields teria o objetivo de retornar apenas os campos necessários para aquela consulta, mas dificilmente este recurso será implantado em datasets customizados, já que construimos datasets para retornar apenas aquilo que é necessário.

Outra abordagem que pode ser tentada é enviar as informações de consulta criptografada, por exemplo em base64.

Desta forma não haveria caracteres especiais enviados, como as aspas ou instruções select ( AND, OR) , o que possivelmente permitiria avançar na rotina, já que o sistema lê e permite avançar em testes que não há caracteres especiais nas informações que são enviadas em filtros pelas constraints.

Conclusão

Mesmo que haja uma solução alternativa, pode ser inviável aplicar as correções em todos os processos, já que várias empresas possuem diversos processos e integrações e deixaria o ambiente com inconsistências até que todas fossem resolvidas.

É interessante estudar cada caso e se necessário voltar uma versão do ambiente, mas sempre buscar uma resposta da empresa responsável pela plataforma.

Caso você descubra outra forma, deixe nos comentários.