Apostila 5

Ameaças e Contramedidas
de Segurança na Aplicação

1
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Ameaças e Contramedidas de Segurança
na Aplicação
 Uma boa maneira de analisar ameaças no nível da
aplicação é organizá-las em categorias de
vulnerabilidade.

• Validação da • Gerenciamento de sessão

Entrada • Criptografia
• Autenticação • Manipulação de
• Autorização parâmetros
• Gerenciamento da • Gerenciamento de
configuração exceções
• Dados • Auditoria e registro
confidenciais
2
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
A validação da entrada é um problema de
segurança se um invasor descobrir que sua
aplicação faz suposições sem fundamento
sobre o tipo, extensão, formato, ou alcance
dos dados de entrada.
O invasor pode então fornecer
cuidadosamente uma entrada fabricada que
comprometerá sua aplicação.

3
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada

Quando os pontos de entrada no nível do

host e da rede estão totalmente seguros; as
interfaces públicas expostas pela sua
aplicação se tornam a única fonte de
ataque.
A entrada para a sua aplicação é um meio
de testar o seu sistema e uma forma de
executar códigos em benefício de um
invasor.

4
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Estouros do buffer
 Scripting entre-sites
 Injeção SQL
 Canonicalização

5
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Estouros do buffer
 As vulnerabilidades relacionadas ao estouro do
buffer podem levar aos ataques de negação de
serviço ou injeção de códigos.
 Um ataque de negação de serviço causa um
travamento do processo; a injeção de códigos
altera o endereço de execução do programa para
executar o código injetado pelo invasor.
 O seguinte fragmento de código ilustra um
exemplo comum de vulnerabilidade de estouro de
buffer.
6
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 void SomeFunction( char *pszInput ) { char
szBuffer[10]; // Input is copied straight into the
buffer when no type checking is performed
strcpy(szBuffer, pszInput); . . . }

7
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Códigos gerenciados .NET não são suscetíveis a
este problema porque os limites das matrizes são
checados automaticamente sempre que uma
matriz é acessada. Isto torna a ameaça do ataque
de estouro do buffer em códigos gerenciados uma
questão menos preocupante.
 Ainda é uma preocupação, no entanto,
especialmente onde códigos gerenciados chamam
objetos de APIs ou COM não gerenciados.

8
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Contramedidas para ajudar a evitar estouros do
buffer incluem:
 Execute uma validação de entrada detalhada.
Esta é a principal linha de defesa contra estouros
do buffer.
Apesar de poder haver um bug em sua aplicação
que permita que a entrada esperada vá além dos
limites de um contêiner, a entrada inesperada será
a principal causa desta vulnerabilidade.
Limite a entrada fazendo a sua validação por tipo,
extensão, formato e alcance.
9
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada

Sempre que possível, limite o uso de

códigos não gerenciados por sua aplicação,
e inspecione cuidadosamente as APIs não
gerenciadas para garantir que a entrada seja
devidamente validada.
Inspecione os códigos gerenciados que
chamam as APIs não gerenciadas para
garantir que apenas os valores apropriados
possam ser transmitidos como parâmetros
para a API não gerenciada.
10
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Use a bandeira /GS para compilar códigos
desenvolvidos com o sistema de desenvolvimento
do Microsoft Visual C++®.
 A bandeira /GS faz com que o compilador injete
checagens de segurança no código compilado.
 Esta não é uma solução à prova de falhas ou uma
substituição para o seu código de validação
específico; ela, no entanto, protege os seus
códigos contra ataques comuns de estouro do
buffer.

11
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Para mais informações, veja a documentação do
produto .NET Framework na página:
http://msdn.microsoft.com/library/default.asp?url=
/library/en-
us/vccore/html/vclrfGSBufferSecurity.asp1 (em
inglês) e o artigo do Microsoft Knowledge Base
325483 "Support WebCast: Compiler Security
Checks: The /GS compiler switch" na página:
http://support.microsoft.com/default.aspx?scid=32
54832.

12
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Exemplo de uma Injeção de Código através dos
Estouros do Buffer
 Um invasor pode explorar uma vulnerabilidade de
estouro do buffer para injetar códigos.
 Com este ataque, um usuário mal intencionado
explora um buffer não checado num processo
fornecendo um valor de entrada cuidadosamente
construído que reescreve o stack do programa e
altera as funções do endereço de retorno.
 Isto causa uma execução que pula para o código
injetado pelo invasor.
13
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada

O código do invasor geralmente acaba

sendo executado sob o contexto de
segurança do processo.
Isto enfatiza a importância do uso de contas
de processo menos privilegiadas.
Se o segmento atual está personificando, o
código do invasor acaba sendo executado
sob o contexto de segurança definido pelo
token de personificação do segmento.
14
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada

A primeira coisa que um invasor geralmente

faz é chamar a API RevertToSelf para
reverter o contexto de segurança no nível
do processo, que o invasor espera que
tenha privilégios mais altos.
Certifique-se de validar a entrada para tipo e
extensão, especialmente antes de chamar
códigos não gerenciados porque eles são
particularmente suscetíveis a estouros do
buffer.
15
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Scripting Entre Sites (XSS)
 Um ataque XSS pode fazer com que códigos
arbitrários sejam executados no navegador de um
usuário enquanto o navegador está conectado a
um site confiável da web.
 O ataque tem como alvo os usuários de sua
aplicação e não a aplicação em si, mas ele se
utiliza dela como um veículo para o ataque.

16
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Como o código do script pode ser obtido através
de download pelo navegador a partir de um site
confiável, o navegador não tem como saber que o
código não é legítimo. As zonas de segurança do
Internet Explorer não oferecem defesas.
 Como o código do invasor tem acesso aos
cookies associados com o site confiável e estão
armazenados no computador do usuário local, os
cookies de autenticação de um usuário
geralmente são o alvo do ataque.

17
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Exemplos de Scripting Entre Sites
 Para iniciar o ataque, o invasor deve convencer o
usuário a clicar num hyperlink cuidadosamente
criado, por exemplo, incorporando um link num e-
mail enviado para o usuário ou adicionando um
link malicioso a um posting de um fórum de
discussões.
 O link direciona para uma página vulnerável em
sua aplicação que ecoa a entrada invalidada de
volta para o navegador na corrente de output
HTML.
18
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Por exemplo, considere os dois links seguintes.
 Este é um link legítimo:
www.yourwebapplication.com/logon.aspx?usernam
e=bob
 Este é um link malicioso:
www.yourwebapplication.com/logon.aspx?usernam
e=<script>alert ('hacker code')</script>
 Se a aplicação web pegar a série de consulta,
falhar ao validado adequadamente, e retorná-lo ao
navegador, o código do script é executado no
navegador.
19
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 O exemplo anterior mostra uma mensagem pop-
up inofensiva.
 Com o script apropriado, o invasor pode
facilmente extrair o cookie de autenticação do
usuário, publicá-lo em seu site, e
subseqüentemente fazer uma solicitação para o
site alvo como se fosse o usuário autenticado.

20
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Contramedidas para evitar XSS incluem:
Execute uma validação cuidadosa da entrada. Suas
aplicações devem garantir que a entrada de
seqüências de consultas, campos de formulários, e
os cookies sejam válidos para a aplicação.
Considere toda a entrada de usuário
potencialmente malicioso, e filtre ou esterilize para
o contexto do código downstream.
Valide toda a entrada para valores válidos
conhecidos e então rejeite qualquer outra entrada.

21
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Validação da Entrada
 Contramedidas para evitar XSS incluem:
Use expressões regulares para validar dados de
entrada recebidos através de seqüências de
consultas, cookies e campos de formulários HTML.
Use funções HTMLEncode e URLEncode para
codificar qualquer output que inclua a entrada de
usuário.
Isto converte scripts executáveis em HTML
inofensivo

22
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Injeção SQL
 Um ataque de injeção SQL explora as
vulnerabilidades na validação de entrada para
executar comandos arbitrários no banco de
dados.
 Isto pode ocorrer quando a sua aplicação usa a
entrada para construir declarações dinâmicas do
SQL para acessar o banco de dados.
 Pode ocorrer também caso o seu código utilize
procedimentos armazenados que são seqüências
transmitidas que contêm entrada não filtrada de
usuários.
23
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Injeção SQL
 Com um ataque de injeção SQL, o invasor pode
executar comandos arbitrários no banco de
dados.
 O problema é ampliado se a aplicação usa uma
conta ultra privilegiada para se conectar ao banco
de dados.
 Nesta instância, é possível usar o servidor do
banco de dados para executar comandos do
sistema operacional e potencialmente
comprometer outros servidores, além de ser
capaz de buscar, manipular e destruir dados.
24
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Injeção SQL

Exemplo de Injeção SQL

Sua aplicação pode estar suscetível a
ataques de injeção SQL quando você
incorpora entradas não válidas de usuários
em consultas do banco de dados.
Mais suscetível ainda são os códigos que
constroem declarações dinâmicas do SQL
com entrada não filtrada de usuários.

25
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Injeção SQL
 Considere o seguinte código:
SqlDataAdapter myCommand = new
SqlDataAdapter(
 "SELECT * FROM Users
 WHERE UserName ='" + txtuid.Text + "'",
conn);

26
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Injeção SQL
 Os invasores podem injetar SQL ao finalizarem a
declaração intencionada do SQL com o caractere
aspa única, seguido do caractere ponto e virgula
para começar um novo comando, e então executar
o comando de sua escolha. Considere a seguinte
série de caracteres inseridas no campo txtuid.
'; DROP TABLE Customers-
 Isto resulta na seguinte declaração sendo
submetida ao banco de dados para execução.
SELECT * FROM Users WHERE UserName=''; DROP
TABLE Customers --'
27
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Injeção SQL
 Isto deleta a tabela Customers, assumindo que o
login da aplicação possui permissões suficientes
no banco de dados (outra razão para usar um
login com menos privilégio no banco de dados).
As linhas duplas (--) denotam um comentário do
SQL e é usado para comentar qualquer outro
caractere adicionado pelo programador, como a
aspa deixada.
 Nota O ponto e vírgula não é na verdade
necessário. O SQL Server executará dois
comandos separados por espaços.
28
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Injeção SQL
 Outros truques mais sutis podem ser
desempenhados. O fornecimento desta entrada no
campo txtuid:
' OR 1=1-
 cria este comando:
SELECT * FROM Users WHERE UserName='' OR
1=1-
 Como 1=1 é sempre verdadeiro, o invasor busca
qualquer fileira de dados da tabela do usuário.

29
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Injeção SQL
 Contramedidas para evitar a injeção SQL incluem:
 Execute validação cuidadosa da entrada. Sua
aplicação deve validar sua entrada antes de enviar
uma solicitação para o banco de dados.
 Use os procedimentos armazenados parametrizados
para acesso ao banco de dados para garantir que as
seqüências de entrada não sejam tratadas como
declarações executáveis. Se você não puder usar os
procedimentos armazenados, use os parâmetros do
SQL quando for construir comandos do SQL.
 Use contas com menos privilégios para se conectar
ao banco de dados.
30
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Canonicalização
 As formas diferentes de entrada determinadas
pelo mesmo nome padrão (nome canônico), são
chamadas de canonicalização.
 Os códigos são particularmente suscetíveis às
questões de canonicalização se são tomadas
decisões de segurança com base no nome de um
recurso que é transmitido para o programa como
uma entrada.
 Arquivos, caminhos, e URLs são tipos de recursos
vulneráveis à canonicalização porque em cada
caso existem muitas maneiras diferentes de se
representar o mesmo nome. 31
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Canonicalização
 Os nomes de arquivos também são
problemáticos. Por exemplo, um único arquivo
poderia ser representado como:
c:\temp\somefile.dat
somefile.dat
c:\temp\subdir\..\somefile.dat
c:\ temp\ somefile.dat
..\somefile.dat
 Em condições ideais, o seu código não aceita
nomes de arquivos de entrada.
32
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Canonicalização
 Se ele aceitar, o nome deve ser convertido para a
sua forma canônica anterior da tomada de
decisões de segurança, como se o acesso tivesse
sido concedido ou negado àquele arquivo
específico.
 Contramedidas para lidar com questões de
canonicalização incluem:
 Evite nomes de arquivos de entrada sempre que
possível e ao invés disso use caminhos de
arquivos absolutos que não podem ser alterados
pelo usuário final.
33
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Canonicalização
 Certifique-se de que os nomes de arquivos sejam
bem formados (se for absolutamente necessário
aceitar nomes como entrada) e os valide dentro do
contexto de sua aplicação. Por exemplo, verifique
se eles estão dentro da hierarquia do diretório de
sua aplicação.
 Certifique-se de que a codificação de caracteres
está determinada corretamente para limitar como
a entrada pode ser representada. Verifique se o
Web.config de sua aplicação está configurada nos
atributos requestEncoding e responseEncoding
no elemento <globalization>. 34
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação

Dependendo dos seus requisitos, existem

diversas opções de mecanismos de
autenticação disponíveis.
Se eles não forem escolhidos e
implementados corretamente, o mecanismo
de autenticação pode expor
vulnerabilidades que os invasores podem
explorar para ganharem acesso ao seu
sistema.

35
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 As principais ameaças que exploram as
vulnerabilidades da autenticação são:
 Escuta na rede
 Ataques de força bruta
 Ataques de dicionário
 Ataques de replay de cookies
 Roubo de credenciais

36
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Escuta na rede
 Se credenciais de autenticação forem transmitidas
em texto puro do cliente para o servidor, um
invasor armado com software rudimentar de
monitoramento de rede num host da mesma rede
pode capturar o tráfego e obter nomes e senhas
de usuários.

37
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Contramedidas para evitar a escuta na rede
incluem:
 Use mecanismos de autenticação que não
transmitem a senha através da rede, como o
protocolo Kerberos ou a autenticação do
Windows.
 Certifique-se de que as senhas serão encriptadas
(se for absolutamente necessário transmiti-las
através da rede) ou use um canal de comunicação
encriptado, por exemplo, com SSL.

38
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Contramedidas para evitar a escuta na rede
incluem:
 Use mecanismos de autenticação que não
transmitem a senha através da rede, como o
protocolo Kerberos ou a autenticação do
Windows.
 Certifique-se de que as senhas serão encriptadas
(se for absolutamente necessário transmiti-las
através da rede) ou use um canal de comunicação
encriptado, por exemplo, com SSL.

39
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Ataques de Força Bruta
 Os ataques de força bruta dependem do poder
computacional para descobrir senhas quebradas
ou outros segredos com quebra ou encriptação.
 Contramedidas:
 Utilize senhas fortes.

40
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Ataques de Dicionário
 Este ataque é usado para a obtenção de senhas.
 A maioria dos sistemas de senhas não armazena
senhas encriptadas ou em texto puro.
 Eles evitam senhas encriptadas porque uma
chave comprometida leva ao comprometimento de
todas as senhas no armazém de dados.
 Chaves perdidas significam que todas as senhas
estão invalidadas.

41
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 A maioria das implementações armazenadas de
usuários tem hashes de senhas (ou passoword
digests).
 Os usuários são autenticados reprocessando o
pedaço baseado no valor da senha fornecido pelo
o usuário e comparando-o com o pedaço do valor
armazenado no banco de dados.
 Se um invasor conseguir obter a lista de hashes
de senhas, um ataque de força bruta pode ser
usado para descobrir os hashes das senhas.

42
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Com o ataque de dicionário, um invasor usa um
programa para passar todas as palavras de um
dicionário (ou de diversos dicionários em línguas
diferentes) e computa a quebra para cada palavra.
 O pedaço resultante é comparado com o valor no
armazém de dados. Senhas fracas como
"Corinthians" (um time favorito) ou "Mustang" (um
carro favorito) serão descobertas rapidamente.

43
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Contramedidas para evitar ataques de dicionário
incluem:
 Use senhas fortes que sejam complexas, que não
sejam palavras normais e que contenham uma
mistura de maiúsculas, minúsculas, números, e
caracteres especiais.
 Armazene hashes não reversíveis de senhas no
depósito do usuário.Além disso, combine um
valor de salt (um número aleatório forte
criptografado) com a quebra da senha.

44
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Senhas fortes como
"?oCeNUnkVay6bMnhçEnHA!", são menos
passíveis de serem descobertas.
 Nota Assim que o invasor tiver obtido a lista de
hashes de senhas, o ataque de dicionário pode
ser executado offline e não requer interação com a
aplicação.

45
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação

Ataques de Replay de Cookies

Com este tipo de ataque, o invasor captura
o cookie de autenticação do usuário
monitorando o software e faz o seu replay
para a aplicação para ganhar acesso sob
uma falsa identidade.

46
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Contramedidas para evitar o replay de cookies:
 Use um canal de comunicação encriptado fornecido
pelo SSL sempre que um cookie de autenticação for
transmitido.
 Use um intervalo (timeout) de cookies para um valor
que força a autenticação após um intervalo de
tempo relativamente curto.
 Apesar de não evitar ataques de replay, esta medida
reduz o intervalo de tempo no qual o invasor pode
fazer o replay de uma solicitação sem ser forçado a
re-autenticar porque o tempo da sessão foi
esgotado.
47
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Roubo de Credenciais
 Se a sua aplicação implementa o seu próprio
armazém de usuários contendo nomes e senhas
de contas de usuários, compare sua segurança
com os armazéns de credenciais fornecidos pela
plataforma, por exemplo, um serviço de diretório
do Microsoft Active Directory® ou o armazém de
usuários do Security Accounts Manager (SAM).

48
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação

O histórico do navegador e do cache

também podem armazenar informações de
login de usuários para uso futuro.
Se o terminal for acessado por outra pessoa
que não o usuário que havia feito o logon, e
a mesma página for aberta, o login salvo
estará disponível.

49
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autenticação
 Contramedidas para evitar o roubo de credenciais
incluem:
 Use e reforce o uso de senhas fortes.
 Armazene verificadores de senhas na forma de
hashes com sal adicionado.
 Reforce o trancamento de contas para contas de
usuários finais após certo número de tentativas.
 Para barrar a possibilidade do cache do navegador
permitir o acesso do login, crie funcionalidade que
permite ao usuário escolher não salvar as
credenciais, ou force esta funcionalidade como uma
política padrão. 50
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autorização
 Com base na identidade do usuário ou na função
de membro, a autorização para um determinado
recurso é concedida ou negada.
 As principais ameaças que exploram as
vulnerabilidades da autorização incluem:
Elevação de privilégio
Revelação de dados confidenciais
Manipulação de dados
Ataques enganosos

51
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autorização

Elevação de Privilégio
Ao criar um modelo de autorização, é
preciso considerar a ameaça de um invasor
tentando elevar os privilégios para uma
conta poderosa como um membro do grupo
de administradores locais ou conta do
sistema local.
Ao fazer isto, o invasor é capaz de ter
controle total sobre a aplicação e máquina
local.
52
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autorização
 Por exemplo, com a programação clássica ASP, a
chamada da API RevertToSelf a partir de um
componente pode fazer com que o segmento em
execução seja executado como a conta do
sistema local com maior poder privilégios na
máquina local.

53
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Autorização
 A principal contramedida que pode ser usada para
evitar a elevação de privilégio é o uso de
processos, serviços e contas de usuários com
privilégio mínimo.

54
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Revelação de Dados Confidenciais
 A revelação de dados confidenciais pode ocorrer
se dados desta natureza forem visualizados por
usuários não autorizados.
 Dados confidenciais incluem dados de aplicações
específicas como números de cartões de crédito,
detalhes sobre empregados, registros financeiros,
e outros juntos com dados de configuração da
aplicação como credenciais de contas de serviço
e seqüências de conexão de bancos de dados.

55
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Revelação de Dados Confidenciais
 Para evitar a revelação de dados confidenciais, é
preciso protegê-los em armazéns persistentes
como bancos de dados e arquivos de
configuração, e durante o trânsito através da rede.
 Apenas usuários autenticados e autorizados
poderão acessar os seus dados específicos.
 O acesso aos dados de configuração no nível do
sistema deve estar restrito aos administradores.

56
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Revelação de Dados Confidenciais
 Contramedidas para evitar a revelação de dados
confidenciais incluem:
 Execute checagens de funções antes de permitir o
acesso às operações com potencial para a
revelação de dados confidenciais.
 Use ACLs fortes para proteger recursos do
Windows.
 Use encriptação padrão para armazenar dados
confidenciais em arquivos de configuração e em
bancos de dados.

57
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Ataques enganosos
 Um ataque enganoso (luring) ocorre quando uma
entidade (usuário, grupo ou recurso), com poucos
privilégios, faz com que outra, com mais
privilégios, execute uma ação em seu nome.
 Para barrar esta ameaça, é preciso restringir o
acesso a códigos de confiança com a autorização
adequada. O uso da segurança de acesso a
códigos do .NET Framework ajuda neste sentido,
ao autorizar um código de chamada sempre que
um recurso seguro é acessado ou uma operação
privilegiada é executada.
58
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Manipulação de Dados
 A manipulação (tampering) de dados trata-se da
modificação não autorizada de dados.
 Contramedidas para evitar a manipulação de
dados incluem:
 Use controles fortes de acesso para proteger
dados em armazéns persistentes para garantir que
apenas usuários autorizados possam acessar e
modificar os dados.
 Use segurança baseada em funções para
diferenciar os usuários que podem visualizar os
dados daqueles que podem modificá-los.
59
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Configuração
 Muitas aplicações suportam interfaces de gerenciamento
de configuração e funcionalidade que permite aos
operadores e administradores alterarem parâmetros de
configuração, atualizarem o conteúdo de sites, e
executarem procedimentos de manutenção rotineiros.
 As principais ameaças ao gerenciamento da configuração
incluem:
 Acesso não autorizado às interfaces de administração
 Acesso não autorizado aos armazéns de configurações
 Retorno de segredos de configuração em texto puro
 Falta de responsabilidade individual
 Contas ultraprivilegiadas de serviços e processos

60
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Configuração
 Acesso Não Autorizado às Interfaces de Administração
 Interfaces de administração geralmente são fornecidas
através de páginas adicionais da web ou aplicações da
web separadas que permitem aos administradores,
operadores, e desenvolvedores de conteúdo gerenciarem
o conteúdo e a configuração do site.
 Tais interfaces de administração devem estar disponíveis
apenas para usuários restritos e autorizados.
 Usuários mal-intencionados capazes de acessar uma
função de gerenciamento da configuração podem
desfigurar um site, acessar sistemas e bancos de dados
downstream, ou tirar a ação da aplicação através da
corrupção dos dados de configuração.
61
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Configuração
 Contramedidas para evitar o acesso não
autorizado às interfaces de administração
incluem:
 Minimize o número de interfaces de administração.
 Use autenticação forte, por exemplo, com certificados.
 Use autorização forte com guardiões múltiplos.
 Considere o suporte apenas da administração local. Se
a administração remota for absolutamente essencial,
use canais encriptados, por ex, com tecnologia VPN ou
SSL. Para reduzir ainda mais o risco, considere o uso de
políticas IPSec para limitar a administração remota aos
computadores da rede interna.
62
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Configuração
 Acesso Não Autorizado aos Repositórios de
Configurações
 Dada a natureza confidencial dos dados mantidos
nos repositórios de configurações, é preciso
garantir que estes locais estejam adequadamente
protegidos.
 Contramedidas para proteger os repositórios de
configurações incluem:
Configure ACLs restritas nos arquivos de
configuração baseados em texto como
Machine.config e Web.config.
63
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Configuração
Mantenha repositórios de configurações
customizados fora do espaço da web. Isto remove o
potencial para download de configurações de
servidores web para explorar suas
vulnerabilidades.
Retorno de Segredos de Configuração em Texto
puro

64
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Configuração
Restringir o acesso para o armazém de
configurações é absolutamente necessário.
Por ser um importante mecanismo de defesa
completo, deve-se tentar encriptar dados
confidenciais como seqüências de conexão e
senhas. Isto ajuda a evitar que invasores externos
obtenham dados de configuração confidenciais.
Isto também evita que administradores e
funcionários internos mal-intencionados obtenham
dados confidenciais como seqüências de conexão
de bancos de dados e credenciais de contas que
podem permitir que eles tenham acesso a outros
sistemas. 65
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Configuração
 Falta de Responsabilidade Individual
 A falta de auditoria e de registros de mudanças
feitas nas informações sobre as configurações
ameaça a habilidade para identificação sobre
quando as mudanças foram feitas e quem fez
estas mudanças.
 Quando uma mudança de transgressão é feita por
um erro de um operador honesto ou por uma
mudança mal-intencionada para garantir acesso
privilegiado, uma ação deve ser tomada, em
primeiro lugar, para corrigir a alteração.
66
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Configuração
 Então, devem ser aplicadas medidas preventivas
para evitar que alterações de transgressão
possam ser introduzidas da mesma maneira.
Lembre-se que a auditoria e os registros podem
ser driblados por uma conta compartilhada; isto
se aplica às contas administrativas e às contas de
serviço/aplicação/usuário.
 As contas administrativas não podem ser
compartilhadas.

67
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Configuração
 As contas de serviço/aplicação/usuário devem ser
destinadas a um nível que permita a identificação
de uma única fonte de acesso utilizando a conta, e
que contenha qualquer dano aos privilégios
concedidos àquela conta.

68
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Configuração
 Contas Ultra Privilegiadas de Serviços e Aplicações
 Se as contas de serviços e aplicações têm acesso
garantido para efetuar alterações nas informações de
configuração no sistema, elas podem ser manipuladas por
um invasor para fazer isso.
 O risco desta ameaça pode ser mitigado através da adoção
de uma política de uso de contas de aplicações e serviços
menos privilegiadas.
 Seja cauteloso ao conceder às contas a habilidade de
modificar suas próprias informações de configuração a
não ser que seja explicitamente necessário por design.

69
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Sessão
 O gerenciamento de sessão para aplicações web é
uma responsabilidade da camada de aplicação. A
segurança da sessão é crítica para a segurança total
da aplicação.
 As principais ameaças no gerenciamento de sessão
incluem:
 Seqüestro de sessão
 Replay de sessão
 Ataques "man in the middle"

70
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Sessão
 Seqüestro de Sessão
 Um ataque de seqüestro de sessão ocorre quando um
invasor utiliza um software de monitoramento de rede
para capturar o token (muitas vezes um cookie) de
autenticação usado para representar a sessão de um
usuário com uma aplicação.
 Com o cookie capturado, o invasor pode enganar a
sessão do usuário e ganhar acesso à aplicação.
 O invasor possui nível de privilégios igual ao do
usuário legítimo.

71
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Sessão
 Contramedidas para evitar o seqüestro de sessões
incluem:
 Use o SSL para criar um canal de comunicação e transmita
o cookie de autenticação apenas através de uma conexão
HTTPS.
 Implemente a funcionalidade do logout para permitir que um
usuário finalize uma sessão que força a autenticação se
outra sessão for iniciada.
 Certifique-se de limitar o período de expiração no cookie da
sessão caso você não utilize o SSL. Apesar desta medida
não evitar o seqüestro de sessão, ela reduz o tempo que
uma janela fica disponível para o invasor.

72
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Sessão
 Replay de Sessão
 O replay da sessão ocorre quando um token da
sessão do usuário é interceptado e submetido por um
invasor para desviar do mecanismo de autenticação.
 Por exemplo, se o token da sessão estiver em texto
puro em um cookie ou URL, um invasor poderá
detectá-lo.
 O invasor então submete uma solicitação usando o
token da sessão seqüestrada.

73
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Sessão
 Contramedidas para ajudar a lidar com a ameaça de
replay de sessão incluem:
Re-autentique quando estiver executando funções
críticas. Por exemplo, antes de executar uma
transferência de dinheiro numa aplicação bancária,
obrigue o usuário fornecer a senha da conta
novamente.
Finalize as sessões adequadamente, incluindo todos os
tokens da sessão e os cookies.
Crie uma opção "não se lembre de mim" que não
permita que nenhum dos dados da sessão ser
armazenados no cliente.
74
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Sessão
 Ataques "Man in the Middle"
 Um ataque "man in the middle" (homem no meio) ocorre
quando o invasor intercepta mensagens enviadas entre
você e a pessoa a quem a mensagem se destina.
 O invasor então altera a sua mensagem e a envia àquela
pessoa.
 Quem recebe a mensagem, vê que ela veio de você, e
age de acordo.
 Quando esta pessoa envia uma mensagem de volta, o
invasor a intercepta, altera o seu conteúdo, e a devolve a
você. Vocês dois jamais saberão que foram atacados.

75
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Sessão
 Qualquer solicitação da rede envolvendo a
comunicação entre cliente e servidor, incluindo
solicitações na web, solicitações de Distributed
Component Object Model (DCOM), e chamadas para
componentes remotos e serviços web, estão sujeitas
a ataques tipo "man in the middle".

76
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Gerenciamento da Sessão
 Contramedidas para evitar ataques tipo "man in the middle"
incluem:
 Use criptografia. Se você encriptar os dados antes de
transmiti-los, o invasor ainda poderá interceptá-los, mas não
poderá lê-los ou alterá-los. Se o invasor não puder lê-los,
ele não saberá qual parte alterar.
 Use os Códigos de Autenticação de Mensagens Quebradas
(Hashed Message Authentication Codes - HMACs). Se um
invasor altera a mensagem, o recálculo do HMAC no
recipiente falhará e os dados poderão ser rejeitados como
inválidos.

77
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início
Bibliografia
 http://technet.microsoft.com/pt-br/library/dd569900.aspx

78
Apostila 5 - Ameaças e Contramedidas de Segurança na Aplicação
Ir ao início