Capítulo 3 — Programação I
Mapa da aula
Aula 03 publicada. Mapa, exemplo, EX007.
flowchart TD
N0["3.1 Propósito"]
N1["3.2 Padrões inseguros"]
N2["3.3 Sintético primeiro"]
N3["3.4 Revisão"]
N4["3.5 Determinismo"]
N5["3.6 Laboratórios do curso"]
N6["3.7 Nota aplicada"]
N7["3.8 Política de dados de teste"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX007"]
Desenho lógico
flowchart LR
N0["3.1 Propósito"]
N1["3.2 Padrões inseguros"]
N2["3.3 Sintético primeiro"]
N3["3.4 Revisão"]
N4["3.5 Determinismo"]
N5["3.6 Laboratórios do curso"]
N6["3.7 Nota aplicada"]
N7["3.8 Política de dados de teste"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX007"]
[3.1 Propósito]
|
v
[3.2 Padrões inseguros]
|
v
[3.3 Sintético primeiro]
|
v
[3.4 Revisão]
|
v
[3.5 Determinismo]
|
v
[3.6 Laboratórios do curso]
|
v
[3.7 Nota aplicada]
|
v
[3.8 Política de dados de teste]
|
v
[Exemplo resolvido] --> [Exercício EX007]
Objetivos de aprendizagem
Você vai (1) escrever pequenas ferramentas em Python para evidências offline; (2) recusar padrões inseguros; (3) testar ferramentas com dados sintéticos.
3.1 Propósito
Sam automatiza verificações de pertinência ao escopo, verificação de hashes e classificação de achados — nunca exploração. Cada verificação automatizada substitui uma etapa manual que as pessoas pulam quando estão cansadas: este endereço está na /26 assinada, este arquivo de evidência ainda corresponde ao hash registrado, quais achados abertos ficam mais alto por severidade e ativo? Nenhum desses scripts envia tráfego a um alvo. Manter a automação do lado seguro dessa linha significa que um bug no código de Sam pode rotular errado um relatório, mas não consegue alcançar o razão contábil nem o SWIFT.
3.2 Padrões inseguros
Sem segredos fixos no código, sem verificação TLS desativada, sem chamadas de shell não sanitizadas a scanners, sem novas tentativas sem limite. Cada regra corresponde a uma falha real: uma chave fixa no código acaba num repositório, a verificação TLS desativada esconde uma interceptação, um nome de host passado a um shell pode carregar comandos extras, e um laço de novas tentativas sem limite pode transformar uma verificação educada numa inundação contra um host frágil. A lista de revisão de Sam nomeia esses quatro, para que os revisores os procurem primeiro, e a CI rejeita os dois que podem ser detectados automaticamente antes que qualquer humano leia o código.
3.3 Sintético primeiro
Toda ferramenta roda em endereços de faixas de documentação e em arquivos falsos antes de qualquer janela de engajamento. Faixas de documentação como 198.51.100.0/24 não roteiam para hosts reais, então um erro durante o desenvolvimento não alcança nada. Sam roda toda ferramenta nova primeiro contra o escopo sintético do TRB, incluindo a exclusão do SWIFT em .20, e guarda as saídas como resultados esperados. Só quando essas saídas batem com as respostas calculadas à mão a ferramenta se torna elegível para uma janela de engajamento, e a aprovação cita a execução sintética pela data. Um pedido de aprovação sem uma execução sintética datada anexada é recusado, por mais urgente que seja a janela.
3.4 Revisão
Um segundo engenheiro lê os scripts de Sam em busca de erros no caminho do escopo. A primeira tarefa do revisor é rastrear todo caminho pelo qual um endereço entra no script e confirmar que ele passa pela verificação de pertinência do TrackScope antes do uso. Erros comuns incluem uma flag de depuração que pula a verificação, um segundo arquivo de entrada lido sem filtragem e uma lista de exclusões carregada depois dos alvos. O revisor assina a revisão no FindingsDesk, de modo que o registro mostra quem verificou qual versão e quando. Scripts não assinados não podem rodar numa janela.
3.5 Determinismo
Fixe a semente da aleatoriedade e as versões do interpretador para que as demonstrações do PulseMap sejam reproduzíveis. Uma demonstração do PulseMap que mostra números de cobertura diferentes em duas execuções não pode merecer a confiança de ninguém que esteja assistindo. Com uma semente fixa e uma versão de Python fixada, a mesma entrada sintética sempre produz os mesmos blocos, e um número alterado significa dados ou código alterados, não acaso. Sam registra a semente e a versão nas notas de cada demonstração, para que um revisor possa reproduzir depois exatamente a mesma tela e compará-la com a saída salva.
3.6 Laboratórios do curso
Os laboratórios deste livro seguem essas regras e incorporam saídas reais. Cada laboratório deste livro roda offline com a biblioteca padrão do Python 3, usa endereços de faixas de documentação e arquivos sintéticos e imprime uma saída capturada de uma execução real. Se a sua saída diferir da impressa, a diferença é informação: uma entrada alterada, um interpretador diferente ou um bug. Trate-a como Sam trata uma regressão do PulseMap, encontrando a causa antes de confiar em qualquer um dos resultados. Nenhum dos laboratórios precisa de acesso à rede, então eles podem rodar num notebook com a rede desligada.
3.7 Nota aplicada
A saída do dry-run é colada no canal do engajamento antes que qualquer modo de escrita rode. Os colegas têm dois minutos para objetar. Sam certa vez pegou um path traversal para dentro de um arquivo de evidências porque um colega leu o dry-run com cuidado. A revisão social vence a esperteza solitária em scripts operacionais. Dois minutos é curto o bastante para não atrasar uma janela e longo o bastante para um leitor cuidadoso. A saída colada lista todo endereço-alvo, o cartão de método e os caminhos de escrita que o script vai tocar, para que o leitor possa comparar cada linha com a /26 assinada e com a exclusão do SWIFT. A objeção de qualquer leitor pausa a execução até ser resolvida e anotada no log da janela.
3.8 Política de dados de teste
Clientes sintéticos nos fixtures usam documentos de identidade obviamente falsos. Sam rejeita fixtures que reutilizam números pessoais com aparência real, mesmo quando não são usados em produção. A transferência de hábito importa. Um fixture parecido com um número de identidade real pode ser copiado para um teste contra a produção por alguém com pressa. Valores obviamente falsos não podem ser confundidos com dados de clientes, e o hábito se estende a todo engajamento posterior. Um revisor que vê num fixture um número de identidade plausível pergunta de onde ele veio; um valor como FAKE-000-001 encerra a pergunta imediatamente e não pode ser confundido com um cliente durante um incidente.
3.9 Varredura de segredos na CI
Os repositórios da plataforma falham na CI se strings de alta entropia parecem chaves. Sam coloca na lista de permissão apenas fixtures de teste claramente marcados como FAKE. Uma chave de aparência real num arquivo de teste ainda treina as pessoas a ignorar o aviso; por isso, a marcação é obrigatória. Cada fixture permitido é listado com seu dono e o motivo pelo qual é seguro, e a lista é revisada sempre que as regras de CI mudam. Permitir pelo marcador, e não pelo caminho do arquivo, significa que uma chave real colada numa pasta de fixtures continua sendo pega. Quando a CI bloqueia um commit, o desenvolvedor rotaciona a string mesmo que ela só tenha existido localmente.
3.10 Quadro de trechos rejeitados
O quadro de revisão de scripts de Sam exibe três trechos rejeitados: uma chamada requests com verify=False, um subprocess com shell=True sobre um nome de host e um laço de novas tentativas sem jitter. Estagiários novos rubricam o quadro depois de lê-lo. O quadro é bobo e eficaz. Quando Sam quase cola verify=False "só em staging", ele vê as próprias iniciais e para. Cada trecho fica ao lado da versão segura: verify ligado com a CA interna do TRB, um subprocess chamado com uma lista de argumentos e um laço de novas tentativas com limite e backoff.
O quadro ganha um quarto exemplo sempre que a CI pega um novo antipadrão. Sam data cada trecho. Cada trecho novo traz uma nota de uma linha sobre o que a CI pegou e por que era perigoso, como uma nova tentativa sem limite contra um host lento. Pede-se aos estagiários que expliquem um trecho com as próprias palavras durante a primeira semana. A nota nomeia a regra, não a pessoa que escreveu o código. A equipe de Sam revisa o quadro todo ano e aposenta os trechos cuja regra de CI se tornou rotina.
Exemplo resolvido (TRB sintético)
O lab_scope.py de Sam usa apenas o módulo ipaddress da biblioteca padrão e faixas de documentação; ele nunca abre um socket.
Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.
Erros e limites
Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.
Exercícios
- EX007 — Regra do socket. Por que o lab_scope não pode abrir sockets? Rubrica: 3 = apenas offline/sintético; nenhuma varredura acidental; 2 = parcial; 1 = sockets não têm problema; 0 = nada.
- EX008 — Dois padrões inseguros. Nomeie dois padrões de script proibidos na equipe da plataforma. Rubrica: 3 = dois entre segredos, TLS desligado, shell não sanitizado, novas tentativas sem limite; 2 = um; 1 = vago; 0 = nada.
- EX009 — Segundo leitor. O que o segundo leitor procura? Rubrica: 3 = erros no caminho do escopo e segredos; 2 = um; 1 = só estilo; 0 = nada.
Síntese
Programar, aqui, significa automação segura, revisada e sintética primeiro.
Continue estudando — capítulo 03 de 40
← Capítulo 02 (rascunho) · Índice de capítulos do curso · Capítulo 04 (rascunho) →