owasp top 10 - web security

Segurança Web OWASP 2013 – TOP 10

; 10) Redirects e Forwards não validados

• Aplicações web geralmente usam redirects e forwards para enviar usuários para outras páginas/sites. Sem a validação necessária, agressores podem redirecionar as vítimas para sites maliciosos OU utilizar forwards para acessar páginas não autorizadas.

10) Redirects e Forwards não validados

Como funciona?

Exemplos:

1) http://www.meusite.com/redirect.jsp?url=virus.com

2) http://www.meusite.com/redirect.jsp?fwd=admin

10) Redirects e Forwards não validados

Como evitar?

1) Evite forwards e redirects

2) Caso realmente sejam necessários, não utilize parâmetros do usuário para “definir” o destino;

3) Se os parâmetros não podem ser evitados (geralmente podem) verifique que o valor informado é válido para o usuário (whitelist)

10) Redirects e Forwards não validados

; 9) Usar componentes com falhas de segurança

conhecidas

Bibliotecas vulneráveis podem ser exploradas por usuários maliciosos. O impacto de falhas de segurança em bibliotecas/componentes pode variar bastante.

9) Usar bibliotecas com falhas de segurança conhecidas

Como funciona?

1) É difícil.

2) Não usar nenhuma biblioteca?

3) Verificar o site/bugzilla/changelog/issues das bibliotecas que estão sendo utilizadas, incluindo as dependências;

4) Manter as bibliotecas atualizadas

9) Usar bibliotecas com falhas de segurança conhecidas

Como evitar?

; 8) CSRF (Cross-Site Request Forgery)

Como funciona?

1) Usuário se autentica normalmente no site exemplo.com.br

2) Sem efetuar logout, o usuário visita o site virus.com.br, que faz uma requisição maliciosa para o site exemplo.com.br

3) Como o usuário ainda está autenticado, caso o site exemplo.com.br não esteja protegido, a requisição funcionará normalmente.

8) CSRF

Exemplos...

8) CSRF

Como evitar?

1) Evitar CSRF geralmente implica em criar uma token em cada requisição HTTP. Essa token dever única e mudar, no mínimo, a cada nova sessão.

2) A token também pode ser incluída na URL (através da query string, mas isso é menos seguro)

3) CAPTCHAs também ajudam a proteger contra CSRF.

8) CSRF

; 7) Falta de verificação de acesso em

funcionalidades

Como funciona?

• Um usuário malicioso simplesmente muda a URL ou muda um parâmetro e acessa uma funcionalidade do sistema que deveria estar bloqueada.

7) Falta de verificação de acesso em funcionalidades

Como evitar?

1) O mecanismo de autorização deve, por padrão, negar acesso a uma funcionalidade e só permitir acesso caso o usuário possua a permissão explicitamente definida

2) A maior parte das aplicações não exibem links e botões para telas/rotinas bloqueadas, mas essa validação também deve ser efetuada no Controller ou na lógica de negócio

7) Falta de verificação de acesso em funcionalidades

6) Exposição de dados confidenciais

1) Existe algum dado confidencial (ex.: senhas, número de cartões de crédito) armazenado em texto?

2) A conexão está usando HTTP (ao invés de HTTPS) para transmitir dados confidenciais?

6) Exposição de dados confidenciais

; 5) Configuração incorreta de segurança

Exemplos:

1) Existem recursos desnecessários habilitados ou instalados (ex. portas, serviços, páginas, contas, privilégios)?

2) Os usuários e senhas padrão foram alterados?

3) No caso de erros no sistema, o stack trace é exibido para os usuários (ou qualquer outra informação excessiva)?

4) As configurações padrão de segurança nos frameworks de desenvolvimento (ASP.NET, Spring, Struts) foram alteradas?

5) Configuração incorreta de segurança

; 4) Referências diretas não protegidas

Exemplos:

http://www.meusite.com/compras/detalhe?idCompra=1234

4) Referências diretas não protegidas

1) Valide o acesso antes de exibir o conteúdo

2) Não utilize referências diretas. Crie referências indiretas que são válidas somente para um usuário ou sessão (map)

4) Referências diretas não protegidas

Como evitar?

http://marcoagner.com/posts/ingresso.com-como-nao-lidar-com-seguranca-da-info/

4) Referências diretas não protegidas

Outro exemplo:

; 3) XSS (Cross-Site Scripting)

• Um usuário malicioso envia texto contendo scripts que serão interpretados pelo browser

• Praticamente qualquer fonte de dados pode ser a origem da injeção de scripts: campos de texto, URL, banco de dados

• O impacto da injeção de script inclui: roubar sessão, modificar sites (phising), redirecionar usuários, forçar download de arquivos, etc.

3) XSS (Cross-Site Scripting)

1) Nunca confiar em dados fornecidos pelo usuário

2) Fazer escape dos caraceteres que serão exibidos na página/script/url

3) Content-Security-Policy header

4) https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

3) XSS (Cross-Site Scripting)

Como evitar?

; 2) Autenticação/gerenciamento de

sessão incorreto

• Autenticação e gerenciamento de sessão é difícil de implementar corretamente;

• As aplicações normalmente possuem falhas que permitem usuários maliciosos obter senhas, logins, tokens de sessão ou explorar outras falhas para utilizar a identidade de outro usuário

2) Autenticação/gerenciamento de sessão incorreto

Exemplos...

2) Autenticação/gerenciamento de sessão incorreto

2) Autenticação/gerenciamento de sessão incorreto

1) Senhas não são criptografadas durante o armazenamento 2) Credenciais podem ser adivinhadas, recuperadas ou

alteradas através de funções como “esqueci minha senha”, “mudar senha”, etc;

3) Sessions Ids são expostos na URL (URL rewriting) 4) Session ids são vulneráveis a “Session Fixation” 5) Sessão não é invalidada durante o logout ou nunca expira 6) Senhas/session ids são enviados sem criptografia em

conexões não criptografadas (ex.: HTTP)

; 1) Injection

RECAPITULANDO...

1) Injection 2) Autenticação/gerenciamento de sessão incorreto 3) XSS (Cross-Site Scripting) 4) Referências diretas não protegidas 5) Configuração incorreta de segurança 6) Exposição de dados confidenciais 7) Falta de verificação de acesso em funcionalidades 8) CSRF (Cross-Site Request Forgery) 9) Usar componentes com falhas de segurança conhecidas 10) Redirects e forwards não validados

; 0) Heart Bleed

"Catastrophic is the right word. On the scale of 1 to 10, this is an 11."

Application Security Verification Standard

ASVS ASVS

Referências

o https://www.owasp.org o https://www.owasp.org/index.php/Category:OWASP_App

lication_Security_Verification_Standard_Project o http://docs.spring.io/spring-

security/site/docs/3.2.x/reference/htmlsingle/#csrf o https://freedom-to-tinker.com/blog/wzeller/popular-

websites-vulnerable-cross-site-request-forgery-attacks/