Desenvolvimento de software seguro

Desenvolvimento de Software Seguro

Charles FortesMTAC – Microsoft Technical Audience Contributor

{ }Secure Coding

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.

Desenvolvimento de Software Seguro{ }Secure Coding

@CharlesFortes

Dave, nosso desenvolvedorVocê já o deve ter conhecido em Plants Vs Zombies

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


@CharlesFortes

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

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.


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


@CharlesFortes

{‘ or 1 = 1 -- }Insecure Coding

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


@CharlesFortes

var commandText = “ Select * From [Security].[User] U Where U.UserName = ‘” + txtNome.Text + ”’ and U.Password = ‘‘’ + txtSenha.Text + ”’”;

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

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


@CharlesFortes

U.UserName = ‘

??

??

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


@CharlesFortes

!Select * From [Security].[User] U

Where U.UserName = ‘’ or 1 = 1 -- and U.Password ‘’

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

Pode inclusive acessar arquivos e

informações do servidor...


@CharlesFortes

CREATE TABLE usuarios (lista_usuarios blob);

LOAD DATA INFILE ’/etc/passwd’ INTO TABLE

usuarios;

SELECT * FROM usuarios;

LiveSample


@CharlesFortes


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

O que fazer?


@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 como o NHibernate


@CharlesFortes

sqlCommand.CommandText = "select * from Books where Title = @title"; sqlCommand.Parameters.AddWithValue("title", txtTitle.Text);

select * from Books where Title = ‘’’ or 1 = 1 -- ‘

Caracter de escapeInterpreta o código injetado como texto simples

para bancos sem suporte nativo a instruções com parâmetros

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.


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


@CharlesFortes

Obrigado


@CharlesFortes

About me on next page

Charles Fortes

MTAC - Microsoft Technical Audience ContributorComunidade Técnica Microsoft Belo Horizonte

Versionamento

GitTFSSVN

Desenvolvimento

WebDesktopMobile

Bancos de Dados

SQLMySQLNoSQLArquitetura

PracticesPatternsModeling

http://o15.officeredir.microsoft.com/r/rlid2013GettingStartedCntrPPT?clid=1046

Desenvolvimento de software seguro

Technology

Transcript of Desenvolvimento de software seguro