SQL Injection no Scriptcase

Prezados, eu gostaria de abrir uma discussão sobre como nos proteger desta prática.

Eu sempre pensei que o Scriptcase por padrão nos formulários vinha com essa proteção ativa. Hoje, eu ainda acredito que seja assim, porém, fiquei com uma pulga atrás da orelha ao olhar o código utilizado em notificações criado pela Netmake.

O código que estava olhando e que me chamou atenção era este de notificações:

sc_lookup(rs, "SELECT tags FROM notif_user_tags WHERE login = " . sc_sql_injection({login}) . " AND login_sender=". sc_sql_injection({notif_login_sender}) );

Para fazer o código do select, a Netmake utiliza a função sc_sql_injection. O que eu nunca usei em nenhum código, pois sempre acreditei que tinha uma validação ao inserir qualquer coisa no input.

Além disso, eles fazem isso com o update também:

sc_exec_sql("UPDATE notif_inbox SET notif_tags = " . sc_sql_injection($tags_in_msg) . " WHERE inbox_id = ". {inbox_id} );

Agora entra a questão, como vocês fazem para se proteger desse problema?

Você utiliza a macro sc_sql_injection em todos os seus select, insert e update que tem interação com um formulário?
  • Sim
  • Não

0 votantes

Usam essa função em todo select, insert e update de vocês?

Fiquei com uma pulga atrás da orelha, pois sempre pensei que o próprio input validava isso por debaixo dos panos.

Caso realmente é necessário utilizar isso em todos os select, insert e updates que tem interação com os campos de nossos formulários. Acredito que deveria estar na documentação de forma explicita sobre isso.

Obrigado pelas respostas.

@yuri_esteves @marcia.caaraujo

Não estou com tempo para olhar o código diretamente agora, mas puxando pela memória, eu tenho quase certeza que essa proteção existe para campos integrados, aqueles que são diretamente ligados a colunas da base de dados. No entanto, se você usa o valor de algum campo internamente em seus eventos, a proteção não é aplicada para que o evento tenha acesso ao valor real que foi digitado no campo.

Esse é exatamente um dos motivos para a existência da macro, em primeiro lugar. E é recomendado que se use a macro para variáveis que serão usadas nas interações com o banco dos eventos.

Espero ter ajudado.

2 Curtidas

Veja o manual da macro:

Todos os acessos a base de dados, gerados pelo Scriptcase, têm proteção contra “sql injection”. Nos comandos gerados pelo usuário (macros: sc_lookup, sc_select ou sc_exec_sql) caso seja necessário, deverá ser utilizada esta macro para proteção.

4 Curtidas

Obrigado pelo comentário.

Acredito que deveria ter um comentário na documentação dessas macros que interagem com o banco e inclusive um exemplo utilizando elas com a macro de SQL Injection.

Deveria ser mais divulgado a utilização desta macro. Ela é bem pouco falada, sendo esquecida. O Scriptcase tinha que utilizar ela mais vezes durante os exemplos em vídeos e exemplos de códigos.

2 Curtidas

Vou mostrar essa sugestão para a equipe do manual. Obrigado!

3 Curtidas

Pelo que está aqui na documentação eu acredito que seja, por exemplo, numa blank, aplicações controle, ou eventos que deva ser usado.

2 Curtidas

Bom, como a amostra foi pequena, não tem como falarmos de maneira exata. Porém, o gráfico já dá indícios que o Scriptcase tem que melhorar a comunicação sobre SQL Injection na documentação, em vídeos, em webinars e nos exemplos que já vem com o sistema.

@marcia.caaraujo @yuri_esteves

2 Curtidas