Ir para o conteúdo

API8:2019 Injection

Agentes Ameaça/Vetores Ataque Falha Segurança Impactos
Específico da API : Abuso 3 Prevalência 2 : Deteção 3 Técnico 3 : Específico Negócio
Os atacantes fornecem à API dados maliciosos através dos vetores de injeção disponíveis (e.g., formulários, parâmetros, integrações, etc.), na expetativa que estes sejam enviados a um interpretador. Falhas de injeção são bastante comuns e são geralmente encontradas em consultas SQL, LDAP ou NoSQL, comandos enviados ao sistema operativo, parsers XML e ORM. Estas falhas são fáceis de identificar durante a revisão do código. Os atacantes podem fazer uso de scanners e fuzzers. As injeções podem conduzir à divulgação de informação e perda de dados. Podem ainda conduzir à negação de serviço (DoS) ou à tomada de controlo do host.

A API é vulnerável?

A API é vulnerável se:

  • Dados fornecidos pelo cliente não são validados, filtrados ou sanitizados pela API.
  • Dados fornecidos pelo cliente são concatenados diretamente em consultas SQL/NoSQL/LDAP, comandos a enviar ao sistema operativo, parsers XML e Object Relational Mapping (ORM)/Object Document Mapper (ODM).
  • Dados com origem em sistemas externos (e.g., sistemas integrados) não são validados, filtrados ou sanitizados pela API.

Exemplos de Cenários de Ataque

Cenário #1

O firmware dum dispositivo de controlo parental implementa o endpoint /api/CONFIG/restore, o qual espera que lhe seja enviado uma parâmetro appId no formato multipart. Com recurso a um descompilador, um atacante descobre que o parâmetro appId é passado diretamente numa chamada ao sistema sem qualquer tipo de sanitização:

snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d",
         "/mnt/shares/usr/bin/scripts/", appid, 66);
system(cmd);

O comando abaixo permite ao atacante desligar qualquer equipamento que corra o mesmo firmware vulnerável:

$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)'

Cenário #2

Perante uma aplicação de reservas com funcionalidades de criação, consulta, atualização e remoção, um atacante desconfia que talvez seja possível realizar injeções NoSQL através do parâmetro bookingId presente na query string dos pedidos de remoção. Este é o aspeto do pedido: DELETE /api/bookings?bookingId=678.

Esta é a função usada pelo servidor da API para atender tais pedidos:

router.delete('/bookings', async function (req, res, next) {
  try {
      const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId});
      res.status(200);
  } catch (err) {
     res.status(400).json({error: 'Unexpected error occured while processing a request'});
  }
});

O atacante interceta o pedido e altera o parâmetro bookingId na query string, conforme apresentado abaixo. Neste caso o atacante consegue apagar a reserva doutro utilizador.

DELETE /api/bookings?bookingId[$ne]=678

Como Prevenir

A prevenção de injeções exige que os dados sejam separados dos comandos e consultas.

  • Usar uma única biblioteca para validação de dados que seja confiável e ativamente mantida.
  • Validar, filtrar e sanitizar todos os dados fornecidos pelo cliente ou outros dados provenientes de sistemas integrados.
  • Caracteres especiais devem ser neutralizados com recurso à sintaxe específica do interpretador para onde serão enviados.
  • Opte por APIs de consulta seguras que oferecem interfaces parametrizadas.
  • Limite sempre o número de registos a devolver por forma a prevenir a divulgação massiva de dados em caso de injeção.
  • Valide os dados de entrada usando os filtros necessários para apenas permitir valores válidos para cada parâmetro.
  • Defina tipos de dados e padrões bem definidos para todos os parâmetros textuais.

Referências

OWASP

External