2. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
Pesquisas realizadas por instituições como o NVD
(National Vulnerability Database) e o OWASP (Open
Web Application Security Project) nos mostram que
a maior parte das vulnerabilidades de software
são resultados de má codificação.
Dave, nosso desenvolvedor
Você já o deve ter conhecido em Plants Vs Zombies
3. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
Um ataque pode ser feito por diversos caminhos da
aplicação, e ano após ano, a maior causa de
vulnerabilidade é a Injeção de Código (o qual iremos
focar nesta apresentação).
OWASP Top 10 – 2013
A1 – Injeção de código
A2 – Quebra de autenticação e Gerenciamento de
Sessão
A3 – Cross-Site Scripting (XSS)
A4 – Referência Insegura e Direta a Objetos
A5 – Configuração Incorreta de Segurança
A6 – Exposição de Dados Sensíveis
A7 – Falta de Função para Controle do Nível de Acesso
A8 – Cross-Site Request Forgery (CSRF)
A9 – Utilização de Componentes Vulneráveis Conhecidos
A10 – Redirecionamentos e Encaminhamentos Inválidos
4. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
Um ataque de Injeção de Código é feito em entrada
de dados de seu sistema
Caixas de texto
Parâmetros de inicialização
Arquivos
Etc.
5. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
Esta vulnerabilidade ocorre quando passamos o
conteúdo recebido na entrada de dados para ser
usado sem tratamento em uma instrução de nosso
sistema.
O ataque mais conhecido neste segmento é o
SQLInjection, que demonstra bem o problema.
{
‘ or 1 = 1 --
}
Insecure Coding
6. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
A forma mais comum de SQLInjection está no login
dos sites, quando desenvolvedores usam
concatenação da string digitada no TextBox de
usuário e senha para montar sua instrução de
consulta e autenticar seu usuário
var commandText = “ Select * From [Security].[User] U
Where U.UserName = „” + txtNome.Text + ”‟
and U.Password = „„‟ + txtSenha.Text + ”‟”;
7. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
Para este caso, basta o atacante usar trechos de
códigos SQL que serão concatenados a instrução
original. Para burlar esta autenticação, basta usar o
comando „ or 1 = 1 -•
A primeira parte do comando “‟” serve para
U.UserName = ‘
fechar a primeira instrução que valida o
nome do usuário
•
A segunda faz com que o a instrução retorne
dados “or 1 = 1”.
•
E a terceira “--” comenta o restante da
instrução invalidando qualquer validação
adicional que o Dave tenha feito...
?
?
??
8. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
O resultado é um comando SQL que retorna todos
os usuários do banco, e como o primeiro tende a
ser o administrador, o usuário tende a ter acesso
irrestrito a todo o sistema
Select * From [Security].[User] U
Where U.UserName = „‟
or 1 = 1 -- and U.Password „‟
!
9. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
Neste cenário, o atacante pode usar mais a sua
criatividade, e injetar um comando de DROP em seu
banco de dados, ou listar todas as tabelas do
sistema e seus conteúdos...
CREATE TABLE usuarios (lista_usuarios blob);
LOAD DATA INFILE ‟/etc/passwd‟ INTO TABLE usuarios;
Pode inclusive acessar arquivos e informações do
servidor...
SELECT * FROM usuarios;
11. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
Microsoft UK (julho/2007)
•
Desfiguração do site
Nações Unidas (agosto/2007)
•
Desfiguração do site
Sony Pictures (junho/2011)
•
Mais de 93mil contas roubadas
(senhas, nomes, e-mail, etc)
Yahoo!Voices (julho/2012)
•
Mais de 400mil contas roubadas
(usuários e senhas)
13. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
O desenvolvedor deve usar APIs e/ou Frameworks
que forneçam uma interface de parâmetros segura.
Para o caso de SQLInjection, podemos usar recursos
como as bibliotecas de dados do .NET e ORMs
sqlCommand.CommandText = "select * from Books where Title = @title";
sqlCommand.Parameters.AddWithValue("title", txtTitle.Text);
para bancos sem suporte nativo a
instruções com parâmetros
como o NHibernate
select * from Books where Title = ‘’’ or 1 = 1 -- ‘
Caracter de escape
Interpreta o código injetado como texto simples
14. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
O desenvolvedor deve sempre estar atento ao seu código e buscar usar as melhores práticas, além de
componentes seguros e consolidados para construir seus softwares.
Seja em ataques de Injeção de Comando, Quebra de Sessão, Cross-Site-Scripting ou qualquer outro sempre
devemos manter princípios como não confiar na entrada do usuário, usar privilégios mínimos e defesa em
profundidade.
15. {}
Secure Coding
Desenvolvimento de Software Seguro
@CharlesFortes
Não confiar na entrada do usuário
• Toda entrada de usuário deve ser armazenada e trada como parâmetro
Usar privilégios mínimos
• Não dar permissão Admin ou usar senha root no banco de dados para a aplicação, os privilégios a tabelas e dados
deve ser apenas o necessário para o funcionamento da aplicação
Defesa em profundidade
• As validações e boas práticas não devem estar apenas na camada de interação com o usuário, mas presente em todo o
código. Em uma aplicação web por exemplo, a validação pode ser feita client-side e server-side também.