Hospedagem Compartilhada. É a opção mais barata, não é? E para uma grande parte da população, é tudo o que eles precisam para hospedar seu site ou aplicativo da web. E quando bem feita, a hospedagem compartilhada é escalável, rápida e segura.
Mas o que acontece quando não é bem feito?
Bem, é aí que questões perigosas de segurança começam a aparecer. É quando seu site corre o risco de ser adulterado ou os dados particulares que você tem vazando. Mas não se preocupe. A grande maioria dos hosts da web tem medidas de segurança decentes. São apenas os anfitriões barulhentos que precisam ser cautelosos.
Vamos explorar os problemas de segurança relacionados à hospedagem compartilhada. Mas primeiro, vamos falar sobre o que torna uma plataforma de hospedagem compartilhada segura.
O que torna um host seguro
Há algumas considerações de segurança de destaque que devem ser feitas com relação à hospedagem compartilhada.
- Cada usuário no servidor deve ser isolado de outros usuários e não deve poder acessar ou modificar os arquivos de outros usuários.
- Uma vulnerabilidade de segurança na lógica de um site hospedado no servidor não deve afetar outros usuários.
- O servidor é regularmente atualizado, atualizado e monitorado para tratar de questões de segurança arquitetônica.
- Cada usuário deve ter seu próprio acesso ao banco de dados isolado e não deve ter permissão para fazer alterações nos registros armazenados ou nas permissões de tabela de outros usuários.
Novamente, a maioria dos hosts da web atende a esses requisitos para suas ofertas compartilhadas. Mas se você está procurando hospedar vários sites em um servidor, ou está curioso para ver como sua empresa hospeda, ou até mesmo pensando em lançar sua própria empresa de hospedagem e está ansioso para descobrir como proteger seus usuários, por favor leia em.
Mas primeiro, uma isenção de responsabilidade
Antes de entrarmos na discussão de ataques comuns nivelados em hospedagem compartilhada, eu só quero afirmar que este post não será (e não deve ser lido como) uma lista exaustiva de possíveis problemas de segurança.
A segurança é, em uma palavra, grande. Há muitas maneiras de comprometer um site. Isso vale em dobro para hospedagem compartilhada. Cobrindo-os em um único artigo, nunca estava nos cartões.
Se você é paranoico com sua segurança, adquira um VPS ou um servidor dedicado. Estes são ambientes em que você tem (na maior parte) controle absoluto sobre o que acontece. Se você não tem certeza sobre os diferentes tipos de hospedagem na web, confira este post As várias formas de hospedagem do site explicado [Tecnologia explicou] As várias formas de hospedagem do site explicado [Tecnologia Explained] Leia mais do meu colega, James Bruce.
Também devo salientar que este post não deve ser interpretado como um ataque à hospedagem compartilhada. Pelo contrário, é uma visão puramente acadêmica sobre as questões de segurança que envolvem essa categoria de hospedagem na web.
Transversal de diretório
Vamos começar com ataques de passagem de diretório (geralmente conhecidos como "caminho atravessado"). Esse tipo de ataque permite acessar arquivos e diretórios armazenados fora da raiz da web.
Em inglês simples? Bem, vamos imaginar que Alice e Bob usem o mesmo servidor para hospedar seus sites. Os arquivos de Alice são armazenados em / var / www / alice, enquanto os documentos de Bob podem ser encontrados em / var / www / bob. Além disso, vamos fingir que há outra pasta no servidor (/ usr / crappyhosting / myfolder) que contém um arquivo de texto puro não criptografado (chamaremos de pwd.txt) contendo nomes de usuários e senhas do sistema.
Comigo até agora? Boa. Agora, vamos imaginar o site de Bob que serve arquivos PDF gerados localmente, e o arquivo local é referenciado na URL. Algo como:
http://example.com/file?=report.pdf
O que aconteceria se eu substituísse o 'report.pdf' pelos parâmetros UNIX que alteram o diretório?
http://example.com/file?=../alice/
Se o servidor estiver configurado incorretamente, isso permitirá que você veja a raiz do documento de Alice. Interessante, mas estamos muito mais interessados nesse arquivo de passaporte suculento. Senhas Accio !
http://example.com/file?=../../../usr/crappyhosting/myfolder/pwd.txt
É realmente tão fácil quanto isso. Mas como lidamos com isso? Isso é fácil.
Já ouviu falar de um utilitário Linux pouco conhecido chamado chroot ? Você provavelmente já adivinhou o que faz. Ele define a raiz do Linux / UNIX para uma pasta arbitrária, impossibilitando que os usuários a saiam. Efetivamente, ele pára ataques de travessia de diretórios em suas trilhas.
É difícil dizer se o seu anfitrião tem isso sem infringir a lei. Afinal, para testá-lo, você estaria acessando sistemas e arquivos para os quais não tem permissão de acesso. Com isso em mente, talvez seja sensato falar com seu host e perguntar sobre como eles isolam seus usuários uns dos outros.
Você está operando seu próprio servidor de hospedagem compartilhada e não está usando o chroot para proteger seus usuários? Evidentemente, chrooting seus ambientes pode ser difícil. Felizmente, há uma abundância de plugins que facilitam isso. Dê uma olhada no mod_chroot, em particular.
Injeção de Comando
Vamos voltar para Alice e Bob. Então, sabemos que o aplicativo da web de Bob tem alguns… Ahem… Problemas de segurança. Uma delas é a vulnerabilidade de injeção de comando, que permite executar comandos arbitrários do sistema Um Guia Rápido para Começar a Usar a Linha de Comando do Linux Um Guia Rápido para Começar a Usar a Linha de Comando do Linux Você pode fazer muitas coisas incríveis com comandos no Linux e não é realmente difícil de aprender. Consulte Mais informação .
O site de Bob permite que você execute uma consulta whois em outro site, que é exibido no navegador. Há uma caixa de entrada HTML padrão que aceita um nome de domínio e, em seguida, executa o comando whois system. Este comando é executado chamando o comando PHP system ().
O que aconteceria se alguém inserisse o seguinte valor?
example.com && cd ../alice/ && rm index.html
Bem, vamos acabar com isso. Parte disso pode ser familiar para você se você leu nosso Guia de Introdução ao Linux Guia de Introdução ao Linux Guia de Introdução ao Linux Um Guia de Introdução ao Linux para Linux! Você provavelmente já ouviu falar sobre o Linux, o sistema operacional gratuito e de código aberto que vem sendo contra a Microsoft. Leia mais e-book, que publicamos anteriormente em 2010, ou olhemos para nossa Cheat Sheet Linux Command Line.
Primeiramente, ele executará uma consulta whois em example.com. Em seguida, ele mudaria o diretório de trabalho atual para a raiz de documentos de Alice. Em seguida, ele removeria o arquivo chamado 'index.html', que é a página de índice do site dela. Isso não é bom. Não senhor.
Então, como administradores de sistemas, como mitigamos isso? Bem, voltando ao exemplo anterior, podemos sempre colocar cada usuário em seu próprio ambiente isolado, desinfetado e chroot.
Também podemos abordar isso de um nível de linguagem. É possível (embora isso possa quebrar coisas) para remover globalmente declarações de função de idiomas. Isso quer dizer que é possível remover a funcionalidade dos idiomas aos quais os usuários têm acesso.
Olhando para o PHP em particular, você pode remover a funcionalidade com o Runkit - o kit de ferramentas oficial do PHP para modificar a funcionalidade da linguagem. Há uma riqueza de documentação por aí. Leia sobre isso.
Você também pode modificar o arquivo de configuração do PHP (php.ini) para desabilitar funções que são frequentemente abusadas por hackers. Para fazer isso, abra um terminal no seu servidor e abra seu arquivo php.ini em um editor de texto. Eu gosto de usar o VIM, mas o NANO também é aceitável.
Encontre a linha que começa com disable_functions e adicione as definições de função que você deseja banir. Nesse caso, seria exec, shell_exec e system, embora seja interessante notar que existem outras funções internas que são exploradas por hackers.
disable_functions = exec, shell_exec, sistema
Ataques baseados em linguagem e intérprete
Então, vamos dar uma olhada no PHP. Esta é a linguagem que alimenta um número surpreendente de sites. Ele também vem com uma série de idiossincrasias e comportamentos estranhos. Como isso.
O PHP é geralmente usado em conjunto com o servidor web Apache. Na maior parte, é impossível carregar várias versões do idioma com essa configuração.
Por que isso é um problema? Bem, vamos imaginar que o aplicativo da web de Bob foi originalmente construído em 2002. Isso foi há muito tempo. Isso é quando Michelle Branch ainda estava no topo das paradas, Michael Jordan ainda estava jogando para o Washington Wizards e PHP era uma linguagem muito diferente.
Mas o site de Bob ainda funciona! Ele usa um monte de funções PHP descontinuadas e depreciadas, mas funciona! Usando uma versão moderna do PHP seria efetivamente quebrar o site de Bob, e por que Bob deveria reescrever seu site para atender aos caprichos de seu host?
Isso deve lhe dar uma idéia do dilema que alguns web hosts enfrentam. Eles precisam equilibrar a manutenção de um serviço arquitetônico sólido e seguro, ao mesmo tempo em que mantêm isso em harmonia com a garantia de que os clientes pagantes estão satisfeitos.
Como resultado, não é incomum ver hosts menores e independentes usarem versões mais antigas do PHP (ou qualquer idioma, por sinal).
Não é incomum ver hosts menores e independentes usando versões mais antigas do PHP, potencialmente expondo os usuários a riscos de segurança.
Por que isso é uma coisa ruim? Bem, em primeiro lugar, isso exporia os usuários a vários riscos de segurança. Como a maioria dos principais pacotes de software, o PHP está constantemente sendo atualizado para lidar com a grande quantidade de vulnerabilidades de segurança que são constantemente descobertas (e divulgadas).
Além disso, isso significa que os usuários não podem usar as mais recentes (e melhores) funções de linguagem. Isso também significa que as funções que foram reprovadas por um motivo permanecem. No caso da linguagem de programação PHP, isso inclui as funções mysql_ ridiculamente terríveis (e recentemente preteridas) que são usadas para interagir com o MySQL Relational Database System, e dl (), que permite aos usuários importar suas próprias extensões de idioma.
Como usuário, você deve ser capaz de ver qual versão de um interpretador está sendo executada em seu serviço. Se estiver desatualizado ou contiver várias vulnerabilidades de segurança, entre em contato com seu host.
E quanto aos administradores de sistema? Você tem algumas opções aqui. O primeiro (e mais promissor) é usar o Docker para cada um dos seus usuários. O Docker permite que você execute vários ambientes isolados simultaneamente, da mesma forma que uma máquina virtual, embora sem precisar executar outro sistema operacional. Como resultado, isso é rápido. Realmente muito rápido.
Em inglês simples? Você pode executar o mais recente e melhor interpretador de ponta para a maioria de seus usuários, enquanto os clientes que estão usando aplicativos antigos que usam intérpretes antigos e obsoletos fazem isso sem comprometer outros usuários.
Isso também tem a vantagem de ser agnóstico de idioma. PHP, Python, Ruby. Tanto faz. É tudo a mesma coisa.
Não tenha pesadelos.
Este post foi destinado a fazer algumas coisas. Em primeiro lugar, foi para trazer a sua atenção o número de questões de segurança que as empresas de hospedagem têm de enfrentar, a fim de garantir a segurança de seus clientes e seus dados.
Ele também pretendia mostrar como os sites hospedados no mesmo servidor podem afetar um ao outro. Quer colocar um dente nisso? Comece a obedecer aos padrões de codificação bons e seguros. Em particular, comece a desinfetar suas entradas no front-end e no back-end.
Um bom começo é com a nova funcionalidade de validação de formulários HTML5. Já falamos sobre isso antes em nosso guia HTML5. Coletivamente, podemos tornar os sites mais seguros por serem programadores melhores e mais conscientes.
Como sempre, estou pronto para ouvir seus pensamentos. Deixe-me um comentário abaixo.
Crédito da foto: Todos precisam de um hacker (Alexandre Dulaunoy), adesivo na janela de táxi (Cory Doctorow), sala de servidores (Torkild Retvedt), livros e revistas sobre Linux (library_mistress), PHP Elephant (Markus Tacker)