Блог A1QA

О тестировании и качестве ПО

ТОП-10 уязвимостей безопасности от A1QA. Часть 2

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

6. Загрузка исполняемых файлов

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

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

Причина: недостаточная проверка загружаемых файлов.

Возможное последствие: получение полного контроля над веб-приложением.

7. SQL-инъекция

Немного об SQL-инъекциях. SQL-инъекция – это внедрение SQL-кода в запросы к приложению. В зависимости от SQL-запроса инъекции бывают следующих типов:

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

Возможные последствия инъекции:

  • Кража данных;
  • Обход аутентификации;
  • Полный захват сервера.

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

Причина: отсутствие проверки входных данных.

Последствия: получение полного доступа к базе данных приложения.

8. Чтение локальных файлов

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

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

Причина: отсутствие проверки входных данных.

Последствия: чтение конфигурационных файлов веб-приложения.

9. NoSQL-инъекция

Вы уже знаете, что есть SQL-инъекция. А бывают ли NoSQL-инъекции? Конечно!

Redis, MongoDB, memcached относятся к классу нереляционных СУБД, и хакеры, естественно, не могли пройти мимо.

NoSQL ≠ No Injection

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

При тестировании приложения мы столкнулись с СУБД MongoDB.

Что же мы нашли?

В приложении было API, которому можно было отправлять запросы. Аутентификация происходила с помощью токена длиной 32 символа. Перебрать его не представлялось возможным. Немного подумав, мы решили проделать манипуляции с параметром. Изучив документацию MongoDB, мы обнаружили, что возможно внедрять регулярные выражения в запрос и таким образом сокращать данные для этого запроса. В итоге 32-символьный параметр мы сократили до 4 шестнадцатеричных символов, которые легко подбирались для аутентификации в приложение.

Причина: недостаточная проверка входных данных.

Последствия: обход аутентификации в приложении.

10. Состояние гонки

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

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

Что мы сделали?

Мы попытались отправить несколько одновременных запросов к веб-приложению. Веб-приложение – хороший пример многопоточного приложения, так как с ним работают много пользователей, которые могут одновременно осуществлять вход в приложение. Важным условием является операция записи либо файла, либо в базу. В нашем случае все записи происходили в базу. Мы отправили несколько запросов на перевод денег и обнаружили, что получили в несколько раз больше, чем планировали. А потратили в итоге ту сумму, которую планировали. Приведем пример: пусть за X монет можно получить Y рублей. Мы делаем 10 одновременных запросов на обмен X монет на рубли. В результате с нашего счета списывается X монет, а получаем 10*Y рублей.

Причина: ошибка проектирования приложения.

Последствия: кража денег.

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

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

Поделиться статьей: