segurança de arquivos

[criatividade zero 17]

é possivel injetar algum codigo ou upar algum arquivo para acesso que contenha codigos que removam pastas e arquivos?

lembro que o IPB tinha uma vulnerabilidade no formulario que era possivel criar um arquivo de acesso remoto total

 

editando as permissões é possivel evitar?

trabalhando com htaccess, jogando os arquivos upados fora da pasta public, torna inacessivel o arquivo?

[Andrey Knupp Vital 136]

Que ??? não precisa complicar amigão, você faz a verificação antes de mover o arquivo ou foto .. verificando as extensões, não tem como ( INJETAR ) arquivo no servidor, não até onde eu saiba.

[Leozitho 81]

Que o IPB tem vulnerabilidades de segurança isso é fato, este fórum mesmo volte e meia está com scripts maliciosos no código-fonte.

 

Acho até que já está na hora do iMasters trocar pelo vBulletin, que além de mais seguro é melhor em desempenho. ;)

[criatividade zero 17]

Que ??? não precisa complicar amigão, você faz a verificação antes de mover o arquivo ou foto .. verificando as extensões, não tem como ( INJETAR ) arquivo no servidor, não até onde eu saiba.

o ipb tinha uma falha no formulario - nao sei se criava ou baixava uma pagina, mas era possivel fazer miseria

[Fvox 0]

Se existe vulnerabilidade ou não, isso depende do seu código.

A falha existe, de fato. Mas quem cria ela é o programador.

 

O nome da vulnerabilidade que o IPB possuia é conhecida como Remote Code Execution.

 

[]'s

[Andrey Knupp Vital 136]

Acho até que já está na hora do iMasters trocar pelo vBulletin, que além de mais seguro é melhor em desempenho. ;)

Não é tão simples assim, pelo menos ao meu ver.

 

Mas quem cria ela é o programador.

Não, de certa forma, a pessoa pode 'desconhecer' certo tipo de falha, ou conhecer e não fazer nada, o programador não cria uma falha no código, se criássemos uma falha no código, ele não compilaria, isso é óbvio, mas claro, depende do que você vai fazer, como no PHP, nem todos os tipos de erros são motivos para pararem a execução do script.

 

Raramente, os problemas encontrados são da própria linguagem.

[Leozitho 81]

Não é tão simples assim, pelo menos ao meu ver.

 

Simples não é, mas iria trazer vários benefícios para a comunidade, como maior segurança e estabilidade, já que em determinados horários do dia você nem consegue acessar o fórum do iMasters por causa da lentidão.

 

Vários fóruns famosos já migraram do IPB para o vBulletin, um desses fóruns é o fórum do Clube do Hardware, a maior referência sobre hardware do Brasil.

 

E todos os fóruns de empresas de hospedagem que eu conheço usam o vBulletin por causa da sua boa performance e segurança, como a Locaweb e a Softlayer.

 

Apesar desse não ser o assunto principal do tópico, fica aí a dica. Prefiram usar vBulletin do que IPB. :)

[Andrey Knupp Vital 136]

Prefiro usar o vBulletin nessas versões mais recentes, 4.0 + , a interface gráfica é bem melhor, mas eu curto o IPB também, e pra te falar verdade, o fórum tem sim alguns problemas, as vezes não consigo acessar, coisa de umas 3 ~ 4 vezes por mês, mas lentidão, lentidão mesmo, nunca tive.

[criatividade zero 17]

desculpe interromper... mas e a minha duvida?

:D

[Fvox 0]

Não, de certa forma, a pessoa pode 'desconhecer' certo tipo de falha, ou conhecer e não fazer nada, o programador não cria uma falha no código, se criássemos uma falha no código, ele não compilaria, isso é óbvio, mas claro, depende do que você vai fazer, como no PHP, nem todos os tipos de erros são motivos para pararem a execução do script.

 

Raramente, os problemas encontrados são da própria linguagem.

 

Se a falha fosse da linguagem, não haveriam sites protegidos quando aparecesse um 0day até o lançamento do patch, não é mesmo? =p

 

Sim, quem cria as falhas é o programador. Com intenção ou não, é ele.

 

[]'s

[criatividade zero 17]

Sim, quem cria as falhas é o programador. Com intenção ou não, é ele.

nao é nao

um formulário precisa ser tratado contra injection

não foi o programador que criou o injection, apenas não conhece tal vulnerabilidade e/ou nao soube trata-la

a linguagem contém suas 'peculiaridades' que são 'funcionais', até alguem descubrir que tal metodo é vulnerável

[Fvox 0]

nao é nao

um formulário precisa ser tratado contra injection

não foi o programador que criou o injection, apenas não conhece tal vulnerabilidade e/ou nao soube trata-la

a linguagem contém suas 'peculiaridades' que são 'funcionais', até alguem descubrir que tal metodo é vulnerável

 

Vamos pela lógica. Se um programador escreveu um formulário, e este formulário possui devida vulnerabilidade, quem criou a falha? Obviamente, o mesmo que criou o formulário.

Como eu já disse anteriormente, com intenção ou não, é ele. Não há outro culpado na história, desde que não seja um bug na linguagem, framework ou service utilizado pelo sistema.

 

[]'s

[criatividade zero 17]

nao vou entrar no merito da questão de qum é a culpa

aguardo informações sobre a minha duvida

[João Batista Neto 448]

Simples não é, mas iria trazer vários benefícios para a comunidade, como maior segurança e estabilidade, já que em determinados horários do dia você nem consegue acessar o fórum do iMasters por causa da lentidão.

 

Leozitho,

 

Estamos fazendo uma mudança muito grande no sistema do fórum, maior que todas as que já foram feitas até hoje.

 

Essa mudança será feita em duas fases e na segunda o ganho de desempenho e estabilidade são os focos. :seta: Vamos aguardar um pouquinho, tenho certeza que muita coisa vai melhorar.

 

Contudo, independentemente de migrar de plataforma ou tentar melhorar a atual, sempre que identificar algum problema que esteja atrapalhando na navegação do fórum, abertura de tópicos, postagem de respostas, pesquisas, enfim, qualquer coisa que alguém identificar como "problema", é só nos avisar, seja por email, MP e até gtalk/msn.

 

Muitos problemas estão relacionados com o servidor e são temporários, mas muitos outros são problemas possíveis de se resolver em poucos instantes, basta alguém avisar.

 

nao é nao

não foi o programador que criou o injection, apenas não conhece tal vulnerabilidade e/ou nao soube trata-la

 

Se um programador escreveu um formulário, e este formulário possui devida vulnerabilidade, quem criou a falha?

 

Ok, aproveitei dois quotes aqui para pegar duas afirmações:

 

1. O desenvolvedor não conhece tal vulnerabilidade.

2. O desenvolvedor escreveu o formulário e é o "criador" da falha.

 

Vejam,

 

Nosso trabalho não é escrever código, é escrever soluções.

 

Em muitas áreas, um profissional sai da faculdade e exerce sua profissão durante toda uma vida, sem preocupações. A área de tecnologia, assim como a área médica, evolui muito rapidamente e os profissionais dessas áreas precisam estar se atualizando sempre. Certamente, vulnerabilidades serão descobertas constantemente, muitas vezes após uma aplicação ser entregue. O desenvolvedor de software precisa estar atento à essas descobertas para que possa corrigir eventuais falhas em aplicações existentes e não cometer erros banais em aplicações futuras.

 

O profissional de tecnologia precisa desenvolver uma rotina de estudos diária, não basta escrever um monte de código e achar que é desenvolvedor. É preciso desenvolver soluções que atendam aos requisitos do cliente e para isso é fundamental que o profissional esteja atualizado.

 

Mas é importante notar também que, se ao desenvolver uma aplicação, os quesitos de segurança forem levados em consideração, e depois da aplicação pronta uma nova vulnerabilidade for descoberta, então é errado dizer que o desenvolvedor "criou" a falha em sua aplicação.

 

Então aqui vão duas dicas:

 

1. O desenvolvedor não conhece tal vulnerabilidade.

Se o desenvolvedor não conhece tal vulnerabilidade, então é fundamental que comece a estudar. Muitas vulnerabilidades existentes hoje são publicadas em grandes sites, pesquise, estude e desenvolva algo sabendo que vulnerabilidade X existe.

 

:seta: Mantenha uma rotina de estudos e procure estar sempre atualizado.

 

2. O desenvolvedor escreveu o formulário e é o "criador" da falha.

Algumas falhas são sim responsabilidade do desenvolvedor da aplicação, seja por displicência ou desconhecimento, ele é responsável por muitas falhas conhecidas.

 

Algumas outras falhas são responsabilidade do administrador do servidor onde a aplicação estará hospedada. Imaginem que o administrador do servidor, por qualquer motivo, tenha configurado o diretório temporário dentro do ambiente de execução do servidor (já vi isso acontecer), ou então que ele utilize uma versão do servidor que está totalmente desatualizada ou que um recurso X tenha uma falha conhecida (ex: PHP 5.3.7). Nesses casos, a vulnerabilidade não é "culpa" do desenvolvedor da aplicação e sim do administrador do servidor.

 

:seta: Conheça o servidor que hospedará a aplicação, veja as configurações e procure saber a frequência que o servidor executa as atualizações.

 

;)

[criatividade zero 17]

ao desenvolver uma aplicação, os quesitos de segurança forem levados em consideração, e depois da aplicação pronta uma nova vulnerabilidade for descoberta, então é errado dizer que o desenvolvedor "criou" a falha em sua aplicação.

acabou com o bafafa :)

 

mas sobre a duvida...

 

editando as permissões é possivel evitar que entre algum arquivo fora da pasta 'upload' e ele edite, altere e remova pastar e paginas fora da pasta onde está?

 

trabalhando com htaccess, jogando os arquivos upados fora da pasta public, torna inacessivel o arquivo?

[João Batista Neto 448]

editando as permissões é possivel evitar que entre algum arquivo fora da pasta 'upload' e ele edite, altere e remova pastar e paginas fora da pasta onde está?

 

trabalhando com htaccess, jogando os arquivos upados fora da pasta public, torna inacessivel o arquivo?

 

O trabalho de gerenciamento de permissões é feito no servidor. Com htaccess você consegue impedir que um determinado caminho seja acessível sem que um controlador manipule a requisição, porém o diretório temporário do sistema deve estar em um caminho inacessível independentemente do que você faça na sua aplicação.

 

Dentro do diretório temporário, você não deve ter permissões de escrita nem execução, você deve ter apenas leitura para que seja possível copiá-lo para um diretório conhecido pela aplicação quando o upload for feito. :seta: É nesse momento que pode existir a falha por parte do desenvolvedor. Se ele não fizer verificações no arquivo, ele poderá estar levando uma "bomba" para dentro de casa.

[Andrey Knupp Vital 136]

Sim, quem cria as falhas é o programador. Com intenção ou não, é ele.

Não não é, o programador que 'desconhece' a falha, ele escrevendo ou não o formulário ele desconhece a falha, ou seja, não sabe que o formulário dele é vulnerável a certos tipos de injection, ou outras coisas maliciosas. o programador que 'conhece' a falha, provavelmente, vai tentar corrigir, tudo que estiver ao seu alcance, o programador que conhece a falha, mas não tem como arrumar, já não é problema dele, entretanto ele tem poucas alternativas para

essa questão.

 

 

Vamos pela lógica. Se um programador escreveu um formulário, e este formulário possui devida vulnerabilidade, quem criou a falha? Obviamente, o mesmo que criou o formulário.

 

Certo, o programador escrever o formulário, e o formulário tem vulnerabilidade, mas esse programador é novato, não conhece essa falha, obviamente, ele quem criou a falha ? ¬¬

Lógico que não, ele apenas criou algo que ele era 100% confiante, mas desconhecendo certa falha, então ele não criou, alguém descobriu e não falou pra ele, vamos dizer assim.

[Leozitho 81]

Que bom que estão previstas melhorias para o fórum João. :joia:

 

O principal problema de lentidão que eu noto no fórum não é tanto na navegação mas principalmente na hora de postar.

 

Aqui no escritório eu tenho conexão de 10Mbps da GVT, então dá pra notar bem quando o site está lento e não confundir com lentidão na conexão.

[criatividade zero 17]

O trabalho de gerenciamento de permissões é feito no servidor.

 

Com htaccess você consegue impedir que um determinado caminho seja acessível sem que um controlador manipule a requisição

 

 

ficou claro isso, mas analisando a vulnerabilidade do IPB - pois é um caso concreto e não teórico - nao sei se a falha do IPB criava um arquivo ou dava acesso, mas era diretamente pelo formulário

 

form's podem injetar codigos que criam arquivos no server ou substituem?

caso positivo, o arquivo seria criado 'manualmente' em alguma pasta, levando em conta as permissões apenas na pasta upload e o trabalho do HTACCESS, não seria possivel acessa-lo, certo?

[João Batista Neto 448]

ficou claro isso, mas analisando a vulnerabilidade do IPB - pois é um caso concreto e não teórico - nao sei se a falha do IPB criava um arquivo ou dava acesso, mas era diretamente pelo formulário

 

form's podem injetar codigos que criam arquivos no server ou substituem?

caso positivo, o arquivo seria criado 'manualmente' em alguma pasta, levando em conta as permissões apenas na pasta upload e o trabalho do HTACCESS, não seria possivel acessa-lo, certo?

 

A falha que havia no IPB é exatamente o que estamos comentando:

 

1. Alguém faz um upload de um arquivo malicioso.

2. O sistema não trata esse arquivo de forma adequada e apenas move para um diretório conhecido.

 

Além disso, havia um agravante no IPB que permitia que esse arquivo fosse executado deliberadamente por quem lançou o ataque.

 

caso positivo, o arquivo seria criado 'manualmente' em alguma pasta, levando em conta as permissões apenas na pasta upload e o trabalho do HTACCESS, não seria possivel acessa-lo, certo?

 

Tanto faz você utilizar .htaccess para proibir o acesso direto à um arquivo, se sua aplicação usar o arquivo sem que você tenha tratado. Em algum momento você vai utilizar esse arquivo (afinal, se existe upload é porque sua aplicação usa arquivos) e é nesse momento que está o perigo.

 

Veja, você já compreendeu que dados de $_GET, $_POST e qualquer informação fornecida pelo usuário deve ser tratada, correto ?

 

É o mesmo com arquivos:

 

1. Alguém faz um upload de um arquivo.

2. Sua aplicação verifica o conteúdo do arquivo (o conteúdo mesmo, não o mime/type enviado pelo browser)

 

Se o arquivo que chegou for o esperado faça alguma coisa, do contrário, delete e notifique o usuário.