Сообщений в теме: 4

[TShark]

Доброго времени суток,

Решил сменить профиль функционального тестирования на security после 4 лет работы. Вооружился литературой, изучаю OWASP Testing Guide v3 и O'Reilly Web Security Testing Cookbook, потренировался на WebGoat, но на интервью людей интересуют скорее общие вещи, описанные в Subj.

С чего начинать:
- анализ приложения
  - определить используемые технологии
  - определить сколько уровней
  - определить на какой стадии SDLC
- проанализировать, какие методики могут быть применены
  - ручное исследование и интервью
  - моделирование угроз
  - обзор исходного кода
  - тест на проникновение

Дальше пишем тест-кейсы, ранним и постим дефекты?
Как планировать-то? :(

[samurai08]

Доброго времени суток,

Решил сменить профиль функционального тестирования на security после 4 лет работы. Вооружился литературой, изучаю OWASP Testing Guide v3 и O'Reilly Web Security Testing Cookbook, потренировался на WebGoat, но на интервью людей интересуют скорее общие вещи, описанные в Subj.

С чего начинать:
- анализ приложения
  - определить используемые технологии
  - определить сколько уровней
  - определить на какой стадии SDLC
- проанализировать, какие методики могут быть применены
  - ручное исследование и интервью
  - моделирование угроз
  - обзор исходного кода
  - тест на проникновение

Дальше пишем тест-кейсы, ранним и постим дефекты?
Как планировать-то? :(

недавно готовил доклад про security testing ). В общем, все правильно написали, только надо понимать, что в каждом конкретном случае шаги разные. Веб приложения тестируются по одному методу, GUI приложения по другому.
Исходный код не всегда как бы доступен, поэтому надо использовать отладчик, дизассемблер чтобы проверить устойчивость приложения к взлому.
Есть куча утилит, которые можно использовать ), поэтому просто советую начинать изучать статьи, желательно на английском.

[lanishkas]

А на русском литературы нет? А то у меня с инглишем не сростается как то.

[owasp]

А на русском литературы нет? А то у меня с инглишем не сростается как то.

А на русском литературы много. Если интересуют электронные книги - то "Library Genesis" в помощь, ключевые слова: хакер, безопасность, взлом, защита (если не знаете адреса "Library Genesis", то поисковик в помощь). В качестве источника статей рекомендую журнал хакер, полезно, хотя бы для того, чтобы знать что означают очередные новые слова и в каком контексте их надо понимать. Так как читать английский текст всё равно придётся.

Кое-что пробовал делать сам. Вот моделирование угроз, к примеру, очень долгий процесс, меня хватило только на модель верхнего уровня и текствое описание всех угроз. Сделать многоуровневую модель, как в книге Защищенный код, не хватило терпения.

И про тест-кейсы. Не писал их до настоящего времени. Так как не мог предположить, что меня ждёт, будет ли доступен код, смогу ли я его расшифровать, ... Но сейчас попробовал с тест-кейсами. Строил тесты от возможных слабых мест (можно шагать от требований, от здравого смысла, а в безопаности можно от конкретных слабых мест - проверять есть оно или нет).
1. Открыл иерархию уязвимостей на http://cwe.mitre.org/
2. Выбрал те, которые могут быть (точно есть) в тестируемом приложении.
3. Описал их в документе, применительно к текущему контексту, и отправил его разработчикам (они почти ничего не вычеркнули)

Тесты получились не как пишутся обычно ("Корректная работа механизма ..."), а все заголовки написаны наоборот ("Ошибки механизма защиты"). Если почитаете Research View (http://cwe.mitre.org...raphs/1000.html) то поймёте почему так - там описаны возможные слабые места, я так и описал их в документе, как слабые места, а не как требования.

Что ещё замечу из опыта. Утилиты активного сканирования веб-приложений имеют очень низкий кпд. Гораздо больший толк от утилит пассивного сканирования, это когда, тестируешь веб-приложение, а трафик который генерируется для твоих ручных действий, проходит через сканер, который следит - не нарушиась ли структура html-разметки, и не попали ли значения из URL в текст страницы без изменений.

Из опыта тестирования не веб-приложений замечу следующее. Много уязвимостей в архиектуре ПО, и их никто не собирается исправлять, никто не знает об уязвимостях, потому что никому не говорят как это ПО работает. И чтобы выявить такие уязвимости, надо быть не просто тестировщиком, а опытным разработчиком, который пришел в тестирование, а конкретно в тестирование безопасности. Поэтому книги по разработке, такие как Совершенный код и многие другие, также надо будет прочесть.

Про планирование - война план покажет. Не планируйте пока ничего, перед Вами открылось непаханное поле. Если Вы - тестировщик конкретной фирмы, то просто найдите как можно больше уязвимостей (простых XSS, SQL-inj и того, что при том можно получить - доводите уязвимость до эксплуатации, на деле, не все они эксплуатируемы, и оттого некритичны), потом перейдите к сложным, архитектурным дефектам. А уже когда набьете руку в эксплуатции, можно и за pentest взяться (это же сложная задача, вот так просто - как одну очередную фазу тестирования, pentest не осилить). OWASP Testing Guide v3 можно считать руководством по пентесту. Но если ознакомиться со всем тем, что проверяется при пентесте (например, тут: http://www.pentest-s...x.php/Main_Page), то станет понятно: пентест - задача сложная.

[Breetonia]

Хах,а если речь идет о фреймворке+extjs? это уже взлом фреймворка выходит )