Desenvolvimento de software seguro

{}
Secure Coding

Desenvolvimento de Software Seguro
Charles Fortes
MTAC – Microsoft Technical Audience Contributor

{}
Secure Coding

@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

{}
Secure Coding

@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

{}
Secure Coding

@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.

{}
Secure Coding

@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

{}
Secure Coding

@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 + ”‟”;

{}
Secure Coding

@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...

?

?
??

{}
Secure Coding

@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 „‟

!

{}
Secure Coding

@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;

{}
Secure Coding

@CharlesFortes

LiveSample

{}
Secure Coding

@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)

{}
Secure Coding

@CharlesFortes

O que fazer?

{}
Secure Coding

@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

{}
Secure Coding

@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.

{}
Secure Coding

@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.

{}
Secure Coding

@CharlesFortes

Obrigado

About me on next page

Web
Desktop
Mobile

Charles Fortes

Git
TFS
SVN

Desenvolvimento

Versionamento

Practices
Patterns
Modeling

Arquitetura

SQL
MySQ
L
NoSQ
Bancos de
L
Dados

MTAC - Microsoft Technical Audience Contributor
Comunidade Técnica Microsoft Belo Horizonte

Desenvolvimento de software seguro

Mais conteúdo relacionado

Mais procurados (10)

Destaque (20)

Semelhante a Desenvolvimento de software seguro (20)

Mais de Charles Fortes (15)

Último (11)

Desenvolvimento de software seguro

Notas do Editor