Algumas regras para uma API segura

A maioria das organizações modernas têm hoje formas de exposição de parte dos seus dados e bases de dados internas em servidores públicos. A forma mais comum de o fazer, hoje em dia, passa pelo uso de APIs que estabelecem e garantem segurança a essa ponte. Quando uma organização opta por esta via opta sempre pela primeira vez (mais se seguirão) é importante sublinhar que a segurança não está geralmente nos lugares cimeiros da lista de prioridades dos programadores que se focam mais na agilidade e desempenho e só depois, muito depois, na segurança.

Esse é o papel das áreas de Sistemas e Segurança que devem exigir aos Programadores que as API desenvolvidas ou utilizadas cumpram alguns requisitos:

1. A API deverá ter autenticação (crucial) e correr em https e TLS para impedir ataque MITM ("Man in the Middle"). Os Programadores devem igualmente avaliar o uso de mecanismos de autenticação seguros como OAuth, mutual (two-way) TLS (transport layer security) authentication ou SAML (security assertion markup language) tokens.
Quanto à autenticação da API existem 3 métodos para autenticar uma API:

HTTP Basic Auth, API Keys e Oauth.
Mas antes do mais importa distinguir entre Authentication e Authorization: Authentication prova uma identidade, como no mundo físico alguém prova a um polícia quem é mostrando um cartão de cidadãos e Authorization ocorre quando uma entidade prova o seu direito a aceder a um recurso: um pouco como alguém entra num cinema sem ter que mostrar quem é, mas apresentado o bilhete.

HTTP Basic Auth:
Um HTTP User Agent oferece um username e password para provar a sua Authentication. Nesta abordagem não são necessárias cookies, session IDs, login pages porque tudo assenta no próprio HTTP Header. O problema da HTTP Basic Auth está em que - a menos que se use SSL - a autenticação é transmitida em sinal aberto o que permite ataques "man in the middle" através da captura de tráfego. Mas mesmo quando esta comunicação ocorre em SSL há problemas devido ao tempo de processamento adicional. De recordar ainda que o HTTP na sua forma básica não é encriptado mas apenas encapsulado em base64. Por estas razões é que a HTTP Basic Auth faz sentido em redes locais e onde a velocidade não é o critério fundamental.

API Keys:
Nesta abordagem uma valor único é gerado e atribuído a um utilizador por vezes a partir de uma combinação do seu hardware, IP ou simplesmente gerado aleatoriamente. Esta chave prova assim a identidade de quem procura aceder à API. A sua maior vantagem é a rapidez e por essa razão é a forma mais corrente de autenticar uma API sendo, como é, fácil de configurar, de controlar o seu uso e de as renovar regularmente. Mas, cuidado, uma API key não é um método de Authorization mas sim um método de Authentication porque quem a transmite pode ser interceptado já que ela é transmitida em cada transacção: ou seja é um método fundamentalmente inseguro.

OAuth:
Antes do mais, há que distinguir entre a versão 1.0a e a 2.0 as quais não são compatíveis e profundamente diferentes. Tecnicamente, o OAuth não é um método de authentication mas um método híbrido de Authentication e Authorization. Nesta abordagem, o utilizador loga num sistema (como a Google ou o Facebook) que requer authentication geralmente sob a forma de um Token. O utilizador encaminha o pedido para um servidor de Oauth que a valida e se aceite o Token é fornecido ao utilizador durante um certo tempo e num certo alcance. Este método torna o Oauth fundamentalmente mais seguro que o HTTP Basic Auth e que o API Keys e por isso se está a tornar cada vez mais comum contudo pode ser excessivo para alguns usos mais básicos. Por outro lado, através do módulo de federação em que uma conta de um site é usada para logar num site diferente (via um Identity Provider (IdP) e um Service Provider (SP) o Oauth oferece uma vantagem adicional.

2. Uma API que sirva de ponte entre uma base de dados interna e um serviço publicamente disponível deve ter análise e listar métodos de chamada mais populares, níveis (severe, warning, config, info, fine, finer, finest e ajustáveis), os metadados assim como como mensagens e argumentos, sumarizar cargas num ciclo horário regular e ter mecanismos básicos de bloqueio por carga (DDos) e por IP de origem (adicionáveis manualmente). Idealmente, deve existir uma consola que liste em tempo real e historicamente estes por forma a simplificar a detecção de padrões de uso anómalos. Uma vez detectados, essa consola pode definir o IP como Allow (default), Block (em caso de anomalia e produzindo um result code 403) ou Flag para o colocar sob observação especial (e, talvez, redução de uso). Esta consola deve listar a quantidade de response errors nas últimas 24 horas, acessos que excederam a quota, sessões Oauth com grandes volumes de tráfego nos últimos minutos, a quantidade de sistemas operativos que usaram a API nos últimos minutos (botnets), padrões de tráfego elevados de um único IP nos últimos minutos, quantidade de sessões Oauth muito curtas nos últimos minutos assim como, todos os Ips que tenham origem na rede TOR.

3. Todas as chamadas à API devem ser logadas para análise futura devendo existir um log para as queries e com os seus resultados assim como um log separado para autenticação à API.

4. A autenticação não deve ser feita por uma password/API key que nunca expira: devendo ser incorporados mecanismos de alerta por mail regular quando esta API Key está prestes a expirar.

5. É importante garantir que a API/Web Service tem apenas um acesso limitado e de leitura à BD central se este for o necessário: quando menos acesso existir e menos dados forem acessíveis menos exposição a eventuais futuras intrusões existirão.

7. A API deve ter embebidos controlos de carga: limitando a um determinado valor a quantidade de queries que pode fazer à BD central deve, igualmente, incorporar um limite máximo ao nº de requests num dado período de tempo ("spike arrest"): quando esse limite é alcançado os acessos à API key devem ser bloqueados e deve ser enviado um alerta por mail e devolver o "429 (too many requests) HTTP error code". Este mecanismo protegé contra sobrecargas, ataques DDoS e garante o desempenho dos acessos normais e reduz o downtime.

8. Os ataques de "SQL Injection" são um dos tipos de ataques mais comuns na Internet e podem servir para obter todo o tipo de dados que estão disponíveis à API. O uso de "parameterized statements" e frameworks de "Object Relational Mapping" (ORM) são a melhor forma de prevenção contra este tipo de ataques. Por outro lado, todos os dados recebidos pela API devem ser validados (tamanho para evitar "HTTP response status 413 Request Entity Too Large", alcance e tipo (apenas números, boleanos, datas e tempos: evitar texto)

9. A API key não deve estar escrita em lado nenhum (mensagens de mail, documentação interna online, etc) a não ser num local físico e seguro.

10. A API deve controlar e apenas aceitar entradas e saídas para IPs muito específicos (não estar aberta ao mundo) designadamente apenas ao ip interno da máquina consultada. Isto é feito através de "Resource Policies" que negam acesso a todo e qualquer IP que não esteja explicitamente indicado. Todos os acessos de outros Ips terão um resultado "HTTP 403 Forbidden".

11. A documentação deve ser detalhada e precisa e a API só entra em produção depois desta escrita e partilhada (não antes) sendo um aspecto de segurança absolutamente essencial.

12. Todos os dados expostos na API estão ao alcance de um hacker potencial: logo estes devem ser um subset tão limitado quanto o estritamente necessário. Um set menor vai também contribuir para um melhor desempenho que um set com dados em excesso e cujo uso não é previsível a curto prazo.

Mais Notícias

Outros Conteúdos GMG

Patrocinado

Apoio de