Software Público Brasileiro

No meu ramo denominado mysqli, criei uma solução com a classe DB. A implementação na parte acessível pelo cidadão está pronta, mas falta implementar em parte da interface administrativa. A commit Classe DB dá uma idéia do que precisa ser feito em cada arquivo restante.

Vou alterar toda interação com o banco utilizado prepared statements .

Já modifiquei a função getDados(); da classe solitacao;

o que acham?

como posso colaborar? segue arquivo anexo em .txt

Rafael, é claro que você pode colaborar, e a melhor forma costuma ser fazendo um fork do repositório. Tem um vídeo na wiki do e-SIC Livre que explica como proceder.

Quanto à alteração na função getDados(), ela atinge uma parcela muito pequena das queries realizadas pelo sistema. Por isso, preferi refazer tudo manualmente, usando essa classe que mencionei acima. Infelizmente, o e-SIC Livre não separa muito o acesso ao banco de dados do resto das funcionalidades. Dá muito trabalho...

Você, no entanto, é livre pra tentar implementar qualquer solução, seja uma própria, seja continuando a minha, que não tenho tido tempo para prosseguir.

Olá pessoal.

Talvez uma boa opção para evitar SQL Injection, seja usar a função preg_replace() nos campos de login e a função strip_tags para evitar tags HTML nos campos de formulários.

Por exemplo: No login $login = preg_replace('/[^ [:alnum:]_ ]/', '', $_POST['login']); Assim ele só vai enviar letras e números, evitando aspas, traços, etc.

E nos campos de formulários: $textosolicitação = strip_tags($_POST["textosolicitacao"]); Evitando as tags HTML, p, script, input, etc.

Espero ter ajudado.

Reinaldo eu tentei usar essa função dessa forma ai, e mesmo assim a variável ainda recebe os caracteres especiais. nos teste que fiz, deu certo dessa forma, mas não remove os espaços

$login = preg_replace("/[^{a-zA-Z0-9\s]/",} "", $_POST['name']);

e esse do campo solicitação deu certo...

Marcelo, na hora de adicionar o comentário acabou apagando alguns caracteres, o correto é:

$login = preg_replace("/[^ [:alnum:]_ ]/", "",$_POST['login']);

Obs: Não tem espaços em "/[^ [:alnum:]_ ]/"

Reinaldo. testei dessa forma ai e deu certo. o que você tinha dito do formulário de solicitação na versão 1.11 do esic ele já remove as tag html

Prezados,

Remover as tags HTML já é um passo importante, mas não é suficiente para evitar riscos à informação. É absolutamente necessário evitar a injeção de SQL, o que vem sendo feito nesse ramo que mencionei através do uso da interface mysqli, do PHP. O ideal seria também validar as entradas dos usuários. Procurem por injeção de SQL no Google, ou prevenção de injeção de SQL para mais informações. O risco é realmente muito grande, e deve ser enfrentado.

Como não estou mais na área da CGU que trata do e-SIC Livre, não tenho mais condições de seguir avançando nessa solução.

Embora seja voltada para Python/Django, essa página contém algumas informações - bem resumidas - que poderíamos aproveitar para melhorar a segurança do e-SIC Livre: http://www.djangobook.com/en/2.0/chapter20.html

de que forma seria feito o ataque injection no esic ? tava testando alguns ataques com algumas strings mas não percebi efeito e tava vendo alguns vídeos de exemplo, não vejo semelhança ao e-sic. em relação as vulnerabilidade mostradas nos vídeos.

ou eu seja iniciante no ramo tanto php quanto mysql.

Precisaria ver no histórico da lista de e-mails, mas uma prefeitura relatou ter sido vítima desse tipo de ataque. A questão é que os argumentos da requisição HTML não são tratados para alterar certos elementos (fechamento de string, por exemplo) antes de passarem a compor a query SQL.