Все приложения можно условно разделить на «спринтеров» и «марафонцев». Спринтеров запускают редко и ненадолго — например, интернет-банк для проведения разовых операций. Марафонцы же включены у своих пользователей постоянно: текстовые редакторы, бухгалтерские программы, системы документооборота и т.д.
Если ваш продукт — марафонец, то вам просто необходимо тестирование надёжности (aka reliability testing). В рамках такого тестирования мы проверяем, как продукт ведёт себя при длительном использовании, не наблюдается ли утечек памяти, не растут ли используемые ресурсы, не возникают ли непредвиденные ошибки.
В своём докладе Олег расскажет, как проводить автоматизированное тестирование надёжности веб-приложений при помощи Selenium Web Driver.
По итогам этого доклада вы узнаете:
Какие критичные ошибки «марафонцев» можно пропустить, не уделяя достаточно внимания тестированию надёжности
Что такое утечки памяти, и почему растёт память браузера при длительном использовании продукта
Почему автоматизация тестирования — наиболее оправданное решение для тестирования надёжности
С чего начать автоматизацию reliability тестов, и как это лучше всего сделать.
Доклад будет полезен всем, кто занят тестированием регулярно и подолгу используемых программных продуктов.
Сегодня мы поговорим о тестировании безопасности веб-приложений. Сам я инженер по тестированию, по образованию – специалист по информационной безопасности, а по жизни – параноик.
В то время, когда я учился в университете, было не принято преподавать какие-то реальные вещи (читай – потребности отрасли), касающиеся защиты и компрометации информационных систем. Конечно, это можно было бы списать на бюрократию и сложности внедрения новых методик, но я думаю, что там, как и везде, просто больше любят бумажки – оттуда и безопасность у нас — «бумажная». В работе же необходимы практические навыки и знания.
1. СНАРУЖИ
Ни для кого не секрет, что количество сетевых атак неуклонно растет. Каждый день их совершается около 1000, подсчитать же их число за год практически невозможно (это наглядно видно из статьи Стива Моргана). Атакам подвергаются самые разные сетевые ресурсы – от сайта местного провайдера до федерального размера (агентурной) торговой сети суши и атомных станций. Можно даже посмотреть на интерактивную карту кибератак в режиме онлайн.
И каждый уязвим. И каждый отдает себе отчет об этом риске. И каждый думает, что это не про него. Что уж там душой кривить – мы так привыкли. Нежелание признавать риски приводит к нежелательным последствиям.
Давайте рассмотрим безопасность подробнее, ведь «в действительности все не так, как на самом деле» (с).
Тестирование на проникновение является одной из методик выявления областей системы, уязвимых для вторжения и компрометации целостности и достоверности со стороны неавторизованных и злонамеренных пользователей или сущностей. Процесс тестирования проникновения включает в себя умышленные санкционированные атаки на систему, способные выявить как ее наиболее слабые области, так и пробелы в защите от сторонних проникновений, и тем самым улучшить атрибуты безопасности.
Данная методика также может быть использована в качестве дополнения к другим методам проверки для оценки эффективности комплекса защиты системы от различных типов неожиданных вредоносных атак.
Есть ли разница между «security testing» и «penetration test»? С вопросом, ответ на который, как мне казалось, лежит на поверхности, я столкнулся на конференции для специалистов по тестированию Testing Stage в начале июня. И хотя выступал я с другой темой, именно этот момент вызвал интерес и резонанс публики. Для большей части моих коллег термины «security testing» и «penetration test» равнозначны. Так ли это на самом деле? Давайте разбираться!
В общем понимании «тестирование на проникновение» представляет собой продукт или услугу по санкционированной попытке обхода средств защиты информационной системы. Результатом теста является отчет, который может/должен содержать список обнаруженных уязвимостей, использованных векторов атаки, достигнутых результатов, рекомендаций по исправлению. Обращаю ваше внимание именно на термин «информационная система» в связи с тем, что это понятие включает в себя не только программное или аппаратное обеспечение, а также данные, персонал, организационные мероприятия, документацию и иные процессы. Т. е. результаты «пентеста» информационной системы зависят не только от качества и условий настройки и эксплуатации реализации программного обеспечения, а также от аналогичных метрик аппаратного обеспечения, корректности действий персонала, налаженности и согласованности операционных процессов и т. д. В то же время «security testing» — это итеративный процесс тестирования безопасности функционирования инфраструктуры в целом, который учитывает все этапы и контроли, и в этом случае «penetration test» — обязательный элемент общей модели «security testing».
Burp Suite – это платформа для проведения аудита безопасности веб-приложений. Содержит инструменты для составления карты веб-приложения, поиска файлов и папок, модификации запросов, фаззинга, подбора паролей и многое другое. Также существует магазин дополнений BApp store, содержащий дополнительные расширения, увеличивающие функционал приложения. Стоит отметить и появление в последнем релизе мобильного помощника для исследования безопасности мобильных приложений — MobileAssistant для платформы iOS.
Burp Suite — это интегрированная платформа, предназначенная для проведения аудита веб-приложения, как в ручном, так и в автоматических режимах. Содержит интуитивно понятный интерфейс со специально спроектированными табами, позволяющими улучшить и ускорить процесс атаки. Сам инструмент представляет из себя проксирующий механизм, перехватывающий и обрабатывающий все поступающие от браузера запросы. Имеется возможность установки сертификата burp для анализа https соединений.
Если посмотреть статистику и репорты bug-bounty программ — практически везде на скриншотах можно встретить использование этого инструмента. На ряду с OWASP ZAP это самый популярный набор утилит для тестирования веб-приложений.
Если недостатки ПО могут стоить миллионы долларов, очень полезно исследовать вопрос, почему так тяжело создать безопасное ПО.
Работа над безопасностью вся целиком связана с трудностями, и цель статьи – собрать наиболее специфические для приложений сложности, чтобы в последующих статьях предложить их решения. Она не направлена на защиту безопасников -мол, без ошибок сделать ПО никак нельзя.
Создание ПО – тяжелая работа
Безопасность ПО – это очень трудно, но даже правильное создание программного продукта – непростая задача. Поиск багов безопасности – это подкатегория поиска багов в ПО.
Программное обеспечение кардиостимулятора, спутника или линкора должно, возможно, быть идеальным в плане безопасности, но для большинства приложений самыми важными будут время до релиза, количество фич и другие подобные цели.
Мы знаем, что создать идеальное ПО возможно, но это очень трудно, и зачастую не в приоритете. Nasa и марсоход "Curiosity" – это пример оптимизированного соотношения качества к нулевому количеству багов, потому что стоимость бага в ПО крайне высока.
Каникулы закончились и многие великие хакеры пошли в школу. Значит ли это, что наше приложение может вздохнуть спокойно? Конечно, нет, ведь на очереди — осенние каникулы :)
Есть хорошее выражение: «Любое приложение может быть взломано. Любая атака может быть отражена». О чем это? Мы можем отразить любую атаку. Но если взломщик потратит больше времени и использует больше инструментов — он сможет взломать любое приложение.
Да, мы не можем избежать всего. Но мы можем обезопасить себя от «великих хакеров», сделав так, чтобы затрачиваемое ими время и количество используемых приложений возросло настолько, что уже не стоило полученного результата.
В ходе доклада мы научимся проводить элементарные проверки безопасности. И изучим способы, которыми от них можно защититься. Согласитесь, когда вас взломают Анонимусы, - это намного приятнее, чем когда каждый третьеклассник :)
В каких случаях может понадобиться тестирование безопасности?
Эта статья для тех, кому пришлось столкнуться с проблемами безопасности своих ресурсов, в первую очередь – корпоративной сети либо веб-приложений, но они не имеют четкого представления о том, как это тестирование осуществляется на практике.
Вариантов, разумеется, может быть множество, вот лишь некоторые из них:
после проведенной кибер-атаки либо ее попытки;
при наличии корпоративной сети или веб-приложения, тестирование безопасности которых проводилось давно либо не проводилось вообще;
после добавления новой функциональности в уже имеющийся продукт;
при значительном изменении топологии корпоративной сети;
при миграции приложения из тестовой среды в производственную;
при наличии требований отраслевых стандартов (PCI DSS, HIPAA).
Однако, определить насколько необходимо проведения тестов безопасности можно гораздо проще. В общем виде формула выглядит так: если у вас есть “что-то”, оно хранит либо обрабатывает важные данные и при этом доступно из Интернета, то тест безопасности необходим!
Если у вас произошел сбой программы, не думайте, что это просто сбой. Вполне вероятно, что некоторая часть так называемых сбоев – это приглашение для злоумышленника написать атакующий код. Не воспринимайте сбой как «просто сбой».
Прошла первая конференция ConfeT&QA, на которой я выступала с докладом про фаззинг. Очень много отзывов было примерно такого содержания: «Очень интересный доклад, но я совсем не знаю, что такое фаззинг».
Что же такое фаззинг и с чем его едят?
Фаззинг – это один из подвидов тестирования безопасности. Определений для него неимоверно много. Википедия определяет фаззинг как технологию тестирования программного обеспечения, когда вместо ожидаемых входных данных программе передаются случайные или специально сформированные данные. Т.е. программе чаще всего подсовываются заведомо неправильные данные, при этом отслеживаются такие ситуации, когда система не может их обработать и вылетает. Аварийное завершение работы считается нахождением дефекта в программе и может привести к дальнейшему выявлению уязвимости.
У нас этот вид тестирования еще не очень распространен, а на западе им пользуются уже достаточно давно. Еще в 1988 году Барт Миллер опубликовал работу The Fuzz Generator, в которой впервые был определен термин Fuzzing. А особо активное использование началось в 2006 году, когда при помощи фаззинга была найдена масса уязвимостей в Internet Explorer, Microsoft Word и Microsoft Excel. Сейчас фаззинг является одним из самых эффективных методов выявления проблем безопасности кода.
Выделяется три подхода к выявлению недостатков системы: тестирование методом черного, серого и белого ящиков. Различие между ними определяется теми ресурсами, которые доступны во время тестирования.
Сканнеры безопасности имеют широкое применение для анализа уязвимостей в локальных сетях на предмет устойчивости всей сети и отдельных компьютеров к вирусам, троянским программам и сетевым червям, а также направленным атакам злоумышленников. Одним из самых известных таких сканнеров является Tenable NeWT и snort.org. Но для анализа уязвимостей именно веб-сайта подобный инструмент не слишком хорош, поэтому существуют специальные сканнеры именно для анализа сайтов. Одной из лучших программ подобного рода является XSpider, разработка российской компании Positive Technologies.
Автор: Коллин Грин (Collin Greene)