Às vezes, você fica ocupado e delega pequenas tarefas aos programadores juniores. Mas se você não prestar muita atenção, você se encontrará com esse tipo de código em produção:
class DivtoggleController extends Zend_Controller_Action {
public function closeAction() {
/* ... code removed for brevity ... */
$req = $this->getRequest();
$formData = $req->getPost();
$d = $formData['div'];
$i = $formData['id'];
$dm = new Model_DivtoggleManager();
$rs = $dm->setDivToggleById($d, $i);
}
}
class Model_DivtoggleManager extends Zend_Db_Table {
public function setDivToggleById($div, $id) {
$result = $this->getAdapter()->query(
"update div_toggle set " . $div . "=1 where id=" . $id
);
}
}Portanto, como removi a lógica de autenticação / gerenciamento de sessões por questões de brevidade, quem pode me dizer qual é o possível problema que pode haver com esse exemplo?
Respostas:
Você pode ensiná-los. Todo mundo faz isso no começo, até você. Se esse tipo de código entra em produção, é culpa do pessoal sênior; não o júnior.
Editar:
Uma das coisas que eu fiz foi pessoalmente pedir às pessoas que ativamente revisassem meu código (incluindo os juniores) antes do lançamento. O código é revisado, os jovens vêem isso como uma experiência de aprendizado, as pessoas perdem o medo da revisão do código como um castigo e começam a fazer a mesma coisa.
fonte
Hackeie o código na frente dos olhos e mostre como corrigi-lo. Repetidas vezes até que eles entendam.
fonte
Você pode mandá-los para uma aula assim que ingressarem na sua empresa, antes que eles tenham acesso ao controle de origem, que os introduza a injeções de SQL, scripts entre sites, falsificação de solicitação entre sites e outras vulnerabilidades comuns. Cobrir exemplos cara a cara, quebrar códigos incorretos na frente deles, fazer com que eles quebrem códigos incorretos e aponte-os para o site da OWASP para obter mais informações quando eles se formarem.
Além disso, você pode determinar o uso de uma biblioteca personalizada que lida com isso para você, mas essa é apenas uma solução secundária, pois eles certamente executarão consultas personalizadas quando isso se tornar mais conveniente.
Se você tiver os recursos, garantir que membros mais altos da equipe verifiquem suas diferenças antes de confirmar também pode ser útil.
Conhecimento é poder!
fonte
Supondo que seja a insegurança a que outras pessoas se referiram, como desenvolvedor de qualquer nível, é fácil esquecer que o getPost () não está protegendo os dados primeiro.
Uma maneira de contornar isso é:
Qualquer desenvolvedor que recupere algo de um array chamado 'insecure_data' e não se preocupe em protegê-lo é ignorante ou preguiçoso. Se for o primeiro, forneça treinamento, após o qual deve ser o último - e então você terá uma questão disciplinar, não de programação.
fonte
Um dos melhores guias que li sobre segurança na web é este guia de segurança do Ruby on Rails . Embora seja Ruby on Rails, muitos dos conceitos se aplicam a qualquer desenvolvimento web. Eu encorajaria qualquer pessoa nova a ler esse guia.
fonte
O código que você vinculou acima é suscetível a um ataque de injeção SQL, porque as entradas HTTP que você está usando na consulta não foram limpas
mysql_real_escape_stringou por qualquer outro meio.fonte
Em termos da sua pergunta (presumivelmente anuladora) "como faço para que os programadores parem de fazer isso", eu diria que os orientava regularmente, explicando cuidadosamente o problema em questão (e as possíveis consequências etc.) e enfatizando a importância das vulnerabilidades de código (tanto em termos de injeção de SQL quanto de scripts entre sites etc.) é provavelmente a solução mais sensata.
Se eles continuarem bagunçados, apesar de tudo o que foi mencionado acima (talvez você queira observar seus commits etc.) em vez de descobrir "ao vivo"), o problema é que você está falhando com eles como mentor ou que eles talvez precisem encontrar algo mais adequado para viver.
fonte