DEV Community: Bernardo Bosak de Rezende

Dorking - O que podemos aprender sobre vazamento de dados por indexação involuntária em ferramentas de busca

Bernardo Bosak de Rezende — Thu, 09 Jul 2020 19:52:08 +0000

Esta semana o mercado da tecnologia aqui no Brasil foi ligeiramente movimentado pelo vazamento de alguns dados de correntistas de uma grande fintech, que estavam disponíveis nos resultados de busca do Google.

A empresa em questão (a qual sou um cliente bem satisfeito) já resolveu a situação e emitiu notas oficiais para esclarecimento, mas de qualquer forma acho que esta é uma boa oportunidade, diante de situações adversas, para evoluirmos e nos aperfeiçoarmos, por isso precisamos falar sobre o assunto.

Disclaimer

Gostaria de deixar bem explícito que esta postagem não é uma crítica à empresa, mas sim uma discussão técnica para evitar que futuramente isso venha a acontecer com outras equipes, produtos ou serviços.

Dito isso, vamos ao ocorrido.

Para facilitar a transferência de valores entre correntistas, o serviço disponibiliza um link (público e sem autenticação) que pode ser compartilhado entre diferentes pessoas para, a partir da leitura de um QR code, realizar uma transferência no aplicativo autorizado. Cada link listava algumas informações pessoais, como Nome, CPF, Agência, Conta, entre outros.

Estes links, que não são expirados e são públicos, acabaram sendo listados no índice de páginas do Google (de outros buscadores também), e com um pouco de "Google Hacking", uma pessoa desenvolvedora conseguiu encontrar vários destes links (contendo diferentes transferências entre contas), e escrever um script que "puxasse" estas informações de dentro do HTML dos documentos listados nos buscadores, podendo criar uma base com os dados extraídos. Estas informações podem ser usadas em tentativas de força-bruta ou até mesmo vendidas para terceiros, mas no caso citado a pessoa foi bem intencionada e reportou o problema para a empresa.

Tudo começa com uma busca no Google

Digamos que queiramos listar todas as páginas da Wikipédia que possuem /computação/ no endereço. Basta usar as diretivas site: e inurl:

Esse tipo de técnica é conhecido como Google Hacking ou Google Dorking, e é muito utilizada por hackers ou profissionais de PenTesting. É importante dizer que existem bancos de dados com estas brechas disponíveis para que outras pessoas consultem. Faça uma busca nas ferramentas e veja se alguma parte dos seus serviços estão listados. Existem várias diretivas que podem ser usadas, não somente site: e inurl:, no futuro compartilharei mais materiais sobre isso.

Mas, voltando ao contexto do ocorrido desta semana, a parte da URL /computação/ pode ser substituída por algo específico como /transferir/, que nos faria chegar na página de transferência de valores.

Exemplo de link: https://minhaempresa.com.br/transferir/sf9y8JV7b0Z

Pesquisa no Google:
site:minhaempresa.com.br inurl:/transferir/

A partir daí, basta escrever um script que acesse os links, interprete o conteúdo do documento HTML e extraia dele as informações desejadas (processo conhecido como web scraping). O Google aplica alguns bloqueios como reCAPTCHA em muitas tentativas de busca com estas diretivas, mas é possível automatizar todo o processo com quebradores de captcha ou requisições intervaladas.

Solução

Caso você se depare com esse tipo de exposição, você tem algumas opções:

Solicitar remoção das informações para o Google, bem recomendado como medida emergencial;
Alterar seu sistema para marcar os documentos como "não listáveis" em mecanismos de buscas;
Avaliar colocar mecanismos de autenticação (ou até mesmo reCAPTCHA) antes de exibir as informações (essa opção afeta experiência de uso)

Por ser tratar de uma abordagem preventiva, vou focar no item 2. Podemos escolher quais páginas/documentos desejamos não ter indexados nos buscadores e, mais ainda, instruir o mecanismo de busca para não seguir os links destes documentos. O primeiro nós resolvemos com a instrução noindex, e o segundo com a instrução nofollow. Podemos configurar isso de duas maneiras (bem simples):

Adicionando a metatag robots no HTML; ou
Alterando o cabeçalho HTTP X-Robots-Tag

Metatag robots

Você pode instruir os mecanismos de busca a não indexarem seus documentos colocando a seguinte metatag no head do HTML:

<head>
  <meta name="robots" content="noindex,nofollow" />
</head>

Todo documento que você deseja não indexar deverá incluir esta metatag. Para evitar a replicação, você pode procurar utilizar hierarquia de layouts (como este exemplo em pug), que é uma técnica comum em várias ferramentas e frameworks de desenvolvimento frontend.

Você pode alterar a metatag para buscadores específicos, bastando alterar o valor de name. Exemplo: para bloquear somente indexação no Bing, altere de robots para bingbot.

Cabeçalho X-Robots-Tag

Alternativamente, você pode preencher o cabeçalho HTTP X-Robots-Tag na resposta do documento HTML. Isto pode ser feito na configuração do servidor (ex: Apache, nginx, IIS, etc) ou no próprio código da aplicação. Vejamos alguns exemplos:

nginx (httpd.conf)

# avoid crawling of all html files
location ~* \.html$ {
  add_header X-Robots-Tag "noindex, nofollow";
}

Apache (.htaccess)

# avoid crawling of all html files
<Files ~ "\.html$">
  Header set X-Robots-Tag "noindex, nofollow"
</Files>

Flask (nível de código)

from flask import make_response

@app.route('/')
def home():
   res = make_response(render_template('index.html'))
   res.headers.set('X-Robots-Tag', 'noindex,nofollow')
   return res

Express

const express = require('express')
const app = express()

app.get('/', (req, res) => {
  res.set('X-Robots-Tag', 'noindex,nofollow')
  res.render('index.html')
})

Conclusão

Os danos da extração de dados por esse tipo de dorking podem ser muito altos, e como vimos, a solução preventiva é bem simples. Muitas vezes, falando de segurança da informação, as soluções são simples, mas infelizmente acabam não sendo priorizadas (não estou dizendo que foi o caso citado). Temos que manter o pilar da segurança aliado com os demais atributos que compõe a qualidade de um software e, ainda assim, correremos o risco constante de ciberataques.

Avalie seu portfólio de produtos e serviços e questione quais deles realmente precisam ser bem indexados em ferramentas de busca (como um dos maiores exemplos, geralmente sistemas administrativos internos não precisam ser indexados e ainda assim é fácil encontrá-los no Google).
Sempre que possível, implemente a expiração dos links públicos.
Utilizar autenticação sempre é uma ideia segura, mas por vezes ela interfere bastante na experiência de uso. Discuta com especialistas de produto e equilibre os pratos da balança, tente encontrar a solução com maior valor entregue ao seu cliente de uma forma segura.

DevSecOps - Mass Assignment

Bernardo Bosak de Rezende — Wed, 01 Jul 2020 18:32:30 +0000

Seguindo a série de posts sobre segurança no processo de desenvolvimento de software, hoje o assunto abordado será Mass Assignment, ou atribuição em massa, que é um sub-tipo de exploração utilizando alteração de parâmetros.

A OWASP elencou este tipo de vulnerabilidade como a 6ª mais importante se tratando de segurança para APIs.

Conheci este tipo de exploração quando o Rails 4 foi lançado em 2013, e junto com ele o conceito de Strong Parameters. Percebi que de lá pra cá muitos times de desenvolvimento deixam escapar verificações importantes de segurança que impediriam esse tipo de exploração. Por isso a importância de ser compartilhado.

Como funciona essa exploração

Basicamente, pessoas exploradoras podem tentar alterar valores críticos no seu banco de dados a partir de implementações no servidor que, ao evitar escrever códigos repetitivos, genericamente atualizam todos campos que foram enviados na requisição, sem verificações. Como exemplo, tomemos a seguinte estrutura de registro, para armazenar usuários em um sistema¹:

{
  "id": String,
  "name": String,
  "department": String,
  "address": String,
  "mobile": String,
  "isAdmin": Boolean
}

Em poucas palavras, usuários possuem nome, departamento onde trabalham, endereço, número de celular e a informação se um usuário é administrador do sistema ou não, que é utilizada em verificações de segurança.

Digamos que uma das funcionalidades do sistema é a de poder atualizar os dados de um usuário, como nome (name), endereço (address) e celular (mobile).

Uma implementação trivial, para esta funcionalidade, seria:

async function updateUser(id, newData) {
  try {
    await db.user.update(id, {
      name: newData.name,
      address: newData.address,
      mobile: newData.mobile
    })
  } catch (err) {
    console.error(err)
    return false
  }
  return true
}

Onde newData é um objeto com os valores atualizados dos campos de usuário, que provavelmente será enviado pela aplicação que controla a interface gráfica onde os usuários podem realizar as atualizações. Também estamos assumindo que db.user.update é uma função que atualiza o registro no banco de dados, de acordo com id. Foi realizado um tratamento mínimo de erro e, caso a operação não dê erro, retornamos true (caso contrário, false).

Onde começa o problema...

Muitos campos podem ser adicionados na estrutura de usuários, e com o passar do tempo esta rotina para atualizar os campos pode tornar-se repetitiva, exigindo que a cada inclusão de campo novo a função updateUser também seja alterada. Por este motivo, é comum que as pessoas desenvolvedoras tornem esta atualização "genérica", atualizando os registros de user independente dos campos que forem enviados em newData:

async function updateUser(id, newData) {
  try {
    await db.user.update(id, newData)
  } catch (err) {
    console.error(err)
    return false
  }
  return true
}

Do ponto de vista de engenharia e design de código, a segunda versão do código parece mais robusta, certo? Certo.

Porém, o código acima abriu uma brecha crítica de segurança: uma tentativa mal-intencionada de atualizar estas informações pode colocar, também, o campo isAdmin no objeto newData (e defini-lo como true). Caso o sistema não se proteja em relação a isso, mesmo que a interface gráfica do usuário não permita a edição deste campo, seria possível tornar qualquer usuário administrador do sistema.

Em termos práticos, é possível "montar" uma requisição de atualização de campos para o servidor (com analisadores de rede ou até mesmo as ferramentas de desenvolvimento dos browsers) e, mesmo havendo autenticação no sistema, ainda assim seria possível alterar campos de acesso crítico.

Em outros exemplos, seria possível zerar valores de produtos, alterar endereços de entrega de um pedido entre outras alterações de impacto crítico.

Resolvendo de forma trivial, porém segura...

Caso não queiramos permitir que apenas o campo isAdmin seja alterado, vamos retirá-lo do objeto que enviamos para db.user.update:

async function updateUser(id, newData) {
  try {
    // remove isAdmin from update using rest operator
    const { isAdmin, ...safeNewData } = newData
    await db.user.update(id, safeNewData)
  } catch (err) {
    console.error(err)
    return false
  }
  return true
}

Existem formas diferentes para remover um campo de um objeto, inclusive na mesma linguagem. No código acima, optei por utilizar o operador rest em uma atribuição por desestruturação, ambas construções do ECMAScript, para criar um novo objeto sem o campo isAdmin, em uma referência chamada safeNewData. Desta forma, respeitamos o princípio da imutabilidade, bem importante na programação funcional. Agora, independente dos valores que cheguem no objeto newData, o campo isAdmin não será alterado.

Tornando a solução segura e robusta...

Embora tenhamos resolvido o problema com segurança, agora temos dois code smells no código: rigidez e fragilidade. Existe um grande risco de qualquer alteração na estrutura de user demandar alterações na função updateUser, aumentando o acoplamento e custo de manutenção do código. Novos campos críticos, que não devem ser mexidos pelos usuários, deverão ser manualmente removidos no código de updateUser.

Como solução geral, independente da forma como for implementado, podemos criar uma lista com os campos que não podem ser atualizados (a menos que o usuário possua permissão para tal), você pode chamar esta lista como deny list, ou forbidden list.

const FORBIDDEN_FIELDS = [
  'id',
  'isAdmin'
]

Uma vez com a lista de campos que não podem ser alterados², nosso código pode, antes de atualizar o registro no banco de dados, remover todos os campos que estão em FORBIDDEN_FIELDS e também no objeto com os dados da tentativa de atualização.

Versão imperativa:

const maliciousUpdate = {
  name: 'New Name',
  address: 'New Address',
  isAdmin: true,
}

for (const [k, v] of Object.entries(maliciousUpdate)) {
  if (FORBIDDEN_FIELDS.includes(k)) {
    delete maliciousUpdate[k]
  }
}
console.log(maliciousUpdate)
// { name: "New Name", address: "New Address" }

Versão funcional:

const removeUnsafeFields = obj => Object.entries(obj)
  .filter(([k,v]) => !FORBIDDEN_FIELDS.includes(k))
  .reduce((acc, [k,v]) => ({ ...acc, [k]: v }), {})

const safeUpdate = removeUnsafeFields(maliciousUpdate)
console.log(safeUpdate)
// { name: "New Name", address: "New Address" }

Explicando um pouco a versão funcional: primeiro filtramos todas as tuplas [chave, valor] do objeto e pegamos somente aquelas cujo campo não esteja na lista de proibição de atualização (FORBIDDEN_FIELDS), depois nós juntamos todas estas tuplas restantes a partir de um objeto vazio, com uma operação de redução.

Basta aplicar a função removeUnsafeFields em pontos do código onde exista atualização. Caso você precise ter proibições diferentes para estruturas diferentes, basta parametrizar uma lista de proibição na função removeUnsafeFields, invés de usar sempre a mesma referência para FORBIDDEN_FIELDS.

Unificando estas verificações no nível da aplicação

Se você utilizar frameworks de desenvolvimento, provavelmente eles permitem que você execute código customizado toda vez que algum evento aconteça. No exemplo abaixo, toda vez que uma web app Express.js recebe uma requisição HTTP e a ação for um PATCH (update), realizamos a verificação de segurança no campo body da requisição:

const massAssignmentProtector = (req, res, next) => {
  if (req.method === 'PATCH') {
    const { body } = req
    req.body = removeUnsafeFields(body)
  }
  next()
}
app.use(massAssignmentProtector)

O exemplo completo, incluindo cenários demonstrando a brecha de segurança, encontra-se no replit abaixo:

Conclusões

Códigos genéricos, como essa atribuição em massa, tem pontos positivos (como a redução de boilerplate), mas podem expôr brechas de segurança. Por isso, sempre questione o código também na dimensão da segurança, pois ela é uma parte (bem) importante na qualidade do seu software.
Se preciso, implemente verificações por roles e permita que somente alguns perfis de usuários podem alterar todos os campos.
Se você possui campos sensíveis e que não podem ser alterados por interações com usuário (mas podem ser autocalculados ou coisas do tipo), nunca confie 100% nas atualizações ou operações que alguma camada externa manda para seu software. Sempre realize as suas verificações de segurança.

a estrutura dos campos é meramente didática e não representa os padrões de modelagem e normalização de dados. ↩
em muitos bancos de dados alterar o campo id gera um erro, mas o exemplo é didático. ↩

DevSecOps - DoS - Paginação de APIs (Parte 3)

Bernardo Bosak de Rezende — Wed, 24 Jun 2020 19:47:19 +0000

Este post faz parte de uma coleção de posts sobre segurança de software ao longo do processo de desenvolvimento e operação (DevSecOps). O tipo de vulnerabilidade abordado neste artigo é negação de serviço através da exploração de paginações de recursos de APIs.

Se você não leu as duas partes anteriores da série, recomendo sua leitura antes de continuar, pois ali são explicados alguns conceitos importantes, como o próprio DoS e log de acessos:

É comum, hoje em dia, que os sistemas precisem fornecer muitos registros de seus bancos de dados para que aplicações cliente consumam estas informações, seja exibindo em uma UI ou até mesmo realizando outros fluxos de operações com as informações obtidas. Seria impraticável, por vários motivos (latência, banda, tempo de resposta e, principalmente, experiência de usuário), fornecer todos os dados de uma tabela (muitas vezes gigantesca) de uma só vez. Como solução, os sistemas entregam seus dados em "lotes" pequenos. Estes lotes são chamados de páginas (de registros), e esse processo é chamado de paginação.

Ok, mas qual a relação disso com DoS (Denial of Service)?

Exemplo de como derrubar uma aplicação por ausência ou má configuração de paginação

Digamos que, um sistema de controle áudio visual, armazene informações sobre quais músicas estão disponíveis para serem ouvidas, e que você precisa disponibilizar estes dados para que várias aplicações possam tratá-los (ex: uma aplicação web, um aplicativo, uma planilha Excel com scripts VBA). Esta "exposição" dos dados pode ser feita de diversas formas (ex: SOAP, REST, protocolos binários, arquivos, etc), mas, como de costume, utilizarei um padrão forte de mercado que são as Web APIs modeladas em REST¹:

GET /api/songs

Na prática, isso significa que as aplicações cliente podem dizer "sistema de controle áudio visual, me disponibilize todas as músicas em sua base de dados". Se a quantidade de músicas for gigantesca (dezenas de milhões de registros), você consegue imaginar o problema para transferir estes dados, correto? Seus servidores podem ficar sem memória, a operação levaria um tempo impraticável que degradaria qualquer experiência de uso, ou seria necessário uma arquitetura de streaming de dados para transferir tanta informação de forma robusta.

Por estes motivos, nestas comunicações de software entre diferentes camadas físicas, é comum que os registros sejam disponibilizados de forma paginada. Ou seja, fornecemos os primeiros X elementos, depois mais X e assim por diante. Desta forma, a modelagem da nossa API de músicas mudou um pouco:

GET /api/songs?limit=20&offset=0

No endpoint acima, offset representa a quantidade de registros que desejamos pular antes de começar a consultá-los, e limit é a quantidade máxima de registros que serão consultados. Neste exemplo, o valor 0 é passado para offset e 20 para limit, ou seja: desejamos obter, no máximo, as 20 primeiras canções do banco de dados (critério de ordenação natural, pois nada foi especificado). Se quisermos os "próximos 20", basta trocarmos offset para 20 e continuar com o mesmo valor de limit. Se quisermos a "terceira página de 20 registros", offset recebe 40 e assim por diante. Também é comum que essa técnica de paginação utilize os termos skip (invés de offset) e take (invés de limit).

Outra alternativa é utilizar diretamente o conceito de página, onde informaríamos o número da página e o tamanho da mesma (20 primeiros registros = page 1 e pageSize 20).

Mas, independente da técnica de paginação, o importante é que você esteja ciente da importância do uso de paginação para a experiência de uso do software, para sua performance e... para a sua segurança também!

Isso mesmo, as paginações podem ser utilizadas para instabilizar seu sistema (um dos objetivos do DoS), pois se o código que realiza a paginação não controla o tamanho das páginas, você está exposto a receber tamanhos gigantescos de página e ter seu serviço instabilizado!

Vejamos, uma tentativa de ataque pode tentar realizar grandes quantidades da seguinte requisição:

GET /api/songs?limit=10000000&offset=0

Caso não exista uma "limitação" para o valor informado em limit, não existe ganho prático de fazer paginação. Isso é ruim para a performance e também expõe uma brecha para instabilidade, pois é possível consultar páginas com grandes quantidades de dados.

Solução

A solução é simples: estabelecer um limite seguro para o valor máximo que pode ser informado em limit (ou pageSize, take, etc).

Isso pode ser feito com uma verificação dos valores passados por parâmetro:

DEFAULT_LIMIT = 20
MAX_LIMIT = 100

limit = request.args.get('limit', DEFAULT_LIMIT)
if int(limit) > MAX_LIMIT:
    abort(400)
# query database with pagination parameters

Preferencialmente, centralize este controle de forma que todos os seus endpoints paginados realizem esta validação com facilidade e sem duplicação de código.

Por exemplo, podemos utilizar Python Decorators:

@app.route('/api/songs')
@ensure_safe_limit()
def get_songs():
    # normally here we'd call a database paginated query
    return jsonify([{'name': 'Respect', 'by': 'Aretha Franklin'},
                   {'name': 'Um dia frio', 'by': 'Djavan'}])

O decorator @ensure_safe_limit garante que nossa página estará segura de limites muito altos. Basta aplicá-lo em todos os endpoints paginados. O mesmo pode ser feito com Higher-Order Functions e com middlewares. Procure a documentação do seu framework ou plataforma de desenvolvimento!

A solução completa pode ser conferida no repl.it abaixo. A implementação do decorator está em utils.py.

Caso o limite "único" que você estabelece em todo seu software não atenda algumas situações específicas, aumente-o separadamente, sempre com bastante cautela e testes. Outra opção é você estabelecer estes limites por perfis de usuários do seu sistema. Por exemplo, usuários administradores possuem um limite de 1000 registros por páginas, usuários "visualizadores" possuem um limite de 50, pois realizam esta operação com muito mais frequência, etc.

Conclusão

É possível ver a importância de compor a proteção do seu software contra DoS em várias técnicas diferentes, pois além de controlar a quantidade de recursos por página, também é preciso controlar o throughput (quantidade de requisições por intervalo de tempo) com que isso é solicitado, conforme abordado na parte 1 desta série.

Caso seu software permitir que terceiros informem a quantidade de registros "por página", estabeleça um limite seguro dentro do seu contexto de aplicação. Adote isso como padrão de paginação.
Faça as devidas mensurações para encontrar um tamanho limite ideal para atender seus usuários sem expor seu sistema.
Conforme já dito, desenvolva uma visão "caixa preta" e analise a sua API com uma perspectiva externa, sem detalhes de implementação. A paginação é um possível ponto de brecha, mas existem outros. Por onde você pode estar vulnerável?

O exemplo dado em REST não anula ou inviabiliza o fato de que todo tipo de integração de dados, com a opção de paginar os recursos transferidos, tenha o mesmo tipo de preocupação abordado neste post, contra a exploração de grandes paginações para fazer a negação de serviço. Sempre questione a interface de programação que você está disponibilizando para terceiros! ↩

DevSecOps - DoS - Heavy payload attack (Part 2)

Bernardo Bosak de Rezende — Tue, 16 Jun 2020 13:12:33 +0000

Versão original em português disponível

This is part of a collection of posts about software security through the development and operation process (DevSecOps). The vulnerability covered in this article is denial of service by exploiting heavy requests payloads.

Denial of Service, or just DoS (a.k.a. DDoS), consists in several exploiting techniques that weaken your service, aiming to find security breaches along the maintenance window, make your service unavailable or simply raise your infrastructure costs, even the system not being impacted.

OWASP¹ considered this exploit the fourth most popular in terms of API security breaches, in 2019.

Once during the homologation phase for a brazilian information security label for e-commerces (SiteBlindado), I encountered a warning that some system operations were vulnerable to receive a much more larger data traffic than really needed. Then I had to setup specific requests payload size limits and it turns out to be a good DoS protection.

How to identify a heavy payload DoS

The most effective way to identify this attack situation is analyzing the requests size incoming to your servers. This information generally is available in access log formatters (e.g: nginx uses the variable $request_length). A common traffic log would be:

2020-06-05T10:14:02Z GET / 1.1.1.1 459 "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
2020-06-05T10:15:23Z GET /products 2.2.2.2 257 "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 523 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:17:20Z GET / 4.4.4.4 289 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:18:22Z GET / 5.5.5.5 336 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:19:11Z GET /products 318 6.6.6.6 "Mozilla/5.0 (Linux; U; Android 5.0.2; en-US; XT1068 Build/LXB22.46-28) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/12.10.2.1164 Mobile Safari/537.36"

The most important piece of information in this case is the number between the client IP address and the User Agent header value. For example, in the third request, this number is 523. This is the request total length in bytes, including header and body.

If your service is under attack with heavy requests payloads, you'll notice a huge difference between the normal requests length and what you are receiving during the attack attempt. That's why is important to know the common traffic limits of your software. Ordinarily, what's the average size of your requests?. If you're being attacked, it would exist an increase on third request above (normally these attacks use your resources with data post, such as an image upload or data form):

2020-06-05T10:16:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"

At this new log sample, we had an increase in the request's total length, from ~0.5kb up to 9mb! Mostly this symptom comes together with high throughput of the same heavy request, like this hypothetical log situation:

2020-06-05T10:14:02Z GET / 1.1.1.1 459 "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
2020-06-05T10:15:23Z GET /products 2.2.2.2 257 "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:17:20Z GET / 4.4.4.4 289 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:18:22Z GET / 5.5.5.5 336 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:19:11Z GET /products 318 6.6.6.6 "Mozilla/5.0 (Linux; U; Android 5.0.2; en-US; XT1068 Build/LXB22.46-28) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/12.10.2.1164 Mobile Safari/537.36"

Something is wrong with this considerable size and throughput increase. It's time to act!

Rightly configuring your server limits

The solution to mitigate this exploit is to establish hard limits to your requests size, avoiding your servers to unnecessarily work on heavy requests that exceeds the acceptable traffic to your system's common operation.

You can set these hard limits from "outside in", from your cloud application firewalls (like AWS WAF, CloudFlare WAF and Akamai Web Protector) to your reverse proxy or application servers. The great majority of servers provide an option to limit the maximum length of incoming requests. I'll list a few, from different architecture layers:

Limiting at the firewall;
Limiting at reverse proxy or load balancer;
- Nginx
Limiting at application server;
Limiting at application code;

Conclusions

Regularly monitor your application and your servers;
Know your application common limits and traffic;
- If you're receiving an attack attempt, being aware of your common traffic average size will make your life much easier on identifying the resource under attack.
Adopt the philosophy of "limiting down until necessary";
- Set low limits to ALL of your requests sizes (you can establish an average size based on your entrypoints with larger traffics).
- Raise these limits in a granular, specific and on-demand way (e.g: if you need a file upload, adjust the configuration to allow a higher request limit specifically to this upload operation).

The OWASP is a valuable information security community. It's important to keep updated with their periodic reports and publications! ↩

DevSecOps - DoS - Ataque de payload pesado (Parte 2)

Bernardo Bosak de Rezende — Mon, 15 Jun 2020 20:48:14 +0000

English version available here

Se você não leu o primeiro artigo da série de DoS, recomendo sua leitura antes de continuar, pois ali são explicados alguns conceitos importantes, como o próprio DoS e log de acessos!

Certa vez, enquanto homologava um site para receber o selo SiteBlindado, recebi uma notificação de que várias operações do sistema estavam suscetíveis a receber um tráfego muito maior de dados do que de fato necessitavam. Foi então que precisei configurar limites específicos para tamanhos de requisições e me dei conta que esta é uma boa proteção contra DoS.

Como identificar um DoS por requisições pesadas

A maneira mais eficaz para identificar este ataque é analisando o tamanho das requisições que seus servidores estão recebendo. Esta informação geralmente está disponível nos formatadores dos logs de acesso (por exemplo, no nginx usa-se a variável $request_length). Um log de tráfego normal seria:

2020-06-05T10:14:02Z GET / 1.1.1.1 459 "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
2020-06-05T10:15:23Z GET /products 2.2.2.2 257 "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 523 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:17:20Z GET / 4.4.4.4 289 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:18:22Z GET / 5.5.5.5 336 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:19:11Z GET /products 318 6.6.6.6 "Mozilla/5.0 (Linux; U; Android 5.0.2; en-US; XT1068 Build/LXB22.46-28) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/12.10.2.1164 Mobile Safari/537.36"

A informação mais importante neste caso é o número entre o IP do cliente que enviou a requisição e o valor do cabeçalho User Agent. Por exemplo, na terceira requisição, este número é 523. É o tamanho total da requisição em bytes, incluindo cabeçalhos e corpo.

Caso o seu serviço esteja sofrendo tentativas de ataque com requisições pesadas, você perceberá uma diferença grande entre o tamanho normal das suas requisições e o que está recebendo durante o ataque. Por isso a importância de conhecer os limites normais do seu software. Quanto costuma ser, em um tráfego de operação normal, o tamanho das suas requisições?. Nesta situação, poderíamos ter um aumento no tamanho da terceira requisição (normalmente estes ataques utilizam os seus recursos que aceitam postagem de dados, como upload de imagens ou cadastramento de formulários):

2020-06-05T10:16:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"

Neste novo log, tivemos um aumento no tamanho da requisição, indo de ~0.5kb para 9mb! Geralmente este sintoma vem acompanhado da repetição da requisição por várias vezes (o que abordamos no primeiro post):

2020-06-05T10:14:02Z GET / 1.1.1.1 459 "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
2020-06-05T10:15:23Z GET /products 2.2.2.2 257 "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:17:20Z GET / 4.4.4.4 289 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:18:22Z GET / 5.5.5.5 336 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:18:53Z POST /admin 3.3.3.3 9000000 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:19:11Z GET /products 318 6.6.6.6 "Mozilla/5.0 (Linux; U; Android 5.0.2; en-US; XT1068 Build/LXB22.46-28) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/12.10.2.1164 Mobile Safari/537.36"

Algo não está certo neste tipo de aumento considerável e repetitivo. É hora de agir!

Configurando corretamente os limites dos seus servidores

A solução para mitigar esta exploração é estabelecer limites para os tamanhos de requisições, evitando assim que seus servidores trabalhem desnecessariamente em requisições pesadas e que excedam o normal aceitável para a operação do serviço.

Você pode configurar estes limites de "fora para dentro", desde firewalls cloud (como o AWS WAF, Akamai Web Protector e CloudFlare WAF) até seus servidores de proxy reverso ou de aplicação. A grande maioria dos servidores fornece a opção de limitar o tamanho das requisições. Vou citar alguns, em camadas diferentes da arquitetura:

Limitando no firewall;
Limitando no proxy reverso ou balancer;
- Nginx
Limitando no servidor de aplicação;
Limitando no código da aplicação;

Conclusão

Monitore constantemente sua aplicação e seus servidores;
Conheça os limites normais da sua aplicação;
- Caso você esteja sofrendo ataques, saber o tamanho do seu tráfego normal facilitará bastante na identificação.
Adote a filosofia de "limitar por baixo até que seja necessário";
- Estabeleça limites pequenos para os tamanhos das suas requisições (a melhor dica é estabelecer uma média de tamanho com base nos seus pontos de entrada que recebem a maior quantidade de dados).
- Aumente estes limites de forma granular e especifica (por ex: se você precisa fazer upload de arquivos, ajuste a configuração para permitir um limite maior especificamente na operação de upload).

DevSecOps - DoS - Throughput e Rate Limit (Parte 1)

Bernardo Bosak de Rezende — Mon, 08 Jun 2020 23:24:39 +0000

Negação de serviço, ou DoS (a.k.a. DDoS), consiste em uma série de técnicas de exploração que instabilizam ou até mesmo indisponibilizam um serviço, visando encontrar brechas de segurança ao longo da manutenção da instabilidade, retirá-lo do ar ou simplesmente fazer com que o seu custo de infraestrutura aumente consideravelmente, mesmo que o sistema não tenha sido impactado.

A OWASP¹ considerou este tipo de exploração o quarto mais popular em termos de brechas de segurança para APIs, em 2019.

É possível tentar retirar um serviço do ar de diversas maneiras, e abordaremos como mitigar as três principais (mas neste artigo falaremos apenas da primeira):

1) Sabendo lidar com altas taxas de requisições (throughput);
2) Sabendo lidar com altas cargas em cada requisição (payload);
3) Limitando tamanho de paginações de recursos.

Como identificar um DoS

O primeiro passo é identificar uma situação de DoS. Geralmente fazemos isso analisando métricas de acesso ou logs de requisição.

Se você ainda não tem certeza da situação, comece analisando a quantidade de requisições que o seu sistema tem recebido nos últimos minutos / horas, preferencialmente procure pelo throughput recente do sistema (ex: total de requisições por segundo ou requisições por minuto). Se existe uma tentativa de DoS, você perceberá um aumento considerável no número de requisições em pequenos intervalos de tempo. Por exemplo, se você estiver visualizando um gráfico, ele representaria um crescimento:

Crescimento no gráfico de requisições recebidas pelo sistema

Aplicações como AWS CloudWatch, NewRelic, Datadog, Nginx Amplify possuem diversos destes tipos de gráficos. Geralmente eles são o primeiro indício de que algo está incomum.

Se você não tiver essas informações, procure nos logs de acesso de seus servidores. Comece analisando "de fora para dentro" (por exemplo, se a sua arquitetura tem um load balancer ou proxy reverso, comece por eles, e depois os servidores de aplicação e assim por diante).

Por exemplo, um log de acesso normal do nginx seria:

2020-06-05T10:14:02Z GET / 1.1.1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
2020-06-05T10:15:23Z GET /products 2.2.2.2 "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:17:20Z GET / 4.4.4.4 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:18:22Z GET / 5.5.5.5 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:19:11Z GET /products 6.6.6.6 "Mozilla/5.0 (Linux; U; Android 5.0.2; en-US; XT1068 Build/LXB22.46-28) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/12.10.2.1164 Mobile Safari/537.36"

Nesta situação, garanta que seus logs utilizam timestamp (data e hora da requisição), mas principalmente preocupe-se em identificar o IP de origem das requisições (ex: 1.1.1.1, 2.2.2.2, etc) e o cabeçalho User Agent, pois quando essas duas informações se repetem por várias requisições, temos o principal sintoma de DoS. As repetições podem seguir um padrão variável, mas muitas vezes elas serão constantes. Exemplo:

2020-06-05T10:14:02Z GET / 1.1.1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
2020-06-05T10:15:23Z GET /products 2.2.2.2 "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
2020-06-05T10:17:20Z GET / 4.4.4.4 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:18:22Z GET / 5.5.5.5 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
2020-06-05T10:19:11Z GET /products 6.6.6.6 "Mozilla/5.0 (Linux; U; Android 5.0.2; en-US; XT1068 Build/LXB22.46-28) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/12.10.2.1164 Mobile Safari/537.36"

O log acima demonstra um padrão repetitivo em excesso em um curto espaço de tempo (menos de um segundo), em requisições com o verbo POST na rota /admin (ex: um ataque de força bruta ao tentar submeter o formulário de login várias vezes):

2020-06-05T10:16:53Z POST /admin 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"

O que nos leva a crer que existe, sim, uma tentativa de DoS. É importante ressaltar que o mesmo ataque pode gerar inúmeras requisições de origens e user agents diferentes. Portanto, se você não encontrar um padrão para bloquear um conjunto específico de requisições, a melhor abordagem é intervalar o acesso ao seu sistema em uma janela de tempo, que veremos mais tarde.

Não deixe para configurar ferramentas em horas emergenciais, garanta que seu software possui um monitoramento adequado e que atende suas necessidades de manutenção de uma forma segura.

Exemplo de ataque por throughput

Um ataque mal-intencionado pode tentar reproduzir em alto volume qualquer requisição que seu sistema disponibilize, mesmo estando sob autenticação. Se o ataque possui acesso a fazer uma requisição, ele possui acesso a fazer 1 milhão, a menos que isso seja tratado, como veremos a seguir.

Uma pessoa com conhecimento não muito avançado de redes e desenvolvimento web conseguiria identificar como são enviadas as requisições para o seu sistema, através de analisadores de pacotes (bem usados para analisar tráfego de aplicativos), como WireShark ou TcpDump, ou simplesmente com as ferramentas de desenvolvimento dos navegadores Web (ex: Chrome DevTools).

Por exemplo, imagine que seu sistema possui um dashboard analítico, com várias métricas complexas e consultas de dados cruzados que demandam bastante recurso computacional para apresentá-los em tempo real², como o exemplo abaixo (Opsview, Ltd / CC BY-SA):

Exemplo de dashboard com várias métricas

Suponhamos que, para atender a este dashboard, exista a seguinte API:

GET /api/dashboard
Authorization: token-do-usuario-id-1

Uma vez que o ataque conheça a estrutura dessa requisição, e estando o token do usuário id-1 devidamente válido (em muitos sistemas, basta cadastrar um usuário para obter um token válido), é possível criar scripts que executem muitas vezes a requisição acima, afim de instabilizar o seu sistema:

import requests

url = 'https://seuservico.com/api/dashboard'
headers = { 'Authorization': 'token-do-usuario-id-1' }

for i in range(1000000):
    requests.get(url, headers=headers)

Idealmente (do ponto de vista de programação), o código que dispara essas requisições mal-intencionadas deveria ser assíncrono e paralelo, mas isso está fora do escopo abordado aqui, o importante é conhecer o funcionamento desses scripts para conseguir evitá-los. Ainda seria possível utilizar frameworks de testes de carga, como artillery, JMeter, k6, Gatling, etc.

Existem dois tipos de solução bem comuns para isso lidar com altas taxas de requisições:

1) Bloquear a origem das requisições (ex: IP, user agent, sessão ou token); ou
2) Estabelecer um limite para a quantidade de requisições que uma ou mais origens podem realizar em um determinado período de tempo. Ex: permitir que o token do usuário id-1 execute apenas uma requisição por segundo. Essa abordagem é conhecida como throttling.

Ambas alternativas podem ser resolvidas em nível de infraestrutura ou código de aplicação.

Resolvendo com infraestrutura

Resolver essa exploração com recursos de infraestrutura tem as vantagens de ser uma solução bem mais rápida (geralmente envolve configurar corretamente os servidores de firewall ou aplicação) e comprometer menos a arquitetura da solução. Bloquear ou intervalar requisições via software exige mais recursos computacionais de servidores que são provisionados para atender a aplicação, ao invés de realizar estas tarefas em servidores de firewall ou proxy reversos (como nginx), otimizados para esse tipo de responsabilidade.

Os pontos negativos ficam por conta do gargalo de conhecimento em infraestrutura que, infelizmente, muitas equipes enfrentam e do custo financeiro de algumas dessas soluções.

Já utilizei o AWS Web Application Firewall e gostei bastante, inclusive existem concorrentes de players gigantes do mercado de SRE:

Converse com os interessados pela arquitetura e infraestrutura do seu software, avalie serviços e soluções (em alguns casos configurar uma instância de proxy reverso é mais vantajoso) e monte um plano de ação para, de preferência, ter prevenção contra esse tipo de exploração.

Resolvendo com software

Podemos escrever pedaços de código que façam estas verificações anti-DoS (bloquear ou intervalar) e incluí-los no início do ciclo de vida das requisições no servidor de aplicação (os endpoints). Porém, muito provavelmente esse tipo de código já foi criado previamente e existe na stack de desenvolvimento que você utiliza, seja de forma incorporada (built-in) ou via código terceiro.

Por exemplo, para quem trabalha com o Express framework, existe uma biblioteca open-source chamada express-rate-limit:

express-rate-limit / express-rate-limit

Basic rate-limiting middleware for the Express web server

`express-rate-limit`

Basic rate-limiting middleware for Express. Use to limit repeated requests to public APIs and/or endpoints such as password reset Plays nice with express-slow-down and ratelimit-header-parser.

Usage

The full documentation is available on-line.

import { rateLimit } from 'express-rate-limit'

const limiter = rateLimit({
    windowMs: 15 * 60 * 1000, // 15 minutes
    limit: 100, // Limit each IP to 100 requests per `window` (here, per 15 minutes).
    standardHeaders: 'draft-7', // draft-6: `RateLimit-*` headers; draft-7: combined `RateLimit` header
    legacyHeaders: false, // Disable the `X-RateLimit-*` headers.
    // store: ... , // Redis, Memcached, etc. See below.
})

// Apply the rate limiting middleware to all requests.
app.use(limiter)

Data Stores

The rate limiter comes with a built-in memory store, and supports a variety of external data stores.

Configuration

All function options may be async…

View on GitHub

Através desta biblioteca, podemos configurar facilmente um middleware para o Express framework, conforme a própria documentação:

const rateLimit = require("express-rate-limit");

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100 // limit each IP to 100 requests per windowMs
});

//  apply to all requests
app.use(limiter);

De forma mais "automática", existem bibliotecas que fazem o bloqueio para você e aumentam o intervalo seguindo sequências, pré-determinadas, como a lib express-brute:

AdamPflug / express-brute

Brute-force protection middleware for express routes by rate limiting incoming requests

express-brute

A brute-force protection middleware for express routes that rate-limits incoming requests, increasing the delay with each request in a fibonacci-like sequence.

Installation

via npm:

  $ npm install express-brute

A Simple Example

var ExpressBrute = require('express-brute');

// stores state locally, don't use this in production
var store = new ExpressBrute.MemoryStore();
var bruteforce = new ExpressBrute(store);

app.post('/auth',
    bruteforce.prevent, // error 429 if we hit this route too often
    function (req, res, next) {
        res.send('Success!');
    }
);

Classes

ExpressBrute(store, options)

store An instance of ExpressBrute.MemoryStore or some other ExpressBrute store (see a list of known stores below).
options
- freeRetries The number of retries the user has before they need to start waiting (default: 2)
- minWait The initial wait time (in…

View on GitHub

var ExpressBrute = require('express-brute');

// stores state locally, don't use this in production - VEJA NOTA ABAIXO -
var store = new ExpressBrute.MemoryStore();
var bruteforce = new ExpressBrute(store);

app.post('/auth',
    bruteforce.prevent, // error 429 if we hit this route too often
    function (req, res, next) {
        res.send('Success!');
    }
);

O mesmo pode ser feito em demais tecnologias e frameworks, consulte a documentação da stack que você está utilizando! Veja as principais:

⚠️ Importante ⚠️

Independente da sua escolha, lembre-se que estas soluções devem funcionar bem em arquiteturas escaláveis, então se você configurar uma destas bibliotecas no modo "in-memory", todo o bloqueio de requisições funcionará de forma separada em cada nodo da arquitetura, ou seja, a requisição maliciosa X será bloqueada no servidor A mas não no servidor B. Por este motivo, a grande maioria destas bibliotecas oferecem a forma de configurá-las com um armazenamento compartilhado das informações (geralmente utilizando Redis ou memcached).

Conclusão

Monitore constantemente sua aplicação e seus servidores;
Ajuste seu software e sua arquitetura para, a qualquer momento (faça simulações!), bloquear ou intervalar requisições.

Questione "que ferramentas e técnicas a stack tecnológica me fornece para evitar DoS?". Então consulte as documentações e faça os devidos testes! Em termos de segurança de informação, a máxima prevenir é melhor que remediar vale muito.

A OWASP é uma comunidade muito valiosa em segurança de informação. É sempre muito importante estarmos atentos aos dados e relatórios periódicos que eles publicam! ↩
Para facilitar a didática e o exemplo, vamos assumir que o cálculo dessas métricas é feito em tempo real. Porém, muitos desses sistemas utilizam estruturas analíticas pré-calculadas. ↩

DevSecOps - Ataque de alteração de parâmetros da requisição

Bernardo Bosak de Rezende — Mon, 01 Jun 2020 17:44:35 +0000

Segurança para devs

Este post faz parte de uma coleção de posts sobre segurança de software ao longo do processo de desenvolvimento (DevSecOps). O tipo de vulnerabilidade abordado neste artigo é Alteração de parâmetros da requisição.

A tradução deste nome é livre, mas o termo mais comum, em inglês, é Parameter Tampering. Você pode conferir a documentação no catálogo da OWASP ¹.

Basicamente, Parameter Tampering consiste em qualquer tipo de exploração de segurança baseada em alterar as informações que uma aplicação cliente envia para o servidor (ex: uma requisição REST ou um formulário HTML), afim de obter resultados diferentes, como acessar informações de outros usuários ou alterar informações que, normalmente por restrições de UI, não seria possível.

Alguns exemplos do que pode ser feito com esse tipo de exploração:

Em um sistema com troca de mensagens instantâneas (chat), poder enviar uma mensagem se passando por outra pessoa (usuário X envia mensagem para usuário A como se fosse usuário B).
Em um sistema de vendas, poder alterar o valor do desconto de uma compra.
Em um sistema de rastreamento, poder acompanhar a entrega de um pedido de outra pessoa.

Por se tratar de uma gama bem ampla de ataques, vamos focar aqui nos problemas que podem ser resolvidos com design de APIs e um pouquinho de código. Para isso, vamos tomar a seguinte especificação de funcionalidade:

Como usuário de um ecommerce
E estando autenticado na área do cliente
Quando acessar "Meus Pedidos"
Então devo visualizar pedidos realizados apenas pelo mesmo usuário que está autenticado

Gosto desse exemplo, pois ilustra bem uma situação corriqueira em equipes de desenvolvimento: criar consultas de dados. Implementamos esse tipo de consulta a todo momento, por centenas de vezes e em muitos sistemas, mas nem sempre questionamos o nível de permissão de acesso à essas consultas.

Para atender a funcionalidade descrita acima, suponhamos a seguinte modelagem do servidor, seguindo a arquitetura REST:

GET /api/usuarios/{id}/pedidos
Authorization: token-do-usuario-id-{id}

Provavelmente a implementação em alto nível (Python)², para atender à esta rota, seria algo como:

@app.route('/usuarios/<int:id_usuario>/pedidos')
def pedidos_unsafe(id_usuario):
    token = decodificar_token(request)
    if not token['valido']:
        abort(401) # Unauthorized
    return consultar_pedidos(id_usuario)

Aparentemente, não há nada de errado com o código acima. A função decodificar_token interpreta o cabeçalho Authorization (enviado com a requisição), e confere se o token³ está válido (na grande maioria dos casos, essa validação consiste em verificar se o preenchimento do token está correto e se o mesmo não expirou ou foi invalidado - o que pode ser disparado por um evento de troca de senha, por exemplo -). Caso esteja válido, o sistema prossegue o fluxo, consultando (no banco de dados) pelos pedidos referentes ao id enviado na requisição.

Porém, além de não atender à especificação⁴, esta implementação expõe uma falha de segurança. Note que apesar de validarmos o token, não verificamos se o usuário relacionado aquele token é o mesmo usuário recebido no parâmetro da requisição. Aqui está a brecha para o Parameter Tampering, pois podemos enviar o token para o usuário 1 e ainda assim pedir os dados do usuário 2:

GET /api/usuarios/2/pedidos
Authorization: token-do-usuario-id-1

Uma forma simples de evitar esse exploit seria garantir que o usuário do token é o mesmo informado no parâmetro:

if token['id_usuario'] != id_usuario:
    abort(403) # Forbidden

Implementação completa:

@app.route('/usuarios/<int:id_usuario>/pedidos')
def pedidos_safe(id_usuario):
    token = decodificar_token(request)
    if not token['valido']:
        abort(401) # Unauthorized
    if token['id_usuario'] != id_usuario:
        abort(403) # Forbidden
    return consultar_pedidos(id_usuario)

Pronto! Agora as requisições que possuem o argumento id do usuário diferente do id do usuário vinculado ao token serão respondidas com um código de erro do servidor 403 (forbidden).

Podemos fazer duas simples evoluções:

Centralizar e unificar esta lógica de verificação de token x parâmetro de query, pois provavelmente muitas rotas terão essa brecha; e
Quando algum usuário tentar acessar informações que não são suas, registrar esta intenção para futuras auditorias.

Centralizando e unificando as regras de segurança

Para o item 1, podemos utilizar o padrão de projeto Decorator, presente nativamente em linguagens / frameworks como Python, Java e C# ou Higher-Order Functions para linguagens funcionais que ainda não possuem suporte a decorators (ex: JavaScript até junho de 2020), de forma que o código da solução se reduziria a:

@app.route('/usuarios/<int:id_usuario>/pedidos')
@garantir_mesmo_usuario(nome_argumento='id_usuario')
def pedidos_safe(id_usuario):
  return consultar_pedidos(id_usuario)

Neste caso, toda "mágica" fica por conta de garantir_mesmo_usuario⁵, uma função decoradora que nos permite executar código antes e depois da implementação que desejamos executar quando a rota for acionada por uma aplicação cliente (neste exemplo, consultar pedidos). Desta forma, conseguimos reduzir bastante o código e ainda reaproveitar esta lógica em outros pontos de alteração. A implementação do decorator pode ser conferida no link no final deste artigo.

Similarmente, poderíamos criar esse comportamento de verificar a segurança em uma função externa que "empacota" (wrapper) a implementação da consulta (exemplo para node.js express):

app.get('/usuarios/:idUsuario/pedidos',
  garantirMesmoUsuario(async (req, res) => {
      const { params: { idUsuario } } = req
      const pedidos = await consultarPedidos(idUsuario)
      res.send(pedidos)
    }
  )
)

Perceba que garantirMesmoUsuario é um função que recebe como argumento... uma outra função. Essa "outra função" é a implementação que desejamos executar quando a rota /usuarios/:idUsuario/pedidos for acionada com o método GET. Primeiro fazemos as verificações devidas de segurança, e aí invocamos a "outra função" em return func(req, res):

const garantirMesmoUsuario = func => (req, res) => {
  const token = decodificarToken(req)
  if (!token.valido) {
    return res.sendStatus(401)
  }
  const { params: { idUsuario } } = req
  // comparação estrita vai falhar se token.idUsuario for Number
  // e idUsuario for String
  if (token.idUsuario !== idUsuario) {
    return res.sendStatus(403)
  }
  return func(req, res)
}

Esta implementação funciona de forma muito similar aos mecanismos de middleware, presente em alguns frameworks para desenvolvimento Web, como Express e Django.

Registrando tentativas de acesso inadequado

Agora que temos toda estrutura de verificação centralizada, é fácil registrar as tentativas de acessos inadequados. Isso pode ser importante caso o software esteja sob tentativas de ataque ou se algum usuário teve suas credenciais comprometidas, permitindo ao sistema reagir corretamente a isso.

    if token['id_usuario'] != id_usuario:
+       registrar_tentativa(token, id_usuario)
        abort(403) # Forbidden

registrar_tentativa é uma função que pode gravar a tentativa no output do sistema (geralmente um stdout de terminal), em um algum arquivo de log transacional, em algum banco de dados gerenciado ou em um serviço especializado de processamento de logs de auditoria (AWS CloudTrail, ELK, Papertrail, etc).

Os detalhes de implementação desta função são, como o próprio termo diz, detalhes. O que importa é que seu sistema armazene estas informações e saiba reagir corretamente a essas tentativas de acesso. Por exemplo: enviar uma notificação para o usuário sobre o acesso inadequado e invalidar todos os tokens relacionados a ele.

"UX também é segurança!"

(Alguma pessoa lúcida, em algum momento lúcido)

Lembre-se: segurança de informação não é apenas sobre tecnologias, frameworks e padrões que inserimos no código e na arquitetura. É também sobre projetar fluxos e interações com o usuário final que garantam a máxima integridade de todos os dados que forem tratados no uso do software.

EDIT 1: essa vulnerabilidade de alterar o ID do recurso a ser consultado também é conhecida como BOLA (Broken Object Level Authorization) ou IDOR (Insecure Direct Object Reference) (créditos @jradesenv). Porém, Parameter Tampering permite outros tipos de explorações, como veremos a seguir.

Outras considerações

Nem sempre os parâmetros que podem ser alterados estarão na URL da requisição, é preciso cuidar os campos que podem ser enviados no corpo ou até mesmo os cabeçalhos. Exemplo:

POST /api/mensagens
Authentication: token-usuario-id-1

{
  "de": 2,
  "para": 3,
  "mensagem": "oi! pode me passar seu endereço?"
}

Se nada for feito no servidor (backend), é possível mandar mensagem do usuário 2 para 3 tendo apenas as credenciais do usuário 1, que pode ter sido criado simplesmente para executar algum ataque. Essa alteração de parâmetros acontece no campo de (id do usuário remetente).

Pode ser mais fácil explorar esta vulnerabilidade se os identificadores únicos dos usuários forem incrementais (ex: 1, 2, 3, ... 10401), facilitando a vida de quem for executar o ataque (ou até mesmo escrever um script para automatizar o exploit). Identificadores incrementais também podem trazer problemas de concorrência de escrita (embora nos últimos anos as tecnologias de banco de dados tenham evoluído bastante nesse aspecto). Prefira abordagens de identificação única com baixa previsibilidade, como UUID ou Hi/Lo!

Outra vulnerabilidade muito comum referente a Parameter Tempering é o acesso irrestrito a informações retirando parâmetros específicos (como um id de busca) e acessando todos registros de uma tabela (consulta mais ampla sem filtros), também conhecido como Broken Function Access Authorization, tomemos as seguintes especificações:

Funcionalidade: Detalhar pedido específico
Como usuário do ecommerce
E estando autenticado na área do cliente
Quando entrar em "Meus Pedidos" e escolher o pedido 1
Então deve abrir a tela com os detalhes do pedido 1

Funcionalidade: Listar todos pedidos
Como usuário administrador do ecommerce
E estando autenticado na área administrativa
Quando clicar no item "Todos os pedidos" do menu
Então devo visualizar todos os pedidos do ecommerce

Para a primeira funcionalidade, podemos assumir a seguinte API:

GET /api/pedidos/{id}
Authentication: token-do-usuario-{id}

Para a segunda funcionalidade:

GET /api/pedidos
Authentication: token-do-usuario-admin

Porém, se nada for feito, o usuário 1 (que não é administrador), poderá acessar /api/pedidos apenas retirando o id do pedido da URL, podendo então visualizar todos os pedidos. Ao criar Web APIs que vão expôr dados de forma ampla e com poucos filtros, questione quem deve poder acessar essas informações e faça os devidos ajustes, pois com um conhecimento básico de Web e protocolos de rede, é possível tentar acessar praticamente todos os dados que seu sistema "expõe" para as aplicações utilizarem.

Muitos frameworks Web já possuem mecanismos para auxiliar a autorização por diferentes papéis de usuários (Role Based Security), a exemplo dos decoradores de autorização do Django ou a anotação @Secured do Spring framework. Consulte a documentação das tecnologias que você usa antes de escrever manualmente esses filtros!

Conclusão

Esse tipo de vulnerabilidade nos parâmetros de requisições nem sempre é fácil de identificar e pode se manifestar de diferentes formas, mas elenco algumas práticas que podem ajudar na grande maioria dos casos:

Questionar, o quanto antes e de forma contínua, que tipo de papéis de usuário poderão acessar as informações que serão disponibilizadas. Refletir as respostas no desenho da solução.
Analisar todos os parâmetros que são trocados entre camada pública (cliente) e camada privada (servidor). Identificar quais desses parâmetros:
1. São utilizados para localizar registros que podem ser lidos ou alterados (ex: ids de busca). Questionar o quanto o usuário que está autenticado (seja por token, cookie, sessão, etc) pode alterar dos parâmetros destes parâmetros elencados.
2. Precisam ser re-validados (além da validação já realizada na camada de UI). Por exemplo, em um sistema com restrição de idade, é preciso garantir, no servidor, que o campo "data de nascimento" atende às regras exigidas, mesmo que essas já tenham sido impostas na camada de UI, pois em uma tentativa maliciosa esta informação pode ser alterada fora da aplicação cliente confiável.
Sempre que possível, preferir mecanismos de geração de identificadores únicos de baixa previsibilidade, como os já citados UUID ou Hi/Lo.
Desenvolva uma visão "caixa preta" e analise a sua API com uma perspectiva externa, sem detalhes de implementação. O que uma pessoa maliciosa poderia tentar fazer com as URLs e parâmetros públicos?
Principal: tente incutir as práticas e revisões de segurança de informação na cultura de desenvolvimento do time, de forma que isso seja diluído em preocupações e tarefas constantes e frequentes.

Segurança da informação também é qualidade de software!

A OWASP é uma comunidade muito valiosa em segurança de informação. É sempre muito importante estarmos atentos aos dados e relatórios periódicos que eles publicam! ↩
Por motivos didáticos e de brevidade, a implementação omite algumas definições de funções, rotas, servidor, etc. Se você quiser todos os detalhes, confira a implementação completa. ↩
Todos os exemplos podem ser interpretados com qualquer mecanismo de autenticação (token, cookie, session id, etc). Por ser uma das abordagens mais populares atualmente, utilizaremos ao longo do artigo a autenticação por token. ↩
É comum que as especificações (independente do formato) não contenham algumas preocupações básicas de segurança. Neste caso, o critério de aceite pode aparecer como "Então devo visualizar pedidos". Uma pessoa que trabalha com produtos digitais deve se preocupar com muitas coisas, então é completamente compreensível que alguns detalhes de segurança passem desapercebidos, por isso a importância da equipe de desenvolvimento se preocupar com infosec de uma forma iterativa ao longo das entregas (e não apenas no final dos projetos através de auditorias), revisando as especificações e fortalecendo uma cultura onde qualidade de software está diretamente relacionada à segurança de informação. ↩
Também por motivos didáticos e de brevidade, a função decoradora garantir_mesmo_usuario possui duas responsabilidades: 1) verificar se o token é válido; e 2) verificar se o usuário do token é o mesmo da requisição. Em termos de boas práticas e design de código, o mais correto seria "dividir" esta função em duas menores, onde cada qual possuiria sua responsabilidade única. ↩