Fuzz testing
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
434
On Slideshare
434
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Русского термина нет: fuzz – это пух. Можно провести такое сравнение: fuzz testing – это как человек, который пытается усидеть на скачущем быке. Скорость и амплитуда движений быка зависит от многих условий.
  • Черный ящик – мы ничего не знаем о системе: поис багов, сплойтов, падений системы Серый ящик - есть догадки о поведении: протоколы, форматы файлов Белый ящик – все знаем о системе: все выше перечисленное Рандомные данные: что будет с системой, если она будет получать “белый шум”? Правильные данные: корректно ли система обрабатывает множество различных наборов данных? Ошибочные данные: как система себя поведет в случае сбоя или некорректных данных?
  • В наиболее произвольном тесте найти все ссылки.
  • Казалось, бы просто выделить все части текста, начинающиеся на http:// Но есть множество форматов записи адреса, и приведенный список – только верхушка айсберга.
  • Читаем RFC – получаем регулярку 1. От 1-ого до 3-х внутренних доменов 2. Последний домен должен быть из списка TLD (Top-Level Domains) 3. Пути 4. Строка запроса 5. Хештег
  • Ну, это надо протестировать. Давай придумывать тесты: раз строка, два строка, умф, пойду покурю, 10 строка, ррррррррр, что же еще придумать.... 15 строка: я сдаюсь
  • В произвольное-произвольное место произвольной-произвольной строки вставляем произвольный-произвольный адрес. Пропускаем полученный текст через поиск адресов, вырезаем их – ничего не должно измениться.

Transcript

  • 1. Пример fuzz testing для поиска URL в тексте Николай Ходов (nkhodov@gmail.com)
  • 2. Fuzz testing
  • 3. Условное деление
  • 4. Задача● В произвольном тексте:● Найти все URLы
  • 5. Бесплотные попытки А как же вот это?! ● ya.ru ● It.s.bori.ng ● vk.com/durov ● Google.com/#plus-plus ● //st.domain.com/?q=1https?://(.*?) ● И еще миллионы вариантов...
  • 6. Пишем регулярку RFC 1738 +(https?://)?<domain>{1,3}.<TLD>(/<path>)*(?<query_string>?)(#<hashtag>?)?
  • 7. Тестируем вручную● self.assertEqual(strip_links(word1 https://ya.ru word2), word1 word2)● self.assertEqual(strip_links(word1 domain.arpa/test.link word2), word1 word2)● self.assertEqual(strip_links(word1 ya.ru/yandsearch? sdfsdfsdf=1fsdf word2), word1 word2)● self.assertEqual(strip_links(word1 naked.domain.asia word2), word1 word2)● …● На 15 строке мозг усиленно отказывается что-либо придумывать.
  • 8. Пусть тестирует сам компьютер!Fully Random URL Kwh89 ydhfj 09 u ><LAKSUy236 vТекст должен остаться неизменным
  • 9. Баги● Домены не могут начинаться на “-” (тире)● RFC не последняя инстанция (//)● Разные наборы символов для query string и для пути
  • 10. Надежность● Не дает 100%-покрытия на границах (где обычно все самое вкусное)● Не факт, что будут выявлены критичные баги● Но...● Вы можете прогнозировать поведение программы в стресс-режиме
  • 11. Применимость● Применим на стыках взаимодействия программ (форматы файлов, передача данных, внешние события)● Очень сильно помогает выявить на раннем этапе то, что может “завалить” программу в боевом режиме
  • 12. Вопросы?