◇ OpenCyber Academy
Graduação · Capítulo 3 · Português

Capítulo 3 — Programação I

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 3 — Programação I

Mapa da aula

Aula 03 publicada. Mapa, exemplo, EX007.

flowchart TD
  N0["3.1 Processar registros"]
  N1["3.2 Allow-lists em vez de block-lists"]
  N2["3.3 Segredos fora do código"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX007"]

Desenho lógico

flowchart LR
  N0["3.1 Processar registros"]
  N1["3.2 Allow-lists em vez de block-lists"]
  N2["3.3 Segredos fora do código"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX007"]

[3.1 Processar registros]
    |
    v
[3.2 Allow-lists em vez de block-lists]
    |
    v
[3.3 Segredos fora do código]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX007]

Objetivos de aprendizagem

Você vai (1) escrever programas simples em Python que processam registros com segurança; (2) validar entradas com allow-lists; (3) evitar segredos fixos no código.

3.1 Processar registros

Os primeiros programas de Lucas leem registros de pedidos de arquivos CSV sintéticos e calculam totais. O Dr. Bellini acrescenta uma lente de segurança desde o início: toda entrada é não confiável até ser verificada. Lucas escreve funções que verificam cada campo: os identificadores de pedido precisam corresponder a um padrão fixo, as quantidades precisam ser inteiros positivos abaixo de um limite e os códigos postais precisam corresponder a um formato permitido. Os registros que falham são separados com um motivo. Os hábitos de programação formados no primeiro ano duram, então o curso trata a validação como parte da programação correta, e não como um tema avançado de segurança acrescentado depois.

3.2 Allow-lists em vez de block-lists

Lucas primeiro tenta bloquear caracteres perigosos nos nomes de produtos. O Dr. Bellini lhe mostra que as block-lists são sempre incompletas: há muitas maneiras de codificar uma entrada perigosa. Uma allow-list, que descreve como é uma entrada válida, é mais segura: os nomes de produtos podem conter letras, dígitos, espaços e alguns sinais de pontuação, até sessenta caracteres. Qualquer outra coisa é rejeitada. Lucas reescreve suas verificações desse jeito e acha o código mais curto e mais claro. O princípio se aplica em qualquer escala, de um único campo até as regras de firewall, em que permitir os fluxos sabidamente bons é mais seguro do que bloquear os sabidamente ruins.

3.3 Segredos fora do código

O programa de Lucas precisa chamar um serviço de estoque sintético com uma API key. Sua primeira versão escreve a chave no arquivo-fonte. O Dr. Bellini explica que o código-fonte é copiado, compartilhado e muitas vezes publicado por engano, então chaves no código vazam. Lucas move a chave para uma variável de ambiente lida em tempo de execução e acrescenta o arquivo de configuração à lista de arquivos ignorados do seu sistema de controle de versão. Ele também aprende que, se uma chave chegar a ser commitada, removê-la do arquivo não basta; ela precisa ser revogada e substituída, porque podem existir cópias do histórico.

Exemplo resolvido

Lucas escreve um verificador de registros de pedidos com validação por allow-list e move uma API key do código-fonte para uma variável de ambiente.

Caso sintético. Os registros, os serviços e as chaves são sintéticos.

Erros e limites

Allow-lists podem rejeitar entradas válidas incomuns, como nomes com acentos, se não forem projetadas com cuidado. Variáveis de ambiente não são uma solução completa de gestão de segredos.

Exercícios

Síntese

A programação segura começa por validar cada entrada em relação ao que é permitido e por manter os segredos fora do código.

Continue estudando — aula 03 (capítulo 03 de 40)

← Capítulo 02 · Índice das aulas · Capítulo 04 →

Continue para a próxima aula já escrita.