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]


109

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.


29
Eu realmente gostaria de uma solução que não envolva arruinar a vida de alguém. Eu deixaria isso em paz, mas também sei que uma falha de segurança também poderia arruinar a vida de algumas pessoas. Complicado.
precisa saber é o seguinte

18
O invasor pode usar a exploração para obter as informações sobre a estrutura do banco de dados. Sem vulnerabilidade de injeção SQL deve nunca ser subestimado.
Dave Rager

17
Mostre a ele como explorar algumas vulnerabilidades sem usar nenhum conhecimento do banco de dados. Isso vai assustá-lo.
Euphoric

74
Eu só quero dizer um bom trabalho por cuidar de outra pessoa / programador que você não conhece. Não é uma coisa menos terrível arruinar seus meios de subsistência, porque eles cometeram um erro e você não os conhece, e eu recomendo que você leve isso em consideração.
Steel

8
@Dokkat A questão é de equilíbrio. Do ponto de vista de um programador, o programador de baixa qualidade com esposa e filho realmente colocou em risco a empresa e, portanto, o trabalho de muitos funcionários com esposas e filhos. Além disso, a questão é muitas vezes complicada pela questão emocional de "O mau programador faz algo que dificulta minha vida. Agora tenho que perder tempo com minha família. Eles são mais importantes para mim do que ele. Isso parece injusto." " Essa é uma resposta irracional, mas as pessoas são pessoas.
deworde

Respostas:


114

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 ".


1
Ótimas respostas em geral. O tópico é subjetivo, por isso vou marcar o seu como foi o mais aceito pela comunidade.
MaiaVictor

1
Se você estiver trabalhando COM o engenheiro, mas sendo pago pela gerência, não deve reportar à gerência? E se o engenheiro agradecer, mas no momento em que você sair, destruir o relatório?
Konerak

Diga a ambos ou informe o engenheiro primeiro e verifique se os bugs estão sendo criados e rastreados em qualquer sistema que eles usem. Se não forem criados erros, informe à gerência.
Eric Hydrick

2
Gostei mais desta resposta: programmers.stackexchange.com/a/189206/28351 , porque para o empregador as prioridades são diferentes. Primeiro relate as falhas de segurança e, em seguida, corrija o pequeno bug.
precisa saber é

80

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.


26
+1. A ignorância pode ser corrigida. Incompetência é uma carreira para alguns!
Mitch Wheat

20

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ê.


17

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.


13

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.


4
Eu acrescentaria: verifique se o desenvolvedor está ciente da gravidade das falhas e como elas podem ser exploradas. Dedicar um tempo para iniciar um 'ataque' controlado em uma máquina local com esse desenvolvedor presente pode fazer muito para educá-lo sobre o problema, o que deixa aberturas para você sugerir maneiras de proteger o código.
Andrew Gray

7

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.


4
Esteja ciente de que isso tem alguns riscos, pois você pode parecer um "hacker". Gestão de pessoas não necessariamente entender termos como "vulnerabilidade existente", "copy desenvolvimento" e "analista de segurança chapéu branco"
deworde

0

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.


3
"Gestão não querem ouvir falar de problemas" - adicionar algum raciocínio / referências para apoiar a sua afirmação (que soa plausível para mim, mas isso realmente não importa) e eu retirarei downvote
mosquito
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.