Convencer Administrador do Sistema que os Uploads de Arquivos podem estar OK?

4

Para manter isso o mais curto possível: Recentemente, o nosso administrador de sistemas chamou a atenção (como esse tipo de coisa deve ser) de que um dos requisitos do nosso mais recente projeto baseado na Web seria permitir que os clientes executassem o arquivo. uploads. Em particular, essas serão principalmente imagens e possivelmente vídeo [mas, como você sabe, não é possível garantir qual é o conteúdo exato do upload até que ele esteja no servidor].

O administrador do sistema ficou um pouco desanimado, e chegou perto de um flagrante "Não!".

Estou familiarizado com muitas das melhores práticas em relação à entrada de usuários, manuseio de uploads, etc, por isso estou muito confiante sobre o aspecto dos bastidores / código deste projeto. Minha pergunta é, existem recursos específicos ou pontos de conversação para facilitar a mente do meu administrador de sistema? O que devo focar em explicar a ele sobre esse tipo de coisa, como é tratado, etc.?

Algumas preocupações são espaço de armazenamento potencial (que eu sei que precisa ser calculado com base na estimativa de "popularidade" vezes o tamanho estimado do arquivo) e problemas de segurança com a hospedagem de conteúdo carregado.

    
por anonymous coward 02.06.2009 / 20:47

9 respostas

11

No final do dia, você e o administrador estão lá para dar suporte às necessidades da empresa. O desafio é encontrar o equilíbrio certo de abordagens funcionais (upload de arquivos) e não-funcionais (segurança, custo de disco, desempenho).

  • Lista de permissões permitida para tipos de arquivos, para que o site não se torne o arquivo pessoal de arquivos de MP3 de alguém.
  • Defina tamanhos de upload de arquivos razoáveis e crie designs de maneira que os administradores possam ajudar com soluções alternativas para tamanhos grandes, mas necessários.
  • Limite de taxa de implementação. Jane realmente precisa fazer upload de 5 arquivos simultaneamente ou 300 arquivos em um dia? Geralmente, eles devem ser definidos a uma taxa invisível para o usuário normal, mas bastante aparente para um invasor.
  • entenda a maneira como seu aplicativo consumirá recursos - memória e disco. Se você está indo para o pedaço, o que você vai fazer para limpar as sessões perdidas? Quanto custa a memória consumir um arquivo de 10 MB no servidor enquanto ele está sendo carregado?
  • Entenda o ciclo de vida dos dados. Quando não será mais necessário? o que desencadeia sua exclusão?
  • O que seu aplicativo fará quando o antivírus colocar em quarentena um arquivo enviado?
por 02.06.2009 / 20:47
3

Todos que recomendam a verificação de extensões de arquivo como uma forma de garantir sua segurança são insanos. É fácil renomear um exe ou um mp3 para um gif. Idem para o tipo MIME de upload.

A maneira somente para ter certeza do tipo de upload é analisá-lo; procure as assinaturas de arquivo dentro do arquivo, carregue-o em um processador de imagem e veja se ele engasga, etc. etc.

O que mais você precisa fazer depende do seu sistema operacional e do servidor web, mas geralmente os uploads não devem ir para um disco separado, então você não mata o seu sistema operacional quando alguém faz upload de muitos arquivos e ocupa todo o espaço . Onde quer que eles sejam carregados não devem conter permissões de execução, então ninguém pode rodar um arquivo através do navegador (caso seja um script em qualquer linguagem da web que você esteja usando), melhor ainda, não permitir referências diretas a ele. afinal, servir os arquivos através de uma página de utilitário com algo como um GUID como o parâmetro (por exemplo, displayImage? id = 0000-000000-0000-0000)

E, é claro, verificar vírus, limitar o tamanho máximo de upload (embora tenha cuidado, o IIS6, por exemplo, não pode verificar o tamanho do fluxo no meio, e assim armazenará o upload na memória até que ele seja concluído aplicação .net)

    
por 02.06.2009 / 20:47
2

Leia este site: http://www.owasp.org/index.php/OWASP_Top_Ten

Você notará que o "upload do Apache corrompido magicamente" não é uma vulnerabilidade de segurança bem conhecida.

Manipulação de uploads do Apache pode ser corrompida - e malograda - mas você realmente precisa trabalhar nisso ignorando a lista de vulnerabilidades do OWASP.

Além disso, o seu framework - que você não mencionou - tem diretrizes específicas para lidar com uploads de maneira segura. Se não houver nenhuma provisão para o upload, execute - não ande - para uma estrutura melhor.

"[mas, como eu tenho certeza que você sabe, não é possível garantir o conteúdo exato do upload até que ele esteja no servidor]".

Longe da verdade. E irrelevante, mesmo se for verdade para o seu quadro particular.

Os arquivos passam pelos buffers. As estruturas do Python tornam o upload disponível no cache (se for grande) ou na memória (se for pequeno). Ele não está "realmente" no sistema de arquivos, mesmo que esteja em um cache de arquivos. Não tem seu nome final ou permissões - são apenas bytes.

Bytes não magicamente corrompem o Apache. Arquivos exeutáveis com propriedade burra (e / ou um bit setuid em suas permissões) corrompem o Apache.

O truque com uploads é (a) alavancar o cache do seu framework, (b) validar os dados antes de salvá-los em qualquer lugar, (c) salvá-los em algum lugar não exe- cutível - o Apache não pode procurar executáveis, e (d) Nunca chmod ou chown qualquer coisa sob nenhuma circunstância. Um upload não executável pode causar problemas se for denominado .htaccess e você o escrever no diretório do qual o Apache obtém isso - uma ação que é facilmente evitada configurando as permissões nesse diretório e nunca nomeando um arquivo carregado .htaccess . / p>

Existem pouquíssimas vulnerabilidades. Eles estão bem documentados. E sua estrutura já lida com isso.

    
por 02.06.2009 / 20:47
1

Se esta é uma parte vital dos requisitos de negócios, não consigo ver como ele poderia recusar, contanto que os protocolos de segurança sejam seguidos (isto é, extensão / tipo de arquivo de filtro, tipo MIME, tamanho do arquivo, etc.)

Supondo que ele faz parte de uma escada corporativa (e não o único administrador de sistemas da empresa), tente ir até seu supervisor e explicar sua situação.

    
por 02.06.2009 / 20:47
0

Lembre-se de que você pode verificar o tipo de arquivos enviados (usando a detecção de tipo MIME; há várias maneiras de fazer isso no PHP ou usar um utilitário externo como file ) e pode verificar se há vírus , novamente, usando um utilitário externo.

Presumivelmente, depois de processar e verificar um arquivo enviado, você o moverá para o local final e rejeitará os arquivos que não passam nessas fases. Se for assim, você pode argumentar com o seu administrador que você só estará salvando arquivos "seguros".

Você pode começar perguntando a ele quais são seus principais pontos negativos sobre o assunto; Ele está preocupado com a segurança / proteção, com a responsabilidade de publicar conteúdo fornecido por outros usuários (e quaisquer implicações de segurança para o usuário final) ou está preocupado com problemas de infra-estrutura - armazenamento, rede, etc.

Nota: "Seguro" acima refere-se à segurança dentro das verificações realizadas. Obviamente, você não pode garantir a segurança absoluta de qualquer coisa que o usuário forneça.

    
por 02.06.2009 / 20:47
0

O upload de arquivos pode ser complicado de gerenciar, em termos de segurança e em geral.

Para ter um aplicativo seguro o suficiente, você precisará ...

  1. Limitar o tamanho do arquivo. Você não quer que as pessoas usem muita largura de banda ou usem seu sistema para armazenar todos os seus dados.
  2. Limitar tipos enviados (não permitir .exe ou bash scripts ...). Você pode fazer apenas verificando o arquivo extensão. Verificação real do tipo de arquivo também pode ser executada, mas na maioria casos, seria um exagero. Dependendo do idioma / sistema você está usando, existem várias maneiras para fazer isso.
  3. Tenha cuidado com alguns     formatos que apresentam segurança     furos.

Então, também depende da confiança depositada nos usuários finais. Se é uma intranet onde tudo é rastreado, você não precisa de muita segurança como um site público! Se os usuários forem conhecidos, você não precisará verificar tudo.

    
por 02.06.2009 / 20:47
0

Outra boa verificação de integridade - não faça o upload de arquivos para o disco, mas armazene-os em um banco de dados. Isso elimina o clássico "upload do arquivo maligno e, em seguida, executa o arquivo maligno no contexto do servidor" porque os arquivos não existem no servidor.

Agora, você sempre pode ser habilidoso em servir os arquivos para download se tiver problemas de desempenho em arquivos com backup de banco de dados.

    
por 02.06.2009 / 20:47
0

Ter sido esse administrador que disse "não". Para desenvolvedores pedindo para fazer upload de arquivos para o servidor, posso dizer-lhe as coisas que eu procuro em um aplicativo que parece fazer isso. A principal restrição é que, a menos que estejamos falando de um servidor web dedicado, nossos servidores web não eram dimensionados tendo em mente o armazenamento em massa de arquivos.

  • Qual é o ciclo de retenção de dados? Se esses dados estiverem no servidor da Web para sempre, tenho muito mais chances de forçar esse aplicativo em seu próprio servidor dedicado. Se esses dados estiverem apenas no servidor por alguns segundos enquanto o software os analisa e depois os exclui, é muito mais provável que isso aconteça. Fico encorajado quando há um processo de limpeza que limpa arquivos mortos / antigos. Isso mostra que eles se importam.
  • De quais arquivos de tamanho estamos falando? Se são arquivos weedy office-doc, isso é uma coisa. Mas bater arquivos enormes em formato GIS é outra coisa.
  • Qual é o público-alvo? Se usuários anônimos da internet podem fazer upload de arquivos, isso aumenta seriamente a paranóia que tenho sobre esses dados.
por 02.06.2009 / 21:56
0

Uma das startups em que trabalhei há alguns anos era um site de upload de vídeos e imagens no Linux (assim, todo o meu exemplo é disso). Há várias coisas que podem dar errado ao permitir uploads.

Todos os sistemas de upload devem transcodificar o formato original para o formato padrão. O benefício disso é duplo. Primeiro você agora tem um formato padrão que torna a exibição de imagens e vídeos muito mais fácil no seu html. O próximo caso você tenha certeza de que alterou o arquivo o suficiente para não hospedar arquivos infectados. Se você estiver planejando veicular arquivos enviados por upload de qualquer usuário com um endereço de e-mail, poderá ter muitos problemas.

Como outras pessoas mencionaram, você precisa de um pouco mais do que apenas verificar a extensão. Este é um problema um pouco mais difícil de resolver. Nós levamos um par de punhalidades que eu nunca estava feliz com, mas vale a pena fazer por um par de razões. O grande problema é que você provavelmente terá vários caminhos para transcodificação de vídeo. O vídeo vem em muitos contêineres diferentes, juntamente com alguns milhões de combinações de faixas de áudio e vídeo. Quanto mais você souber sobre o arquivo, melhor será a escolha de como processá-lo ou rejeitá-lo.

Supondo que você esteja transcodificando os arquivos, estará vulnerável a explorações em suas bibliotecas de processamento, como ffmpeg ou libgd. Nós gravamos o arquivo original em disco no compartilhamento NFS e depois geramos o processamento em um ambiente jail / chroot. Isso nos permitiu transcodificar para um novo formato ou falhar em um único diretório sem infectar o servidor ou qualquer outro arquivo. Também seu sistema de transcodificação precisa estar muito atualizado, então você precisa checar sua distribuição a cada noite para ter certeza de que as bibliotecas básicas como libpng, libtiff, libmad, libdv, etc não possuem nenhum bug de segurança atual.

Voltando à pergunta original, certifique-se de abordar os problemas apontados por todos, e você não deve ter problemas para obter o seu administrador de sistema e ter uma aplicação muito melhor no final também. Infelizmente o trabalho do seu administrador de sistema é dizer "Não" a coisas que parecem ser um pesadelo operacional para suportar.

    
por 14.06.2009 / 08:45

Tags