Você foi contratado para corrigir um pequeno bug em um site com muita segurança. Olhando para o código, ele está cheio de falhas de segurança. O que você faz? [fechadas]

Fui contratado por alguém para fazer um pequeno trabalho em um site. É um site para uma grande empresa. Ele contém dados muito sensíveis, portanto a segurança é muito importante. Ao analisar o código, notei que ele é preenchido com brechas de segurança - leia, muitos arquivos PHP lançam entradas de usuário / entrada do usuário diretamente em solicitações mysql e comandos do sistema.

O problema é que a pessoa que criou o site para ele é um programador com familiares e filhos que dependem desse trabalho. Não posso apenas dizer: "seu site é um parque de diversões para crianças. Deixe-me refazê-lo e você ficará bem".

o que você faria nesta situação?

Atualizar:

Segui alguns bons conselhos aqui e educadamente relatei ao desenvolvedor que encontrei algumas possíveis falhas de segurança no site. Apontei a linha e disse que poderia haver uma possível vulnerabilidade para ataques de injeção de SQL lá, e perguntei se ele sabia disso. Ele respondeu: "claro, mas acho que, para explorá-lo, o invasor deve ter informações sobre a estrutura do banco de dados; tenho que entender melhor" .

Atualização 2:

Eu disse que esse nem sempre é o caso e sugeri que ele seguisse esse link de pergunta do Stack Overflow para lidar com isso corretamente: Como evitar a injeção de SQL no PHP? Ele disse que estudaria e me agradeceu por ter contado antes. Acho que minha parte está pronta, obrigado pessoal.

Antes de mais, aqui, a prioridade é fechar as brechas de segurança.

Se você estiver trabalhando diretamente com o engenheiro que escreveu isso, documente tudo e entregue ao engenheiro.

Caso contrário, informe ao empregador que os problemas de segurança são maiores do que se pensava inicialmente e que o site precisa de muito trabalho. Peça para trabalhar com o desenvolvedor principal que está no site e ofereça-se para ensiná-lo sobre segurança do PHP (não prometa tornar a pessoa um especialista, mas ofereça-se para treiná-la em tudo que você sabe) para que a pessoa possa assumir o controle depois que você terminar.

Não faça disso uma questão de "esse cara é ruim, demiti-lo". Aproxime-o da perspectiva de "Ei, encontrei alguns bugs em potencial que precisam corrigir estatísticas, que parecem advir de algumas ignorâncias / equívocos comuns sobre segurança do site. Também gostaria de conversar com seu desenvolvimento para que possamos melhorar seu site. e esperamos evitar mais desses problemas no futuro ".

Há uma diferença entre ignorância e incompetência. Houve um tempo em que você também não sabia o que era a injeção de SQL, e não há razão para acreditar que o programador original não seja capaz de corrigir os problemas assim que tiver conhecimento deles.

Então diga a eles. Seja específico e objetivo, e fique à disposição para responder perguntas, fornecer exemplos de explorações e recomendações para correções. Se eles ainda não o obtiverem após esse ponto, o máximo que você pode realmente fazer é não colocar nenhuma informação pessoal no site.

Seu trabalho não é refazer o site para ele. É para corrigir o pequeno bug. No entanto, se você notou problemas de segurança que deveriam ser corrigidos, você pode falar com o proprietário do site e oferecer informações sobre qual pode ser o problema.

Não repreenda ou fale negativamente sobre o desenvolvedor original ou comente o quão horrível é o código. Seja respeitoso e profissional. Você pode se oferecer para trabalhar com o desenvolvedor para resolver os problemas. Não tente consertar você mesmo ou oferecer uma solução, a menos que tenha sido contratado para resolver o problema. Se eles seguirem o seu conselho e você estiver errado, eles poderão voltar para você.

Em primeiro lugar - conserte o que eles contrataram. Se você não fizer isso, será percebido como o tipo de consultor que está interessado em fazer mais trabalho para si, em vez de fazer o trabalho.

Juntamente com as correções, você precisa fornecer a eles uma lista das coisas que você notou que estão erradas do ponto de vista da segurança e por que essas coisas estão erradas.

Não é bom para ninguém não reportar os problemas. Se você teve uma tarefa específica que foi contratada para concluí-la, mas documente outros problemas de segurança ao vê-los e relate-os ao indivíduo apropriado, provavelmente o indivíduo ao qual você está relatando a tarefa para a qual foi contratado.

Essa é uma situação em que fortes habilidades pessoais serão úteis para lidar com isso com tato, exigindo não deixar de lado o trabalho realizado por outras pessoas no site e não fazer o desenvolvedor sentir como se estivesse questionando seu talento.

Obviamente, evite palavras como "porcaria, ruim, ruim, complicado" ao se referir ao código / falhas e palavras semelhantes para o desenvolvedor que escreveu o site.

Além das outras respostas, o que você pode querer fazer é apontar o desenvolvedor para alguns recursos sobre a facilidade com que os problemas de injeção SQL podem ser explorados, por exemplo, sqlmap, que é uma ferramenta automatizada de exploração de Injeção SQL.

O que eu achei eficaz em demonstrar a seriedade desse tipo de problema no passado é mostrar o que pode ser feito com ele, por isso, se você executar algo assim contra um desenvolvedor. cópia do site para mostrar extração de dados, etc, você pode convencê-los da seriedade.

Primeiro e único; A gerência não quer ouvir sobre problemas. Fui demitido do Escritório de Gerenciamento de Pessoas (autorizações de segurança para a casa branca) porque apontei o quão inseguro era o sistema deles. Isso foi há algum tempo, mas as atitudes de gerenciamento não mudaram.

Resolva o problema com o desenvolvedor, por e-mail, para que você tenha uma trilha, depois caminhe ou fuja. Quando eles acabam tendo um problema, como contratados, tentam culpá-lo, independentemente de terem algum envolvimento conectado remotamente ao problema.

Ter um problema tão fundamental quanto uma injeção de SQL indica que eles eram baratos quando desenvolveram o sistema inicialmente, e é provável que agora eles sejam mais baratos. Obtenha o que puder deles enquanto eles ainda estiverem no negócio, mas busque o desenvolvimento de negócios em outros lugares.