[Resolvido] Desconfiar e Verificar

[RSS iMasters 5]

Quando trabalhando em um aplicativo web com colegas de trabalho ou com alguns voluntários, poucas coisas são mais importantes dentro do grupo do queconfiança. Confiança entre desenvolvedores permite que eles trabalhem confiantes,facilita a comunicação entre os membros do time, e fortalece cada um deles paraque possam tomar boas decisões.

 

Com o aplicativo em si, no entanto, essa confiança nunca deve virfacilmente, Com os aplicativos web de hoje, você não pode confiar em nada. Vocênão pode confiar nos inputs do usuário, você não pode confiar no seu código,você não pode confiar nos seus processos, e você não pode confiar nos seussistemas. Portanto, enquanto o provérbio russo diz, ????????, ?? ????????,? oque significa ?confie e verifique?, nos dias de hoje você precisa desconfiar everificar.

 

 

O usuário

Um usuário nãoprecisa de ser malicioso para violar o seu aplicativo, mas usuários maliciososexistem, então nenhum input de nenhum usuário pode ser confiável. Qualquer dadorecebido é imediatamente suspeito, precisa ser validado se está no formato correto(números são números, datas são datas, códigos postais são válidos, endereçosde e-mail devem corresponder à RFC 822, e os dados solicitados devemestar com o comprimento correto) e filtrados para remover inputs perigosos.Existem muitos artigos sobre como evitar a SQLinjection, mas prevenir ataquesdo tipo cross-site scripting e session hijacking também é importante.

 

Você deve desconfiar de dados entrando em seu aplicativo o suficientepara ler os artigos na biblioteca do PHP Security Consortium, seguir um post por dia duranteum mês no PHP secutiry, ou passar uma hora revisando os básicos do PHPSecurity.

 

Uma ótima fonte(e que deve ser lida) para iniciantes ? e que é cheia de ótimos lembretes paradesenvolvedores experientes ? é o Essential PHP Security, que sucintamente listaáreas problemáticas em que todos os desenvolvedores de PHP devem tomar cuidado,juntamente com soluções.

 

Felizmente paradesenvolvedores que preferem usar frameworks, a maioria dos frameworks sabemlidar com a checagem e com o filtro dos dados, prevenindo buracos bemcomuns na segurança. Se você usa um framework, abrace sua maneira de lidar com dados deforma que não mine seus processos. Desconfie dele o suficiente para verificarse ele faz o que você espera, e então se cadastre em sua mailing list desegurança. Quando uma correção é reportada, faça o download do trecho e reviseas mudanças; você cometeu o mesmo erro no seu código?

 

 

Ocódigo

O input deusuários é somente uma parte do aplicativo; como você confia no seu código, seele parece brilhante às duas da manhã, mas talvez menos brilhante na manhãseguinte? Você não confia. Você escreve unidades de testes.

 

Unidades detestes permitem que você automatize o trabalho tedioso de verificar se o seucódigo funciona corretamente e se está retornando os formatos de dadoscorretos. Eles permitem que você saiba quando as mudanças afetam o resto dosistema de maneira adversa.

 

SimpleTest e PHP Unit são dois frameworks PHPde testes bem populares. A criação de unidades de teste tem sido feita de umamaneira relativamente indolor, mas não sem erros e esforços.

 

Depoisque suas unidades de teste estão escritas, testando todas suas funções ebibliotecas, será que você realmente pode confiar neles? Na verdade, não.Unidades de teste são como o white box testing; você sabe o que o seu códigoestá fazendo (ou o que ele devia estar fazendo), você sabe qual input serátestado, e você sabe o que você espera em retorno. Com todo esse conhecimento,não, você não pode nem confiar nas suas unidades de teste, pois todos os passossão conhecidos, com a exceção dos inputs dos usuários.

 

Paraserem efetivas, as unidades de teste devem ser completas e devem seratualizadas para saberem lidar com novos casos que você vê durante odesenvolvimento e em produção. Cada vez que um bug é descoberto, um problema desvendado,ou uma proeza exposta, a unidade de teste deve ser criada para a questão.Brainstorm em casos complicados; você talvez não coloque caracteres de controlenos seus campos de formulários para inputs, mas as pessoas que cortam e colam,ou que talvez usem Emacs, podem colocar. Para aplicativos multilíngues, você játentou fazer testes em outras linguagens?

 

Umarevisão de suas unidades de teste de tempos em tempos também é uma boa idéia.Já olhou para uma parte completa do seu projeto e achou isso?

 

/**

* Test validName function

* @param string input name

* @return boolean

*/

function testValidName($name) {

// TODO: write validName test

return true;

}

</h4><h4>Odeployment

Então o input do usário édesconfiado, checado e filtrado. O código é desconfiado, revisado e testado.Você está pronto para lançar um novo atributo ou um programa completamentenovo. Agora é a hora de desconfiar dos seus processos de deployment, se elesnão estão documentados, repetitivos e (preferencialmente) não destrutivos.Deployments manuais provavelmente vão gerar erros (?eu estava no passo 3 ou4??), com processos não documentadossendo os piores deles (?O que você fez?? ?Eu não me lembro.?)

 

Documentar o lançamento deum processo força você a pensar quais passos devem ser seguidos, quaisrequisições devem ser feitas, e quais problemas você pode encontrar. Cada passotem pressupostos que devem ser questionados. As versões de desenvolvimento sãoas mesmas para a produção em OS, web server, PHP e database? Algum passo temrecursos limitados? O que acontece se um passo falhar? Você pode repetir umpasso sem se preocupar? O que poderia possivelmente dar errado aqui?

 

Existem passos quenecessitam de intervenção manual? Esses passos podem ser automatizados?Automatizar um processo de deployment faz dele repetitivo e, neste ponto,debugável. Phing, Capistrano (sim, você pode, use-o com PHP), shell scripts, seuspróprios scripts PHP, ou até Ant pode ser usado para construir umainfraestrutura de deployment de acordo com as necessidades do seu projeto.

 

Quais checagens de errossão necessárias nessa automação? Como você verifica que o deployment foi umsucesso? Para web sites com uma única página, responder a ?Ei, essa páginamostra alguma coisa?? é o suficiente. Para aplicativos maiores, você podeexecutar testes contra ao vivo; faça o login na conta, execute uma série detarefas comuns, e verifique o resultado.

 

 

Pontode vista

Umavez que seu aplicativo é lançado, você pode respirar com alívio, e entãodesconfie da sua visão do seu aplicativo. Você pode estar perto do seuservidor, em uma conexão rápida, usando um browser com Javascript. Os seususuários podem estar do outro lado do mundo, com uma conexão ruim, e semJavaScript.

 

Você pode desconfiar dasua visão fofa do seu aplicativo, e entender o que seus usuários estãorealmente vendo ao instalar o Charles ou qualquer outro proxy de debugging web.Ao aumentar a latência da rede e deixar sua conexão lenta, você pode ver seuaplicativo pelo ponto de vista de um usuário.

 

 

Oservidor

Seuaplicativo pode ser sólido como uma rocha, perfeitamente seguro, e tremendamenterápido, mas seu servidor pode se tornar o responsável pela travessura. É melhordesconfiar disso também. A maioria dos provedores de hospedagem de hoje ainda oferecemhospedagem compartilhada, com centenas de usuários em um único servidor. Aspermissões erradas ou uma OS desatualizada podem comprometer algo que nenhumdos seus códigos ou unidades de testes poderiam ter prevenido.

 

Portanto, ataque suaaplicação como um usuário malicioso iria atacar. Use skipfish para atacar seuaplicativo, e Nmap para escanear seu servidor.

 

Vejaquais portas você abriu, ou quais processos estão em execução. Descubra o quevocê pode desativar para remover ameaças potenciais. Ter portas de acesso adatabase abertas em um servidor sem limitações de IP, por exemplo, é umareceita para o desastre.

 

Faça o download dorainbow tables, e teste eles contra seu sistema. Tente instalar umrootkit ? tanto pela alegria de tentar penetrar em seu sistema, e porque,realmente, a essa altura, você desconfia de tudo em seu servidor.

 

 

Obackup

É claro que, no final dascontas, a coisa mais fundamental em seu aplicativo são seus dados. Perdê-lospode ser catastrófico para o projeto ou até para sua empresa. Nesse ponto, vocêdeve desconfiar dos seus backups.

 

A sua database está com backup, mas onde estão esses backups? Elesestão na database do servidor? O que acontece se o hardware falhar? Existebackup em outro servidor? O que acontece se o seu provedor de hosting fica forado ar? Você tem uma database master-slave no servidor preparada, de forma quevocê sempre tenha um backup preparado? Quando foi a última vez que vocêexecutou um SHOW SLAVE STATUS para determinar se oslave está realmente replicando a data do master? Você tem um processo deheartbeat em execução? Alguém está ouvindo às suas respostas? O monitoramentodo status da sua database só vai funcionar se alguém estiver prestando atenção.

 

Aprincipal questão, e o teste final de qualquer sistema de backup, é saber sevocê reparou, com sucesso, seu sistema a partir de seus backups. As históriasde horror sobre backups vazios são inúmeras, então repare a partir de um dessesbackups, e inicie um staging server ? mesmo que seja apenas em uma máquinavirtual. Repare a partir desse backup antes que você realmente precise dele.

 

Fundamentalmente, programar defensivamente, desconfiando das suassuposições, e verificando cada parte do seu aplicativo, desde a menor linha decódigo, até o último deployment, cria uma aplicação melhor e mais segura.

 

Existem muitas maneiras deum projeto falhar; é melhor eliminar aquelas que você consegue.

 

Desconfie e verifique.

 

*

 

Texto original de KittHodsden, traduzido do inglês, disponível emhttp://phpadvent.org/2010/mistrust-and-verify-by-kitt-hodsden.

 

 

 

 

 

http://imasters.com.br/artigo/20119/desenvolvimento/desconfiar-e-verificar