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.