...com base no código do post 'Um exemplo do que não se deve fazer . . .' do nosso colega Luís Sousa, utilizar o ataque SQL Injection?
As respostas devem ser acompanhadas de justificativas, se possível.
Obrigado ao Luís pelo exemplo!
Abraço e Feliz 2010!
Até ao próximo post!
Fernando Oliveira
Agap2 Developer
MCTS - .NET Framework 2.0
Web Applications
Subscrever:
Enviar feedback (Atom)
2 comentários:
Bora lá pessoal, mais opiniões!
Os trechos parecidos com:
"select @Centro='" + Centro + "' "
possibilitam injectar SQL, desde que se consiga, de alguma forma, manipular as variáveis: Centro, Estrutura, etc. O Joaquim já mostrou uma forma de manipular estes valores utilizando os debuggers de JavaScript dos próprios browsers.
Esta prática expõe o modelo de negócio e possibilita efectuar ataques directos ao servidor SQL.
À parte da injecção de SQL, que é possível neste exemplo, acho que o mais relevante é que a manipulação do código de cliente é sempre possível.
Por isto, toda e qualquer validação deve ser sempre feita por código de servidor, mesmo que já tenha sido "garantida" por código de cliente - não só validações unitárias e cruzadas, ao valor dos campos, mas também validações ao estado do processo descrito.
Como justificação para o "sucedido" podem adivinhar-se questões de inércia e política empresarial, tais como quem pode ou não criar stored procedures.
Mas, à parte disso, e aceitando a vulnerabilidade, ao menos o programador podia ter feito o escape dos caracteres especiais de SQL, quando concatena valores que sabe que serão strings de SQL. O mesmo se aplica com a construção dinâmica de XML ou HTML.
Tudo funciona até alguém se lembrar de acrescentar o cliente "Loja de Paço d'Arcos", acontecimento que é MUITO frequente. Deve-se sobretudo à inconsciência de muitos programadores, que fazem sempre tudo pela rama, e acabam por deixar trabalho para alguém mais tarde.
Enviar um comentário