View
110
Download
6
Category
Preview:
Citation preview
How to Break SoftwareCapítulo 3 Taíse DiasTesting from the user Interface
Roteiro Testando “dentro da caixa” Explorando armazenamento de
dados Attcak 11 Attack 12 Attack 13 Attack 14 Attack 15 Attack 16 Attack 17
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
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
Attack 11
“Apply inputs using a variaty of inicial conditions”
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
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
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
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
Attack 12
“Force a data structure to store too many or too few values”
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)
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
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
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
Attack 13
“Investigative alternative to modify internal data constraints”
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
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
Como determinar se esse ataque revela falhas?
Dados inválidos provocam travamento do sistema
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
Attack 14
“Experiment with invalid operand and operator combinations”
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
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
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
Como conduzir esse ataque?
Identificar onde a computação ocorre
Entender que dados são usados
Usar valores inválidos nas operações
Attack 15
“Force a function to call itself recursively”
Quando aplicar esse ataque?
Aplicações com funções recursivas
Número de chamadas ilimitadas
Loops infinitos
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
Como determinar se esse ataque revela falhas?
Overflow no heap na memória do computador
Trava a aplicação
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) );}
Attack 16
“Force computation results to be too large or too small”
Quando aplicar esse ataque?
Objetivo é analisar os resultados da computação
Aplicações que produzem e carregam resultados internamente
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
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
Como conduzir esse ataque? Forçar ocorrência da computação
várias vezes Usar valores muito pequenos ou
muito grandesconst count = 2main() {
int sum, value[count];sum = 0;for (int i = 0; i < count; ++i) {
sum = sum + value[i];}
}
Attack 17
“Find features that share data or interact poorly”
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
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
Como determinar se esse ataque revela falhas?
Falhas sutis durante uso de entradas subseqüentes
Testador deve estar atento
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
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
Recommended