O documento fornece diretrizes para implementar segurança em APIs HTTP, discutindo esquemas de autenticação como OAuth, SSL e assinaturas digitais. Ele também aborda tópicos como rate limiting, auditoria, conteúdo sensível e modelos de permissão para proteger recursos de acordo com seu nível de sensibilidade. A mensagem central é que os desenvolvedores devem escolher um esquema de autenticação equilibrando segurança e facilidade de implementação de acordo com os riscos envolvidos em cada caso.

1. @TwitterAds | Confidential
@lfcipriani
2013-08-31
Segurança em APIs HTTP
u 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

2. @TwitterAds | Confidential
Quem?
@lfcipriani

3. @TwitterAds | Confidential
O que?

4. @lfcipriani 4
TL;DR;
Esquemas de Autenticação HTTP

5. @lfcipriani 5
TL;DR; {Use OAuth
Use SSL
Esquemas de Autenticação HTTP

6. @lfcipriani 6
TL;DR; {Use OAuth
Use SSL
Qual o problema por trás do Too Long, Didn’t Read?

7. @lfcipriani 7
TL
Qual o problema por trás do Too Long, Didn’t Read?
#simplify

8. @lfcipriani 8
risco de segurança custo de implementação
O que devemos buscar?

9. @TwitterAds | Confidential
O que considerar?

10. @lfcipriani
Localização de sua API HTTP
10

11. @lfcipriani
Consumidores
11

12. @lfcipriani
Autoridade responsável
12
Centralizada
Distribuída
VS

13. @lfcipriani
Maturidade do modelo de segurança
13
Enviando uma carta de A para B

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

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

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

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

18. @TwitterAds | Confidential
Métodos de autenticação

19. @lfcipriani
Identificação baseado em Tokens
19
GET /post/1234?token=12ba3bf44edf3bf3123 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, compress
Host: www.example.com
User-Agent: Your browser/1.0
Authorization: 12ba3bf44edf3bf3123
X-Extension: 12ba3bf44edf3bf3123
Set-Cookie: token=12ba3bf44edf3bf3123
token=12ba3bf44edf3bf3123

20. @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
Riscos
Token na URL;
Não é seguro, todos os ataques se
aplicam
Processo de Adoção simples

21. @lfcipriani
RFC 2617
HTTP Basic
21
Authorization: Basic YmFzZTY0ZW5jb2Rpbmc6aXNudGNyeXB0b2dyYXBoeQ==
Base64 encoding of username:password

22. @lfcipriani
RFC 2617
HTTP 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

23. @lfcipriani
Autenticação baseada em Assinaturas Digitais
23
Os campos que você adiciona à assinatura influenciam na
segurança.

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

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

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

27. @lfcipriani
OAuth
27
https://github.com/Mashape/mashape-oauth/blob/master/FLOWS.md

28. @lfcipriani
Baseado em assinatura
OAuth 1.0a
28
POST /1/statuses/update.json?include_entities=true HTTP/1.1
Accept: */*
Connection: close
User-Agent: OAuth gem v0.4.4
Content-Type: application/x-www-form-urlencoded
Authorization:
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: 76
Host: api.twitter.com
status=Hello%20Ladies%20%2b%20Gentlemen%2c%20a%20signed%20OAuth%20request%21

29. @lfcipriani
Depende de SSL
OAuth 2.0
29
Authorization Code Grant
Implicit Grant
Resource Owner Password Credential Grant
Client credentials Grant

30. @lfcipriani
Há muitos cenários e várias implementações
OAuth
30
https://dev.twitter.com/docs/auth/obtaining-access-tokens

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

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

33. @TwitterAds | Confidential
Modelos de Permissionamento

34. @lfcipriani
Definindo a sua estratégia para proteger seus recursos
Modelo 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?

35. @TwitterAds | Confidential
Conclusão

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

37. @lfcipriani 37
Links
The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws by
Dafydd Stuttard and Marcus Pinto
HTTP: 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-tokens
https://dev.twitter.com/docs/auth/application-only-auth
http://www.ietf.org/rfc/rfc2617.txt (RFC Basic and Digest auth)
http://tools.ietf.org/html/rfc6749 (RFC OAuth 2.0)

38. @TwitterAds | Confidential
Obrigado!