Segurança de APIs HTTP, um guia sensato para desenvolvedores preocupados

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