Artigo faz parte da disciplina de “Segurança de Sistemas”, do professor Elgio Schlemer.

Neste artigo são descritas as formas de autenticação e autorização de REST apis distribuídas, os motivos que aumentam a complexidade de desenvolvimento dessas futures em web services escalonados e as soluções baseadas nas melhores práticas em relação à essas arquiteturas.

Também é abordado a importância da criação de sistemas seguros, evidências que demonstram como esse problema impacta desde pequenas startups até grandes empresas, a gravidade da ciência do nível de criticidade e risco em relação aos softwares desenvolvidos e a importância de expor apenas recursos que sejam realmente necessários.

Serão mencionados também os perigos relacionados aos ataques de Man-in-the-middle, negação de serviço, SQL inject, JSON inject e os métodos utilizados para combatê-los.

INTRODUÇÃO

Informações sigilosas são expostas diariamente e esse problema não atinge apenas jovens startups que não tem o devido investimento na área, com frequência surgem notícias de grandes empresas que são hackeadas e acabam vazando dados indesejados. Somente neste ano, o Yahoo! afirmou que quinhentos milhões de contas foram hackeadas. No Dropbox foram mais de sessenta milhões e a Anatel teve seu banco de dados invadido. Inclusive grandes organizações como NASA e ESA não ficam fora dessa lista.

Softwares com suas arquiteturas baseados em micro serviços, orquestração e coreografias são termos cada vez mais citados na comunidade de desenvolvimento web. E todas as abordagens tem uma característica em comum: REST APIs. Elas estão por toda a parte.

Com o crescimento exponencial de estratégias digitais em mobilidade, cloud computing, mídias sociais e dispositivos inteligentes da Internet das Coisas, empresas de todos os tamanhos e setores estão desenvolvendo e expondo seus Web Services. Mas como sempre no mundo da computação, nem tudo são flores: junto com várias vantagens relacionadas à utilização de APIs distribuídas, também existem grandes problemas a serem resolvidos, e uma das maiores dificuldades é a segurança desses sistemas.

NÍVEL DE CRITICIDADE E RISCO

Já é sabido que não existe uma forma de manter dados totalmente seguros na internet. A segurança total é uma utopia, mas é possível de se dizer que existe um nível de segurança adequado para determinado software ou para dados específicos.

Antes de desenvolver ou arquitetar a segurança de uma API, é fundamental determinar o nível de criticidade existente nos dados que serão manuseados pela mesma, e quem serão os clientes que irão consumi-la. Se a API for disponibilizada apenas em uma rede bem configurada e consumidas apenas por sistemas desenvolvidos internamente, o risco será muito menor que se estiver disponível na internet e sendo consumida por centenas de sistemas desenvolvidos por outras empresas ou pela comunidade. Outro fator importante é ter o conhecimento dos dados trafegados pelo sistema e da criticidade de perda ou alteração deles.

A definição da forma de autenticação e de validações de acesso que será desenvolvido para cada API deve depender do nível de criticidade dos dados manuseados e do risco relacionado à perda ou modificação dos mesmos.

AUTENTICAÇÃO E AUTORIZAÇÃO

Primeira e principal preocupação relacionada à exposição de APIs. Sempre! Você é realmente quem diz ser? Você tem acesso a esse recurso? Estas são perguntas fundamentais. Evitar ataques de força bruta e roubo de credenciais são ameaças relacionadas à autenticação e autorização de APIs.

Existem várias alternativas que diminuem a força dessas ameaças, desde uma simples implementação do HTTP Basic, até o OAuth, que está se firmando como principal forma de delimitação de acesso à recursos em APIs. As maiores empresas do mundo da tecnologia aderiram a esse padrão, tais como Google e Facebook.

PRIVACIDADE

O descuido nesse quesito pode colocar uma boa implementação em risco, principalmente se suas APIs não forem disponibilizadas apenas em uma rede interna. Existem vários ataques em que um usuário consegue capturar as requisições e respostas feitas ao seu Web Service. E não tem nada de difícil nisso, a verdade é que qualquer roteador em que uma requisição passa tem acesso às informações trafegadas. Por isso é muito importante que seu servidor tenha um certificado HTTPS para que os dados trafegados não sejam legíveis para interceptadores mal intencionados.

Sabemos que é indispensável o uso do HTTPS na construção de APIs. Destaca-se que em algumas situações, até mesmo o uso de uma criptografia adicional é recomendável.

Um exemplo de ataque que utiliza os meios citados é o Man-in-the-middle, ou ataque do homem do meio. Consiste na interceptação de dados trocados entre duas partes, por exemplo o navegador de um usuário navegando em um site e a sua API. O interceptador tem a capacidade de registrar as informações em uma base local, ou até mesmo modificá las.

DISPONIBILIDADE

Mais um tópico onde o risco de ataque é muito maior no caso de sua API ser disponibilizada para todos na internet, ao invés de estar disponível apenas em uma rede interna. É sabido que existe a necessidade, mas é importante salientar a diferença da criticidade das duas situações. Isso demonstra muito bem a importância de um assunto já citado neste artigo: O levantamento do nível de criticidade e risco relacionado ao seu sistema.

DDoS, também citados como Ataques distribuídos de negação de serviços é um dos riscos mais comuns nas abordagens citadas neste artigo. A questão é: Como é possível construir softwares e definir a infra-estrutura ideal para resistir a esse tipo de ataque? Infelizmente não é possível se proteger de maneira completa em relação a esse risco, caso um grupo gigante de invasores desiste rodar scripts ao redor do mundo para atacar um software, não existe infra-estrutura no mundo capaz de resistir. Mas existem recursos que amenizam esse problema: monitorar o tráfego dos Web Services, gerando alertas capazes de identificar comportamentos maliciosos é imprescindível. Em determinadas situações também é importante limitar o uso das APIs por meio de controles de rate limiting.

AUDITORIA

É extremamente importante ter um gerenciamento de logs muito bem definido e implementado. Todas as requisições e respostas de um REST Web API devem ser registrados por completo. O que aconteceria se em um Web Service responsável por fazer a venda de produtos de uma loja virtual, uma venda for contabilizada para um usuário e ele alegar que não foi feito compra alguma? Nesses momentos será extremamente importante ter logs das requisições registradas.

Vale a atenção referente ao tamanho de arquivos de logs, que tendem a crescer muito. Importante que os registros sejam fáceis de registrar e consultar, para que seja possível ter uma resposta ágil no caso de algum incidente.

INTEGRIDADE

Novamente um risco que é mais recorrente em APIs disponibilizadas na internet. Alguns ataques de injeção de SQL ou JSON podem causar problemas graves. Para evitar esses problemas é muito importante que sua API exponha apenas recursos realmente necessários para seus clientes. A tecnologia utilizada para desenvolver a aplicação, o servidor utilizado e a forma de persistência são os principais pontos a serem ocultos, ou até mesmo omitidos.

Existem várias abordagens que modificam os cabeçalhos das requisições HTTP omitindo as tecnologias utilizadas, dificultando muito a ação de invasores. Também é imprescindível fazer o uso de filtros de dados de entrada, para evitar SQL e JSON injections e filtrar exceções para não correr o risco de exposição de tecnologias ou bugs.

SEGURANÇA DE SISTEMAS ESCALONÁVEIS E DISTRIBUÍDOS

Um software pode ser chamado de escalonável quando funciona bem em variados cenários. Ou seja, seu sistema deve estar preparado tanto para rodar no provedor de hospedagem da sua cidade, com 5 acessos ao mesmo tempo, quanto distribuído em centenas de servidores espalhados pelo mundo, capaz de ter milhares ou milhões de acessos simultâneos.

Arquiteturas de sistemas devem ser moldadas desde o ínicio levando em consideração a necessidade de escalonamento e distribuição, mesmo tendo como projeção inicial poucos acessos. Ao menos que a ambição relacionada ao software seja muito pequena, a forma de escalonamento e distribuição de um software deve ser pensada antes mesmo do seu desenvolvimento, porque se o número de acessos aumentar, será preferível ter construído uma aplicação escalável do que ter que ficar aumentando a memória ou capacidade de processamento do servidor a cada usuário novo acessando o sistema.

É no cenário de APIs distribuídas em vários servidores que a complexidade na manutenção da forma adequada da segurança da informação aparece. A partir do momento que um mesmo REST web service é distribuído em mais de um servidor, as informações de um usuário autenticado não são armazenados em uma sessão, por exemplo, pelo contrário, a autenticação deve acontecer em cada requisição. Existem vários padrões que resolvem esse problema, como HTTP Basic, Autenticação/Autorização baseada em certificados, Token-Based Authorization e OAuth.

CONCLUSÃO

Este documento apresentou os problemas recorrentes na autenticação e manutenção de um nível adequado de segurança em REST Web APIs. Fica clara a diferença do nível de criticidade e risco entre Web Services que são disponibilizados apenas em redes de empresas internas e APIs que são disponibilizadas para todos os usuários na internet. Em redes locais, requisitos que são extremamente críticos em APIs públicas, como disponibilidade e integridade, por exemplo, não necessitam de uma atenção tão grande.

É sabido que se há a necessidade de disponibilização de serviços na internet, é extremamente aconselhável o uso de REST, e pode-se concluir que esses sistemas devem ser arquitetados visando a escalabilidade e, principalmente, conhecendo o nível de criticidade e risco relacionado ao mesmo, pois só assim será possível encontrar a solução ideal para o nível de segurança ideal.

REFERÊNCIAS

BACILI, Kleber. Os fundamentos da segurança de APIs. Disponível em: <http://awshub.com.br/resources/os-fundamentos-da-seguranca-de-apis/>. Acesso em: 18 out. 2016.

REESE, George. Principles for Standardized REST Authentication. 26 dez. 2009. 10 f. Disponível em: <http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html>. Acesso em: 18 out. 2016.

SAUDATE, Alexandre. REST – Construa API’s Inteligentes de Maneira Simples. São Paulo: Ed. Casa do Código