Dicas Do Trabalho Individual

Segurança Da Web
==============
Aspectos de Segurança na Web

A Web foi projetada sem muita preocupação, ou quase nenhuma, com segurança. O objetivo principal era disponibilizar informações de uma forma mais amigável que os recursos disponíveis na época. Com o rápido crescimento da Web e com a diversificação de sua utilização, a segurança se tornou um ponto de importância crucial, principalmente para quem tem a Web como um dos principais apêlos comerciais. Este artigo aborda alguns ítens de segurança que devem ser levados em consideração em um servidor Web.

Deveremos tratar, em outros artigos, outros aspectos relacionados à segurança na Web, como: aspectos relacionados à segurança da máquina, no cliente Web, dos dados em trânsito, assim como algumas recomendações para tornar seu servidor Web mais seguro.

As Ameaças na Web

Atualmente, a Web enfrenta diferentes formas de ameaça que foram surgindo ao longo de sua evolução. A Web não introduziu muito mais ameaças de segurança do que já existia na Internet. A Internet funciona para a Web como seu mecanismo de transporte e portanto herda suas vulnerabilidades de segurança. Devido à pressa na construção de novas funcionalidades em todo o ambiente, projetistas não consideraram o impacto em segurança que esta nova tecnologia causaria, deixaram de ver importantes pontos de possíveis ataques e vulnerabilidades. A Web não demorou muito em caminhar da comunidade científica para o mundo comercial. Neste ponto, as ameaças tornaram-se mais sérias. Uma nova tecnologia encontrava-se disponível e muito atrativa para os atacantes.

O quadro a seguir apresenta uma comparação das principais formas de ameaças.
Integridade Confidenciabilidade Negação de Serviço Autenticação
Ameaças - modificação de dados do usuário

- browser cavalo de Tróia

- modificação de memória

- modificação de mensagens em trânsito
- eavesdropping

- roubo de info/dado do servidor/cliente

- info da configuração da rede/máquinas...

- info de qual cliente "conversa" com servidor em trânsito
- bloqueio da conexão

- inundação da máquina com solicitações bogus

- isolamento máquina por ataques a DNS
- personificação de usuários legítimos

- falsificação de dados
Consequências - perda de info

- compromete a máquina

- vulnerabilidade para outras ameaças
- perda de informação

- perda de privacidade
- interrupção

- aborrecimento

- impedir usuário realizar seu trabalho
- má representação do usuário

- crença que informação falsa é verdadeira
Medidas - checksums criptográfico - encriptação, Web proxies - difícil prevenir - técnicas criptográficas

Integridade

Ataques contra integridade consistem em alterações maliciosas de dados, programas, mensagens e até mesmo informações da memória. Este tipo de ataque é devastador. Na maioria dos sistemas, este tipo de ataque permite ao atacante ler/modificar/remover qualquer arquivo, enviar mensagem, etc, enfim ter total controle de seu computador.
Confidenciabilidade

Este ataque tenta revelar informações confidenciais para terceiros. Um atacante pode tentar obter estas informações na máquina do usuário ou no servidor. Normalmente, assumimos que informações em nossas máquinas locais são privadas, mas poucos têm ciência de que uma vez que você esteja conectado à Internet estas informações podem não se tornar tão confidenciais assim. Por exemplo, os "browsers" normalmente mantém caches locais de visitas efetuadas pelos usuários a servidores Web que podem revelar alguns "hábitos" deste usuário.
Negação de Serviço

Esta é uma das mais sérias ameaças na Web e a mais difícil de prevenir. Este tipo de ataque consiste em ações maliciosas que desviam acessos a um determinado serviço que se encontra disponível. Web spoofing é um exemplo típico deste tipo de ataque, acessos feitos a determinado servidor Web são desviados para um outro servidor, normalmente um clone. Veja o exemplo abaixo:
Suponha que um competidor de uma empresa X deseja "roubar" informações ou parte das transações desta empresa X.
A empresa X tem um servidor Web: [Apenas Administradores podem visualizar links] com IP: 1.2.3.4
O competidor que tem um servidor Web com aparência idêntica a [Apenas Administradores podem visualizar links] e envia (fazendo "spoofing" no DNS) o endereço IP 5.6.7.8
O usuário que conecta com [Apenas Administradores podem visualizar links] na verdade está conectando com o servidor em 5.6.7.8 (o falso servidor Web). Efetua suas transações e não percebe que efetuou a compra em um site falso ou simplesmente, este site informa preços elevados, o que faz o usuário procurar a empresa concorrênte da empresa X (eg, a própria empresa "intrusa" neste caso).
Autenticação

Neste caso, o atacante se faz passar por outro, obtendo a senha do usuário por algum método qualquer, como por exemplo, filtrando pacotes na rede e capturando senhas não criptografadas.

Segurança no Servidor

Em um ambiente cliente/servidor as atenções normalmente estão direcionadas para o servidor, onde residem as informações e portanto foco de ameaças. Os clientes na Web estão fora de nossa guarda e assim fora do nosso controle. A proteção do cliente, não é o grande objetivo, a não ser quando se trata de sua privacidade. Segurança no servidor Web consiste, em geral, em um ponto crítico em relação para algumas organizações que tem a Web a sua principal fonte de renda.

Os assuntos de segurança tratados aqui são direcionados ao servidor Apache em ambiente Unix por ser o mais utilizado na Internet. Mas, a maioria das recomendações, tópicos, sugestões, etc. mencionada é válida para outros servidores Web.

Configurações Básicas

Um dos maiores problemas de segurança, assim como com outros serviços de rede, é o mau gerenciamento. Sistemas distribuídos com uma má configuração pode significar um desastre. Sistemas crescem e também crescem em sua complexidade. Se não se tem uma boa configuração torna-se difícil o emprego de uma política de gerenciamento satisfatória.
Como são organizadas estas configurações?

Arquivos de configurações contêm diretivas que são tratadas pelo daemon httpd. Estas diretivas controlam o comportamento de funções do servidor, como: controle de acesso a páginas (nomes e senhas), disponibilização de recursos, etc.
Um exemplo: uma diretiva que bloqueia acessos indevidos (bloqueia acessos ao arquivo de senha /etc/passwd)

Alguns cuidados devem ser levados em consideração: saiba o que já vem previamente configurado em seu servidor ao instalá-lo; comente (iniba) o desnecessário e conheça bem o que você tem configurado em seu servidor Web; configure seu servidor para tratar acessos indevidos; não esqueça de checar seus logs constantemente, etc.
Estrutura de Diretórios

A estrutura hierárquica de diretórios de um servidor Web é composta de dois diretórios. Os diretórios:
Raiz do servidor: tem informações de controle do servidor, como: arquivos de configurações, aplicações adicionais, etc.
Raiz de Documentos (o Web space do servidor): contém o conteúdo "público" (informações disponibilizadas via conexões HTTP). Geralmente este é um sub-diretório do diretório raiz do servidor.

Ao se "disparar" um servidor Web, todas as informações abaixo da raiz do diretório de documentos poderão ser disponibilizadas publicamente a menos que se tenha alguma restrição de acesso. Um dos erros mais comuns é se executar o servidor Web como "root", o que trás algumas vulnerabilidades para seus sistemas. Uma solução muitas vezes adotada é rodar o servidor Web como usuário "nobody", que também trás vulnerabilidades. Algumas aplicações também podem estar sendo executadas como "nobody" e portanto o servidor Web passa a ter seus mesmos privilégios. Uma boa estratégia é criar um usuário qualquer (e também um grupo) específico para o servidor Web (exemplos: web, www, webserver, etc...). Assim, acessos ao sistema de arquivo serão restringidos a este usuário, e também eventuais ataques feitos ao servidor também seriam afetados ao usuário Web específico do servidor.
Server-Side Include (SSI)

SSI é um código HTML que "injeta" a saída de um comando ou um arquivo dentro da página quando enviada pelo servidor para o browser. A formatação HTML é um conteúdo estático, SSI é um conteúdo dinâmico.

Alguns exemplo ilustrando o uso de SSI:
Tamanho do arquivo (fsize)
HTML com SSI

<!--#config sizefmt="byte"-->
O tamanho deste arquivo é <!--#fsize="arquivo.shtml"--> bytes
gera a saída

O tamanho deste arquivo é 34564 bytes
Includes: incluíndo um arquivo em outro
HTML com SSI

Este é um exemplo de texto de um outro arquivo
<< <!--#include virtual="arquivo.shtml"--> >>
Texto acima foi incluído do arquivo <i> arquivo.shtml </i>
gera a saída

Este é um exemplo de texto de um outro arquivo
<< texto incluído >>
Texto acima foi incluído do arquivo arquivo.shtml

SSIs são bastante úteis, mas podem também ser "caros" computacionalmente, acabam com a portabilidade e podem abrir sérios furos de segurança. Se esta funcionalidade não é necessária para o seu servidor, é melhor desabilitá-la.
Autenticação

Em geral, serviços Web são muito dependentes de servidores de nomes. Se um servidor de nome é atacado, servidores Web dependentes deste serviço podem ter sua autenticação comprometida.
Autenticação Básica

Um serviço que provê autenticação básica utiliza a identificação do usuário (username) e a senha, que passa as claras (sem criptografia) pela rede. No máximo, em alguns casos, alguns pequenos "mascaramentos" são utilizados como o redirecionamento para uuencode do Unix. Algumas restrições de acesso podem ser utilizadas via arquivo .htaccess. Este arquivo contém diretivas, palavras chaves que norteiam o acesso do httpd.

Uma vez autenticado, vem a autorização. Existem dois tipos de autorização: por diretório e por servidor. Por diretório, significa restrição de acesso a um determinado diretório dentro de sua árvore do seu web space. Veja exemplo de um .htaccess:


AuthGroupFile /usr/local/httpd/etc/group
AuthUserFile /usr/local/httpd/etc/user
AuthName Empresa ABC
AuthType Basic

order allow,deny
allow from all
deny from .badguy.com.br
require user antonio
require group suporte

Autorizações por servidor somente muda a localização das diretivas, agora definidas no servidor, que podem ser sobrepostas por outras por diretório.
Digest Authentication

Diferentemente do que ocorre em Autenticação Básica, em DA a senha não passa pela rede as claras. A comunicação entre as partes envolvidas, neste esquema, contém um checksum, por default MD5 (http://ds.internic.net/rfc/rfc1321.txt), o username, a senha, o método HTTP, e um autenticador único (geralmente um número randômico longo), além da URL requisitada. O objetivo é melhorar a segurança de senhas.
CGI Scripts

Quase todo servidor Web que se visita utiliza algum tipo de conteúdo ativo. Common Gateway Interface (CGI), é um tipo de matalinguagem ou middleware, que permite a interoperabilidade requerida por este conteúdo. É um mecanismo independente de plataforma provido pelo servidores Web que permitem executar programas/scripts a partir de uma URL. Estes scripts são geralmente escritos em Perl, Shell, Tcl, Java, Python ou C (maioria escritos em linguagem interpretadas) e localizados normalmente em um diretório /cgi-bin.

Aplicações CGI escritas sem cuidados com segurança podem causar sérios problemas a vulnerabilidades de servidores Web.

Um CGI script sendo executado sob o mesmo UID do servidor Web não é necessariamente um fato ruim, mas se alguma aplicação CGI possui um furo de segurança que permite que um atacante execute programas sob UID do servidor Web, isso pode acarretar um problema bastante sério ao seu site.

Uma maneira de contornar este problema é via "wrappers", isto é, programas que envolvem outros programas afim de alterar a maneira que estes operam. Assim, em ambientes onde usuários escrevem independentemente aplicações CGI, é uma boa estratégia isolá-los um dos outros, isto é, implementar mecanismos em seu servidor de maneira que acessos de scripts de um usuário não venham a interferir em dados de outros usuários. suEXEC (http://www2.idiscover.co.uk/apache/docs/suexec.html) resolve este problema (existem outras ferramentas que também tratam este problema) fazendo com que aplicações CGIs sejam executadas sob o UID do próprio usuário, isto é, o dono da aplicação CGI.

Referências

A.D. Rubin, D. Geer, and M.J. Ranum, Web Security Sourcebook, John Wiley & Sons, New York, 1997.
A.D. Rubin, D. Geer, A Survey of Web Security, Computer, September 1998, pp 34-41.
B. Laurie and P. Laurie, Apache: The Definite Guide, 2nd Edition, O'Reilly, 1999.

Ja vi varias respostas em q mandavam usar um site para criar o WBS, mas como seria um modelo de WBS de um site? o q é necessário informar? teriam modelos para me enviar?
e sobre segurança WEB eu preciso falar sobre ela ou dizer como será feita a segurança do suposto site??

aguardo a ajuda de VCS!!!