Статическое тестирование безопасности опенсорсными инструментами / хабр

Какие навыки и знания необходимы тестировщику безопасности ПО

Развиваться в области безопасности ПО без базовых технических знаний практически невозможно.

С чего начать в этой сфере IT? С освоения основополагающих для тестировщика знаний:

этапы разработки программного обеспечения;
типы дефектов и их жизненный цикл;
виды и правила составления тестовой документации;
подходы к тестированию и его уровни.

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

типы кибератак;
особенности server-side- и client-side-уязвимостей;
методики анализа защищённости;
и многие другие.

Кроме того, тестировщику безопасности будет полезно иметь представление о следующих нюансах:

основы криптографии и подходы к шифрованию информации;
некоторые аспекты сетевых технологий (модель OSI, маршрутизация пакетов в сети и т. д.);
основы SQL и Javascript, языка разметки HTML.

Если же у вас не так много времени на самостоятельное обучение или вы планируете перейти в сферу тестирования из области, не связанной с IT, то стоит пойти на курсы тестировщиков безопасности ПО.

Как тестировать ПО на безопасность?

Приведем примеры тестирования ПО на предмет уязвимости в системе безопасности. Для этого Вам необходимо проверить Ваше программное обеспечение на наличия известных видов уязвимостей:

XSS (Cross-Site Scripting)

Сами по себе XSS атаки могут быть очень разнообразными. Злоумышленники могут попытаться украсть ваши куки, перенаправить вас на сайт, где произойдет более серьезная атака, загрузить в память какой-либо вредоносный объект и т.д., всего навсего разместив вредоносный скрипт у вас на сайте. Как пример, можно рассмотреть следующий скрипт, выводящий на экран ваши куки:

либо скрипт делающий редирект на зараженную страницу:

либо создающий вредоносный объект с вирусом и т.п.:

XSRF / CSRF (Request Forgery)

Наиболее частыми CSRF атаками являются атаки использующие HTML <IMG> тэг или Javascript объект image. Чаще всего атакующий добавляет необходимый код в электронное письмо или выкладывает на веб-сайт, таким образом, что при загрузке страницы осуществляется запрос, выполняющий вредоносный код. Примеры:

IMG SRC

SCRIPT SRC

Javascript объект Image

<script>
           var foo = new Image();
           foo.src = "http://hacker_site/?command";
</script>

Code injections (SQL, PHP, ASP и т.д.)

Вставки исполняемого кода рассмотрим на примере кода SQL.

Форма входа в систему имеет 2 поля — имя и пароль. Обработка происходит в базе данных через выполнение SQL запроса:

SELECT Username
FROM Users
WHERE Name = 'tester'
AND Password = 'testpass';

Вводим корректное имя ’tester’, а в поле пароль вводим строку:

testpass’ OR ‘1’=’1

В итоге, Если поле не имеет соответствующих валидаций или обработчиков данных, может вскрыться уязвимость, позволяющая зайти в защищенную паролем систему, т.к.SQL запрос примет следующий вид:

SELECT Username
FROM Users
WHERE Name = 'tester'
AND Password = 'testpass' OR '1'='1';

Условие ‘1’=’1′ всегда будет истинным и поэтому SQL запрос всегда будет возвращать много значений.

Server-Side Includes (SSI) Injection

В зависимости от типа операционной системы команды могут быть разными, как пример рассмотрим команду, которая выводит на экран список файлов в OS Linux:

< !—#exec cmd=»ls» —>

Authorization Bypass

Пользователь А может получить доступ к документам пользователя Б. Допустим, есть реализация, где при просмотре своего профиля, содержащего конфеденциальную информацию, в URL страницы передается userID, а данном случае есть смысл попробовать подставить вместо своего userID номер другого пользователя. И если вы увидите его данные, значит вы нашли дефект.

Функциональное тестирование

Что проверяем?

Тестирование форм
1. Регистрация
  1. Пользователь с данными существует в системе.
  2. Пользователь с данными не существует в системе.
  3. Пользователь, заблокированный в системе, не может пройти повторную регистрацию.
2. Авторизация
  1. Пользователь существует в системе с введенным логином и паролем.
  2. Пользователь с введенным логином не существует в системе.
  3. Пользователь с введенным логином существует в системе, но пароль неверный.
  4. Пользователь с введенным логином и паролем существует в системе, но заблокирован модерацией (страница заморожена).
  5. Валидация полей ввода.
3. Протестируйте валидацию всех обязательных полей
  1. Максимальная и минимальная длина.
  2. Диапазон допустимых символов, спецсимволы.
  3. Обязательность к заполнению.
  4. Убедитесь, что астериск (знак звездочки) отображается у всех обязательных полей.
  5. Убедитесь, что система не отображает окно ошибки при незаполненных необязательных полях.
4. Формы обратной связи
5. Ссылки на пользовательские соглашения
Поиск
1. Результаты существуют/не существуют.
2. Корректное сообщение о пустом результате.
3. Пустой поисковой запрос.
4. Поиск по эмодзи.
Поля
1. Числовые поля: они не должны принимать буквы, в этом случае должно отображаться соответствующее сообщение об ошибке.
2. Дробные значения, например, как система валидирует 1.1 и 1,1.
3. Отрицательные значения в числовых полях, если они разрешены.
4. Деление на ноль корректно обрабатывается.
5. Протестируйте максимальную длину каждого поля, чтобы убедиться, что данные не обрезаются или скрываются под многоточие.
6. Протестируйте все поля ввода на спецсимволы.
7. Проверить что текст не выезжает за границы поля.
Всплывающие сообщения
1. Протестируйте всплывающие сообщения («Это поле ограничено N знаками»).
2. Подтверждающие сообщения отображается для операций обновления и удаления.
3. Сообщения об ошибках ввода.
Фильтры
1. Протестируйте функциональность сортировки (по возрастанию, по убыванию, по новизне).
2. Задать фильтры с выдачей.
3. Задать фильтры, по которым нет выдачи.
4. Фильтры по категориям/подкатегориям.
5. Фильтры с радиусом поиска.
6. Данные в выпадающих списках.
Протестируйте функциональность доступных кнопок.
Наличие favicon.
Проверка обработки различных ошибок (страница не найдена, тайм-аут, ошибка сервера и т.д.).
Протестируйте, что все загруженные документы правильно открываются.
Пользователь может скачать/прикрепить/загрузить файлы/медиа (картинки, видео и т.д.). А также удалить эти файлы из вложений. Убедитесь, что файлы уходят на сервер только после нажатия соответствующей кнопки
Протестируйте почтовую функциональность системы.
Кеш, cookie и сессии
1. Пользователь очистил кэш браузера
2. Посмотрите, что будет, если пользователь удалит куки, находясь на сайте.
3. Посмотрите, что будет, если пользователь удалит куки после посещения сайта.
DevTools
1. Ошибки в Console.
2. Все стили загружаются.
3. Картинки загружаются.

Основные этапы пентестинга

Чаще всего пентестинг проводят по методу «черного ящика», поэтому именно на этом примере мы проследим этапы работы этичного хакера.

Постановка цели тестирования

Тестирование безопасности проводится только после подписания договора с заказчиком, иначе проверку информационной безопасности могут принять за попытку взлома. Этичный хакер согласовывает с заказчиком цель пентестинга, например, ограничится ли проверка поиском уязвимостей или потребуется проникновение и захват контроля над приложением

Действия пентестера могут привести к сбоям в работе проверяемой инфраструктуры, поэтому важно предупредить клиента о возможных рисках и определить ограничения для тестирования

Предварительный сбор информации, или разведка

Сканирование уязвимостей

Тестировщик автоматизирует первый этап поиска уязвимостей с помощью программ-сканеров. Один из самых популярных инструментов – Nessus, который после сканирования автоматически формирует список обнаруженных уязвимостей. Сканеры ищут проблемы в информационной защите по определенным базам уязвимостей, например, CVE (Common Vulnerabilities and Exposures) или Vulners, поэтому тестировщики обычно используют несколько программ.

Ручная проверка уязвимостей

Пентестер дополнительно проводит ручное тестирование, потому что программы-сканеры могут пропустить некоторые уязвимости или, наоборот, обнаружить несуществующие.

Эксплуатация уязвимостей

Чтобы попытаться проникнуть в систему через уязвимость, пентестер использует эксплойты (программы или фрагменты вредоносного кода). На этом этапе работы чаще всего применяется фрейморк Metasploit, который позволяет подбирать или создавать эксплойты под разные виды уязвимостей.

Анализ результатов тестирования и составление отчета

Пентестер анализирует все этапы тестирования, чтобы оценить уровень защищенности проверяемых объектов. Результаты своей работы он отражает в отчете для заказчика. Этот документ, как правило, содержит список уязвимостей, степень их критичности и рекомендации по устранению.

Проверка № 5. Анализ событий

В «Гарда БД» предустановлен набор отчетов с информацией по количеству запросов и объему ответов, неудачным авторизациям, ошибкам в запросах и т. д. Графические отчеты интуитивно понятные. Собственноручная настройка отчетов с графическим представлением не вызвала у нас каких-либо сложностей.

Отчеты позволили провести быстрый анализ событий на предмет поиска логинов с неуспешными попытками аутентификации:

Обнаруженные события отображаются таблицей, можно просмотреть каждый объект. Над таблицей расположены фильтры, соответствующие параметрам SQL-запроса (IP-адрес, логин пользователя, наименование запрашиваемых таблиц и полей, объем ответа и количество строк в ответе, тип SQL-операции и другие), с помощью которых могут быть отобраны интересующие данные для атрибутивного поиска.

Контентный поиск мы успешно провели, анализируя события по признаку наличия ключевых слов и регулярных выражений в тексте запроса, ответа, переменной или сообщении об ошибке (при некорректном запросе).

Порадовало, что в продукте виден полный синтаксис отправленного к БД запроса и возвращаемые ответы:

Принципы безопасности программного обеспечения

Общая стратегия безопасности основывается на трех основных принципах:

конфиденциальность
целостность
доступность

Конфиденциальность

Конфиденциальность — это сокрытие определенных ресурсов или информации. Под конфиденциальностью можно понимать ограничение доступа к ресурсу некоторой категории пользователей, или другими словами, при каких условиях пользователь авторизован получить доступ к данному ресурсу.

Целостность

Существует два основных критерия при определении понятия целостности:

Доверие. Ожидается, что ресурс будет изменен только соответствующим способом определенной группой пользователей.

Повреждение и восстановление

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

Доступность

Доступность представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс тем выше уровень доступности должен быть.

Предисловие

Очевидным способом автоматизировать тестирование безопасности веб приложений является использования сканеров уязвимостей, например OWASP ZAP или Accunetix.
Такие сканеры применяют фаззинг, что сопряжено с рядом проблем:

Наблюдается комбинаторный взрыв количества запросов, выполняемых в ходе тестирования: умножаем количество параметров в приложении на размер списка значений для фаззинга и получаем нагрузку, которую может выдержать не каждая тестовая инфраструктура;
Фаззер не запоминает состояние приложения и не учитывает логику его работы, и поэтому некоторые уязвимости пропускает;
При добавлении в приложение новых форм, страниц, API требуется дополнительно обучать сканер.

В сложной системе всё это осложняет процесс тестирования безопасности, и мы обратились к статическому анализу.

Что нам было нужно?

Дешёвое масштабирование: автоматизированный инструмент, который можно запускать часто, на большом количестве приложений, и это не будет требовать значительного количества ручного труда;
Возможность воспользоваться уже существующими у нас знаниями о ранее найденных уязвимостях (если мы какие-то баги уже исправили, то было бы неплохо найти все похожие);
Способ искать уязвимости не только в вебе, но и в мобильных приложениях.

С таким списком ожиданий мы попробовали внедрить у себя статический анализ.

Но прежде чем перейти к рассказу об этом посмотрим, как статический анализ может использоваться для поиска уязвимостей и насколько это укладывается в вышеперечисленные пожелания.

Как понять, что ваши данные в опасности

Если хакеру удастся угнать cookie пользователя, то он сможет действовать от его лица или же просто получит конфиденциальную информацию юзера. Как узнать, всё ли впорядке?

Во-первых, нужно проверить, не хранятся ли пароли от сайтов в cookie. Удивительно, но в 2021 году до сих пор существуют сайты, которые это делают. Информация о сессиях должна иметь ограничения — быть временной или заменяться с каждой новой сессией.

Во-вторых, нужно проверить, чтобы все конфиденциальные cookie были с флагом httpOnly и secure.

Cookie с флагом “secure” передаются на сервер только по протоколу HTTPS. Как правило, в этом случае есть сертификат SSL или TLS. Cookie с флагом “httpOnly” защищены от манипуляции JavaScript через документ, где хранятся cookie.

Открываем в Chrome «инструменты разработчика» и переходим во вкладку Application.

Проверяем, не хранятся ли пароли в LocalStorage в этом же разделе «инструментов разработчика».

Теперь рассмотрим сценарии кражи пользовательских данных и как от них защититься.

Как проверить безопасность приложения?

Безопасность предприятия основана на тестировании безопасности приложений. Прежде чем развернуть приложение и начать его регулярное использование, в нем не должно быть ошибок и сбоев. После запуска приложения могут быть недостатки, но вы должны использовать инструменты и процедуры тестирования безопасности, чтобы найти уязвимости.

Вы можете протестировать безопасность приложения, приняв безопасный жизненный цикл разработки программного обеспечения (SDLC). Безопасный SDLC — это наиболее эффективный подход к внедрению и оценке безопасности на этапах подготовки и завершения производства.

Безопасное тестирование безопасности SDLC основано на следующих основных шагах:

1. Сбор и анализ требований

На этом этапе группа безопасности встречается с командой проекта, чтобы определить системные требования. Группа безопасности также проанализирует требования для поиска любых потенциальных угроз безопасности.

2. Дизайн и разработка

На этом этапе группа безопасности работает с разработчиками над созданием безопасной системы, отвечающей установленным требованиям.

требования. Функции безопасности встроены в систему, а тесты безопасности выполняются для кода.

3. Проверка и проверка

На этом этапе группа безопасности работает с группой обеспечения качества (QA), чтобы убедиться, что приложение соответствует всем требованиям и не содержит дефектов. На этом этапе также выполняются тесты безопасности.

4. Развертывание и операции

На этом этапе приложение запускается в производство, и проводится мониторинг безопасности для выявления любых новых уязвимостей.

5. Отставка

Когда приложение больше не используется, оно удаляется, и группа безопасности проводит окончательную оценку, чтобы убедиться, что все уязвимости были выявлены и устранены.

Выбираем статический анализатор

Статических анализаторов для Java много: есть и проекты в опенсорс, и коммерческие продукты. Нужно определиться с требованиями к инструменту. Вот такие пожелания сформулировали мы:

Первое очевидно: поддержка тех технологий, которые мы используем. В Одноклассниках мы пишем на Java, у нас есть JavaScript и TypeScript, а ещё мы хотим сканировать мобильные приложения, поэтому нужна поддержка Android-а.
Второе: мы однозначно хотим taint analysis. Как мы только что выяснили, эта штука нужна, чтобы находить инъекции и подобные им баги, а они составляют значительную часть всех проблем.
Мы поняли, что не ограничимся набором стандартных правил, потому что в нашем коде есть конструкции, которые статический анализатор «из коробки» не понимает, возможность кастомизации правил нам важна.
Хотим, чтобы у разработчиков была единая «точка правды» про наш статический анализ: чтобы все использовали одну и ту же версию правил, знали статус сканирования на данный момент, видели какие из найденных ошибок являются ложными срабатываниями, а какие настоящими багами. В общем, нам нужен collaboration сервер.
Наконец, мы хотим, чтобы добавление двух строчек кода в наш проект не повлекло необходимость переделывать всё. Если мы уже разобрали результаты сканирования на настоящие баги и ложные срабатывания, то следующее сканирование с небольшими изменениями позволяло бы переиспользовать предыдущие результаты.

В открытом доступе можно найти исследования, сравнивающие различные статические анализаторы. Посмотрим на одно из них, сделанное проектом OWASP (Open Web Application Security Project) в 2016-м (https://github.com/OWASP/benchmark). OWASP написал бенчмарк — приложение на Java с уязвимостями в заранее известных местах и просканировал его несколькими сканерами. Результат ниже:

Диаграмму не назвать интуитивно понятной, но разберёмся, что здесь изображено. Красная пунктирная линия — это результат, соответствующий случайному угадыванию. Все, что выше этой линии — лучше.

Также диаграмме можно заметить взаимосвязь между полнотой (сколько из всех багов было найдено) и точностью (сколько из найденного действительно является багами) анализатора. Сканеры с меньшим количеством ложных срабатываний пропускали больше багов.

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

Также OWASP протестировал один и тот же сканер Find Security Bugs с разными наборами правил, и в этом случае видно, что чем больше правил, тем больше уязвимостей обнаруживается. То есть добавление правил очевидно приносит результат.

Какой вывод мы можем сделать? Вероятно, выбор движка в статическом анализаторе не так важен для нас, как мощность набора правил и возможность дописывать детекторы под свои нужды.

Мы решили использовать опенсорсный Find Security Bugs. Это плагин для всем известного статического анализатора для Java, который раньше назывался FindBugs, а теперь называется SpotBugs. Find Security Bugs добавляет разнообразные детекторы, связанные с безопасностью, в том числе и для Android.

Также это единственный опенсорсный анализатор для Java, позволяющий добавлять свои правила taint analysis.

Всё, что связано с коллаборацией, с работой внутри команды и с серверной частью нашего инструмента, отдано SonarQube. У Find Security Bugs есть плагин для SonarQube, позволяющий загружать отчеты на сервер и управлять результатами сканирования.

Что из себя представляет WSTG?

За более чем 20 лет своей работы OWASP накопил огромный багаж знаний в области безопасности приложений. Результат — Web Security Testing Guide (WSTG) — Руководство по тестированию безопасности web-приложений, с которым может свободно ознакомиться каждый. В нём описываются приёмы, методики, инструменты и ресурсы для тестирования наиболее распространённых уязвимостей web-приложений.Текущая версия WSTG — 4.2. Также доступны материалы для будущей версии 5.0, которая в настоящее время разрабатывается и постоянно обновляется. Надо сказать, что это не первая попытка перевода, но полной версии WSTG я в свободном доступе не нашёл, решил взяться за текущую, актуальную на 2022 г. (latest).

XSS

XSS расшифровывается как “Cross-Site Scripting”. Эта уязвимость входит в список . Её смысл в том, что злоумышленник принудительно внедряет JavaScript-код через инпут на сайте: в поле ввода «пушит» код, который сохраняется на странице. Впредь он будет исполняться каждый раз при вызове страницы. Это происходит потому, что на сайте отсутствует экранирование спец символов.

У хакера много вариантов воспользоваться этой уязвимостью: от отображения алерта (всплывающего окна) с рекламой до кражи cookie и редиректа на сайт-зеркало.

Не забывайте, что проверять наличие уязвимостей на чужом сайте по законодательству РФ (и многих других стран) запрещено. Это воспринимается, как попытка намеренного причинение вреда сайту. И что тогда делать?

Первым делом вводим в инпуты на сайте скрипты например . Если уязвимость есть, то при перезагрузке страницы появится алерт со значением «test».

После этого вводим в инпуты строку:

Это универсальная проверка сразу на несколько кейсов. Если часть символов исчезла (например, в поле поиска) или не записалась в БД (если это поле имени пользователя при регистрации, например), то уязвимость есть. Все символы не должны восприниматься, как часть исполняемого поля. Если часть символов исчезла (например, в поле поиска) или не записалась в БД (если это поле имени пользователя при регистрации, например), то уязвимость есть. Все символы не должны восприниматься, как часть исполняемого поля.

В конце вводим скрипт или спецсимволы в окно фронтенда — вставляем прям в код сайта через dev tools в браузере.

Андрей Рыжкин и Алексей Клинов из AGIMA — о том, как и зачем контролировать безопасность приложений в заказной разработке

Персональные данные сотрудников и клиентов.
Данные доступа в банк-клиент.
Данные о клиентах компании.
Производственные чертежи.
Проектная документация.
И др.

Как организовать процесс тестирования на уязвимости?

Полная интеграция в процессе разработки CI/CD.
Ревизия безопасности на контрольных точках.
Ситуационная или разовая ревизия безопасности.

Сокращение репутационных рисков как для разработчика, так и для заказчика.
Снижение стоимости устранения уязвимостей в процессе эксплуатации приложения.
Уменьшение количества независимых проверок приложения на безопасность.

Выбираем статический анализатор

Первое очевидно: поддержка тех технологий, которые мы используем. В Одноклассниках мы пишем на Java, у нас есть JavaScript и TypeScript, а ещё мы хотим сканировать мобильные приложения, поэтому нужна поддержка Android-а.
Второе: мы однозначно хотим taint analysis. Как мы только что выяснили, эта штука нужна, чтобы находить инъекции и подобные им баги, а они составляют значительную часть всех проблем.
Мы поняли, что не ограничимся набором стандартных правил, потому что в нашем коде есть конструкции, которые статический анализатор «из коробки» не понимает, возможность кастомизации правил нам важна.
Хотим, чтобы у разработчиков была единая «точка правды» про наш статический анализ: чтобы все использовали одну и ту же версию правил, знали статус сканирования на данный момент, видели какие из найденных ошибок являются ложными срабатываниями, а какие настоящими багами. В общем, нам нужен collaboration сервер.
Наконец, мы хотим, чтобы добавление двух строчек кода в наш проект не повлекло необходимость переделывать всё. Если мы уже разобрали результаты сканирования на настоящие баги и ложные срабатывания, то следующее сканирование с небольшими изменениями позволяло бы переиспользовать предыдущие результаты.

Также это единственный опенсорсный анализатор для Java, позволяющий добавлять свои правила taint analysis.

Каковы инструменты тестирования безопасности?

Существует множество различных инструментов тестирования безопасности, но некоторые из самых популярных перечислены ниже:

1. Nmap

nnMapper — это бесплатный инструмент с открытым исходным кодом для оценки уязвимостей, тестирования на проникновение, аудита безопасности и обнаружения сети. Его можно использовать для тестирования различных тестов безопасности веб-приложений. Он также используется сетевыми и системными администраторами для помощи в процессе инвентаризации сети, мониторинга хостов, управления службами и других сетевых действий.

Технологическая система обнаруживает IP-сети, а затем определяет, какие узлы доступны в сети, какие приложения установлены, работают ли какие-либо сетевые службы или версии, используется ли в сети брандмауэр, фильтры пакетов и другие открытые порты, сетевые протоколы. и различные подобные атрибуты.

2. Nessus

Сканер уязвимостей Nessus — популярный коммерческий инструмент, который используется для выявления уязвимостей в системах и сетях. Он имеет широкий спектр параметров сканирования, в том числе возможность сканирования определенных уязвимостей, аудита системных конфигураций и выявления мошеннических устройств в сети.

3. Метасплоит

Metasploit — популярный инструмент с открытым исходным кодом для оценки уязвимостей, тестирования на проникновение и эксплуатации. Он предоставляет множество функций и опций, в том числе возможность использовать уязвимости, создавать пользовательские полезные нагрузки и автоматизировать процесс использования уязвимостей.

4. Люкс Burp

Burp Suite — популярный коммерческий инструмент для тестирования безопасности веб-приложений. Он включает в себя широкий спектр функций, таких как возможность сканирования уязвимостей, перехвата и изменения трафика, а также приложений для нечеткого тестирования.

5. Wireshark

Wireshark — популярный инструмент сетевого анализа с открытым исходным кодом, который можно использовать для захвата и анализа сетевого трафика. Его можно использовать для выявления проблем безопасности, устранения неполадок в сети и криминалистического анализа.

Wireshark — бесплатный анализатор сетевых протоколов с открытым исходным кодом. Он обычно используется сетевыми и системными администраторами для устранения неполадок в сети. Wireshark также можно использовать для выявления потенциальных уязвимостей безопасности в системах и сетях.

6. Сканер приложений

AppScanner — это коммерческий инструмент, который используется для тестирования безопасности веб-приложений. Он имеет широкий набор инструментов для таких задач, как сканирование веб-приложений, фаззинг и перехват трафика.

DDoS

Распределенные сетевые атаки часто называются распределенными атаками типа «отказ в обслуживании» (Distributed Denial of Service, DDoS). Что же данная атака из себя представляет?

Представьте себе небольшой магазинчик с одеждой, который вмещает максимум 10–15 человек, в котором работает всего один продавец и охранник. Злоумышленники захотели ограбить этот магазин, подали объявление на популярном ресурсе, что у данного магазина будет распродажа со скидками в 99%, после чего в данный магазин приходит больше тысячи покупателей, среди которых есть и злоумышленники. Пока продавец и охранник не справляются с нагрузкой и не могут уследить за всеми покупателями разом, злоумышленники спокойно проходят под видом обычных покупателей и крадут одежду. Бизнес заходит в тупик.

Это и есть DDoS, или «распределенный отказ в обслуживании», который представляет собой злонамеренную сетевую атаку, в которой хакеры заставляют многочисленные устройства, подключенные к Интернету, отправлять запросы на сетевое соединение одному конкретному сервису или веб-сайту с целью подавления ложного трафика или запросов. Это приводит к тому, что все доступные ресурсы связываются с этими запросами, и происходит сбой веб-сервера или его отвлечение настолько, что обычные пользователи не могут создать соединение между своими системами и сервером.

Для проверки устойчивости на DDoS атаки можно воспользоваться The Low Orbit Ion Cannon (LOIC) или «Низкоорбитальная ионная пушка» Возможно самая популярная DDOS программа. Она может рассылать массовые запросы по протоколам ICMP, UDP тем самым забивая канал к серверу жертвы. Самая известная атака с помощью LOIC была совершена группой Anonymous в 2009 году и направлена против PayPal, Visa, MasterCard в отместку за отключение WikiLeaks от системы сбора пожертвований.

Атаки, организованные с помощью LOIC могут утилизироваться с помощью блокировки UDP и ICMP пакетов на сетевом оборудовании интернет провайдеров. Вы можете скачать саму программу LOIC бесплатно на сайте SourceForge. Этот инструмент на базе Windows и работа с ним очень проста, указываете сайты жертвы и нажимаете всего одну кнопку (не рекомендуется использовать дома).

Дмитрий Никульчев, DD Planet — о том, как защитить данные пользователей web и mobile сервисов

Severity в борьбе за идеальный продукт

В первую очередь мы выявляем и устраняем блокеры или ошибки, при которых у пользователя нет возможности выполнить целевое действие. Например, посетитель не может зарегистрироваться на сайте или в приложении; осуществить вход в аккаунт; получить доступ к целевым данным или к разделам приложения.
Далее мы отслеживаем и устраняем критические баги — проблемы безопасности, зависания системы, неправильно работающий бизнес-процесс, периодические падения приложения.
Затем анализируем проблемы medium-уровня — находим ошибки, которые появляются лишь в отдельных специфических ситуациях.
Завершающим этапом вносим минорные правки — избавляемся от мелких багов, отрабатываем замечания по интерфейсу и так далее.

Используйте параметризованные запросы к Базе Данных.
Избавляйтесь от конструирования запросов внутри приложения, чтобы избежать sql-инъекций.
Подключайтесь к Базе Данных лишь под специальной заведенной учетной записью с минимально необходимым набором прав.
Регулярно ведите журналы безопасности.

В качестве вступления

В прошлом году мы уже тестировали «Гарда БД» версии 4.17.1 с версией агента 2.7 и системой управления базами данных (СУБД) MS SQL. Тогда обнаружили несколько проблем: например, при прямом подключении к СУБД с установленным на сервере агентом в журнале событий продукта не отражался логин локальной учетной записи операционной системы и СУБД, а также не работала блокировка доступа к БД MS SQL с использованием агента.

В этом году для проведения испытаний на стенде мы использовали версию продукта 4.21.0 и агента 2.11. Тестирования чаще всего проводили на трех СУБД: Oracle, MS SQL Server и PostgreSQL. В статье сосредоточимся на последней, так как с ней была связана большая часть запросов. Детали подготовки стенда к тестированию опустим, отметим только, что стенд состоял из сервера управления и двух анализаторов.

Итоги

Как было озвучено ранее, пентест и Аудит ИБ являются неотъемлемой частью общего процеса обеспечения информационной безопасности. Аудит позволяет задать вектор движения для развития. Пентест же позволяет проверить насколько успешно выполняются процессы по реализации установленного вектора и насколько эффективно работает отдел информационной безопасности (~~если он конечно имеется~~). Начинать защищать информацию необходимо с Аудита ИБ. Этот шаг позволит Вам понять текущее состояние организации.

Пентест — лишь верхушка айсберга, он не позволяет увидеть всю картину в масштабе и ставит своей целью проверить техническую составляющую процесса защиты информации.

Аудит безопасности является более широким понятием. Он важен в первую очередь руководителям организаций, поскольку в результате складывается понимание о зрелости и о тенденциях к развитию.

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

Для проведения аудитов безопасности необходимо иметь фундаментальные знания как в IT сфере, так и в сфере безопасности. Необходимо иметь комплексное и стратегическое мышление для построения будущей системы безопасности.

Выводы

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

Авторы:

Михаил Топкасов, руководитель направления комплексной безопасности центра «Solar Интеграция» компании «РТК-Солар»

Никита Игонькин, руководитель направления по сервисному партнерству центра «Solar Интеграция» компании «РТК-Солар»