segurança de apis http, um guia sensato para desenvolvedores preocupados
DESCRIPTION
Liberar uma API HTTP para seus usuários é a melhor forma de estimular ideias inovadoras baseadas no seu produto, porém para ser livre é necessário responsabilidade. Você já pensou qual o melhor método para garantir a segurança dos dados de seus usuários? Será que só basta implementar o melhor método de autenticação do mercado? Como balancear segurança com a queda de performance percebida pelo usuário, devido ao overhead do processo de autenticação? Devo me preocupar com rate-limiting? Com foco nesses desafios, a palestra apresentará os métodos de autenticação de APIs, suas vantagens e desvantagens, quando utilizar cada uma e liberar os dados com cabeça tranquila.TRANSCRIPT
@TwitterAds | Confidential
@lfcipriani2013-08-31
Segurança em APIs HTTPu m g u i a s e n s a t o p a r a d e v s p r e o c u p a d o s
Q C O N S P 2 0 1 3
@TwitterAds | Confidential
Quem?@lfcipriani
@TwitterAds | Confidential
O que?
@lfcipriani 4
TL;DR;
Esquemas de Autenticação HTTP
@lfcipriani 5
TL;DR; { Use OAuthUse SSL
Esquemas de Autenticação HTTP
@lfcipriani 6
TL;DR; { Use OAuthUse SSL
Qual o problema por trás do Too Long, Didn’t Read?
@lfcipriani 7
TL
Qual o problema por trás do Too Long, Didn’t Read?
#simplify
@lfcipriani 8
risco de segurança custo de implementação
O que devemos buscar?
@TwitterAds | Confidential
O que considerar?
@lfcipriani
Localização de sua API HTTP
10
@lfcipriani
Consumidores
11
@lfcipriani
Autoridade responsável
12
Centralizada
Distribuída
VS
@lfcipriani
Maturidade do modelo de segurança
13
Enviando uma carta de A para B
@lfcipriani
TLS/SSL
14
Regra geral:Os dados trafegados são sensíveis? Então use.
Tem o papel de simplificar esforços de implementação de autenticação.
Esqueça cache compartilhado sem revalidação
@lfcipriani
Rate Limit
15
Auxilia na implementação de cotas de acesso;
Protege de abuso de APIs;
Protege de mal entendidos;
Mas recomenpense o bom usuário, seja flexível;
Monitore cada endpoint e não a API como um todo.
@lfcipriani
Auditoria em API
16
Auxilia no esforço de implementação da autenticação;
Ajuda a corrigir o problema depois que o erro acontece;
Pode-se focar somente em operações de escrita e remoção.
@lfcipriani
Zele pelo conteúdo
17
Transforme dados de APIs internas antes de expor para usuários finais;
Assuma que toda entrada de dados é potencialmente maliciosa.
@TwitterAds | Confidential
Métodos de autenticação
@lfcipriani
Identificação baseado em Tokens
19
GET /post/1234?token=12ba3bf44edf3bf3123 HTTP/1.1
Accept: */*Accept-Encoding: gzip, deflate, compressHost: www.example.comUser-Agent: Your browser/1.0Authorization: 12ba3bf44edf3bf3123X-Extension: 12ba3bf44edf3bf3123Set-Cookie: token=12ba3bf44edf3bf3123
token=12ba3bf44edf3bf3123
@lfcipriani
Identificação baseado em Tokens
20
SSL recomendado sim, se houver dados sensíveis
Performance pouco impacto, se for usado como header extension ou entity body
RiscosToken na URL;Não é seguro, todos os ataques se aplicam
Processo de Adoção simples
@lfcipriani
RFC 2617HTTP Basic
21
Authorization: Basic YmFzZTY0ZW5jb2Rpbmc6aXNudGNyeXB0b2dyYXBoeQ==
Base64 encoding of username:password
@lfcipriani
RFC 2617HTTP Basic
22
SSL recomendado sim, para não vazar credenciais e se os dados são sensíveis.
Performance pouco impacto
Riscos
Plaintext credentials;Header Tampering;Dictionary Attacks;Replay attacks;Man-In-The-Middle;
Processo de Adoção simples, challenge-response
@lfcipriani
Autenticação baseada em Assinaturas Digitais
23
Os campos que você adiciona à assinatura influenciam na segurança.
@lfcipriani
Autenticação baseada em Assinaturas Digitais
24
SSL recomendado sim, se houver dados sensíveis
Performance impacto na geração de assinaturas
Riscos
se for adicionado URL, method, parâmetros, credenciais, nonce, timestamp, consegue-se proteger a aplicação de forma satisfatória.
Processo de Adoção médio, tem que lidar com a geração de assinaturas customizadas
@lfcipriani
HTTP Digest
25
Baseado em assinaturas
Porém, só protege as credenciais.
Pode oferecer integridade de mensagens se usado com qop=auth-int
RFC 2617
@lfcipriani
HTTP Digest
26
RFC 2617
SSL recomendado sim, se houver dados sensíveis
Performance impacto na geração de assinaturas
Riscos
security options são opcionais, portanto há risco de não utilizá-las;Man-In-The-Middle (Multiple Auth Mechanisms);Header Tampering;
Processo de Adoção médio, disponibilidade de bibliotecas pode não ser boa
@lfcipriani
OAuth
27https://github.com/Mashape/mashape-oauth/blob/master/FLOWS.md
@lfcipriani
Baseado em assinaturaOAuth 1.0a
28
POST /1/statuses/update.json?include_entities=true HTTP/1.1Accept: */*Connection: closeUser-Agent: OAuth gem v0.4.4Content-Type: application/x-www-form-urlencodedAuthorization: OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog", oauth_nonce="kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg", oauth_signature="tnnArxj06cWHq44gCs1OSKk%2FjLY%3D", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1318622958", oauth_token="370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb", oauth_version="1.0"Content-Length: 76Host: api.twitter.com
status=Hello%20Ladies%20%2b%20Gentlemen%2c%20a%20signed%20OAuth%20request%21
@lfcipriani
Depende de SSLOAuth 2.0
29
Authorization Code Grant
Implicit Grant
Resource Owner Password Credential Grant
Client credentials Grant
@lfcipriani
Há muitos cenários e várias implementaçõesOAuth
30
https://dev.twitter.com/docs/auth/obtaining-access-tokens
@lfcipriani
Críticas ao OAuth
31
http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/Oauth and the road to hell
OAuth, a great way to cripple your API (bag of ideas)
Oauth 1, Oauth 2, Oauth...?
http://insanecoding.blogspot.com.br/2013/03/oauth-great-way-to-cripple-your-api.html?m=1
http://homakov.blogspot.com.br/2013/03/oauth1-oauth2-oauth.html
@lfcipriani
Oauth em geral
32
SSL recomendado Oauth 1.0a, se houver dados sensíveis; se Oauth 2.0, obrigatório
Performance Oauth 1a, impacto na geração de assinaturas; Oauth 2, controle de expiração de tokens
Riscos
como há interação direta com usuário, há riscos de ataques de injeção nos inputs;diversidade de implementações podem expor vulnerabilidades;
Processo de Adoção complexo, depende do suporte oferecido aos usuários.
@TwitterAds | Confidential
Modelos de Permissionamento
@lfcipriani
Definindo a sua estratégia para proteger seus recursosModelo de permissionamento
34
•O quão sensíveis são meus dados?•Quais operações (read, write, destroy, admin) serão expostas?•Quem serão os consumidores da minha API?•Qual o prejuízo que vou ter se meus dados vazarem?•O quão importante os dados são para os meus usuários?•O quão importante os dados são para os hackers?•Minha API está exposta na Internet?•Quem será a autoridade para realizar autenticação?•Preciso auditar as operações?•Há a necessidade de um modelo híbrido de autenticação?
@TwitterAds | Confidential
Conclusão
@lfcipriani 36
risco de segurança custo de implementação
O que devemos buscar?A partir do seu modelo de permissionamento, escolha um ponto no eixo x
@lfcipriani 37
Links
The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws by Dafydd Stuttard and Marcus PintoHTTP: The Definitive Guide (David Gourley, Brian Totty, Marjorie Sayer and Anshu Aggarwal)
https://github.com/Mashape/mashape-oauth/blob/master/FLOWS.md#oauth-2-two-legged (OAuth Bible)http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/https://dev.twitter.com/docs/auth/obtaining-access-tokenshttps://dev.twitter.com/docs/auth/application-only-authhttp://www.ietf.org/rfc/rfc2617.txt (RFC Basic and Digest auth)http://tools.ietf.org/html/rfc6749 (RFC OAuth 2.0)
@TwitterAds | Confidential
Obrigado!