How to Break Software

1. How to Break Software Capítulo 3 Taíse Dias Testing from the user Interface

2. Roteiro • Testando “dentro da caixa” • Explorando armazenamento de dados • Attcak 11 • Attack 12 • Attack 13 • Attack 14 • Attack 15 • Attack 16 • Attack 17

3. Testando “dentro da caixa” • Dados e computação (caixa branca) • Escopo do livro: caixa cinza • Abstrações do código • Baseado em interface com usuário, porém envolve dados e computação interna

4. Explorando armazenamento de dados • Dado é o “sangue” do software • Se corrompido, provoca danos trágicos • Dados são manipulados através de leitura e escrita pela aplicação • Tentar enxergar através da interface • Tentar encontrar que dados estão sendo carregados • Ex.: Se um dado entrou em uma tela, e o mesmo dado apareceu em outra tela, esse dado foi carregado

5. Attack 11 “Apply inputs using a variaty of inicial conditions”

6. Quando aplicar esse ataque? • Configurar pré-condições que causem bugs • Entradas são aplicadas em diversas circunstâncias • Ex.: um arquivo pode ser salvo contendo ou não alterações

7. Que falhas do software tornam esse ataque bem sucedido? • A computação funciona apenas sob determinadas condições • Entradas devem ser validadas • Estruturas de dados devem ser validadas • Combinação entre entradas e estruturas de dados

8. Como determinar se esse ataque revela falhas? • Melhor caso: combinações de entradas e estruturas de dados incompatíveis, o software trava • Pior caso: Poucas variações de saídas ou disposição/ordem da tela

9. Como conduzir esse ataque? • Isolar features ou funções • Considerar as possibilidades de dados usadas nessas features • Tentar particionar configurações dos dados que teriam o mesmo comportamento • Executar uma combinação pra cada partição

10. Attack 12 “Force a data structure to store too many or too few values”

11. Quando aplicar esse ataque? • Estruturas de dados conhecidas • ou identificando estruturas de dados: • Utilizando a aplicação • Imaginando como os desenvolvedores implementaram • Estruturas de tamanho fixo (limites)

12. Que falhas do software tornam esse ataque bem sucedido? • Desenvolvedores implementam estruturas de dados com cuidado mas esquecem dos limites • “AddElement” e “RemoveElement” sem checar • Provoca underflow e overflow

13. Como determinar se esse ataque revela falhas? • Leitura e escrita em fronteiras de arrays geralmente fecha o SO, prejudicando a aplicação • Dados corrompidos • Saídas incorretas

14. Como conduzir esse ataque? • Detectar os limites das estruturas de dados • Inserir números grandes como entradas (256, 1.024, 32.767) • Underflow – deletar mais elementos do que os que foram inserido

15. Attack 13 “Investigative alternative to modify internal data constraints”

16. Quando aplicar esse ataque? • Sempre que identificar qualquer restrição de carregamento de dado • Investigando todos os pontos de acesso para quaisquer restrições na estrutura de dados • Tamanho, dimensão, tipo, forma, localização na tela... • Qualquer propriedade da estrutura, que o usuário possa configurar

17. Que falhas do software tornam esse ataque bem sucedido? • Implementa casos para restrição na criação de dados • Não implementa casos para restrição na modificação dos dados • Dados manipulados por diferentes funções • Código para checar restrições deve ser incluído em toda as funções

18. Como determinar se esse ataque revela falhas? • Dados inválidos provocam travamento do sistema

19. Como conduzir esse ataque? • Identifica dados • Lista propriedades de mudança • Intervalos, tipos, condições de execução • Inicializa os dados e realiza modificações

20. Attack 14 “Experiment with invalid operand and operator combinations”

21. Quando aplicar esse ataque? • Computação envolvendo entradas e dados específicos • Computação operadores • Entradas e dados operandos • Combinar operandos/operadores para produzir falhas

22. Que falhas do software tornam esse ataque bem sucedido? • Quase todo operador possui operandos inválidos (ex.: divisão) • Alguns desenvolvedores se descuidam ao escrever casos de erros

23. Como determinar se esse ataque revela falhas? • Executar operações inválidas geralmente trava softwares • Se o exception handler mantém a aplicação funcionando, o dado está incorreto ou a mensagem de erro está ilegível

24. Como conduzir esse ataque? • Identificar onde a computação ocorre • Entender que dados são usados • Usar valores inválidos nas operações

25. Attack 15 “Force a function to call itself recursively”

26. Quando aplicar esse ataque? • Aplicações com funções recursivas • Número de chamadas ilimitadas • Loops infinitos

27. Que falhas do software tornam esse ataque bem sucedido? • Desenvolvedores geralmente falham ao tratar casos de recursão • Não garantem que loops e recursões terminarão • Verificação condicional no começo ou no fim do loop

28. Como determinar se esse ataque revela falhas? • Overflow no heap na memória do computador • Trava a aplicação

29. Como conduzir esse ataque? • Lista features que podem usar recursão • Força a utilização da recursão long int factorial (int n) { if( n <=1) return (1); else { return (n * factorial (n-1) ); }

30. Attack 16 “Force computation results to be too large or too small”

31. Quando aplicar esse ataque? • Objetivo é analisar os resultados da computação • Aplicações que produzem e carregam resultados internamente

32. Que falhas do software tornam esse ataque bem sucedido? • Entradas e dados corretos, mas resultados incorretos • Como? Depende da combinação • Desenvolvedores esquecem de checar limites dos resultados

33. Como determinar se esse ataque revela falhas? • Overflow e underflow • Desenvolvedores raramente escrevem exception handlers • Às vezes não compreendem como pode surgir falha uma vez que entradas e dados estão corretos

34. Como conduzir esse ataque? • Forçar ocorrência da computação várias vezes • Usar valores muito pequenos ou muito grandes const count = 2 main() { int sum, value[count]; sum = 0; for (int i = 0; i < count; ++i) { sum = sum + value[i]; } }

35. Attack 17 “Find features that share data or interact poorly”

36. Quando aplicar esse ataque? • Features compartilham dados • Sempre que uma aplicação executa mais de uma instrução ao mesmo tempo • Sempre que mais de uma feature é ativada ao mesmo tempo

37. Que falhas do software tornam esse ataque bem sucedido? • Uma feature produz um dado e outra feature o modifica • Restrições diferentes para o mesmo dado

38. Como determinar se esse ataque revela falhas? • Falhas sutis durante uso de entradas subseqüentes • Testador deve estar atento

39. Como conduzir esse ataque? • Verificar uso de entradas iguais para features diferentes • Verificar se saídas similares são produzidas pelas features • Verificar se uma feature interfere na computação de outra

40. Conclusão • Ataques relativos a dados e computação exigem que os testadores enxerguem através da interface com o usuário e imagine o que acontece • Em compensação, os que conseguem encontrão sérios bugs nos softwares analisados