Мы
рассказали о пяти простых видах критических уязвимостей, которые были обнаружены нашей командой при тестировании реальных IT-продуктов. Сегодня предлагаем поговорить о следующих пяти, более опасных и сложных в обнаружении.
Загрузка исполняемых файлов
Тестируемое приложение позволяло загружать файлы, которые были доступны по прямому пути. При этом содержимое файла проверялось, а его расширение – нет. Файлы с php-кодом оно также не пропускало.
Проводя аудит приложения, мы немного изменили php-файл, добавив в его начало HTML- разметку, при этом оставив расширение .php. В итоге мы получили полный доступ к серверу с возможностью выполнения консольных команд.
Причина: недостаточная проверка загружаемых файлов.
Возможное последствие: получение полного контроля над веб-приложением.
SQL-инъекция
Немного об SQL-инъекциях. SQL-инъекция – это внедрение SQL-кода в запросы к приложению. В зависимости от SQL-запроса инъекции бывают следующих типов:
- С выводом результата на страницу;
- Слепые (для извлечения данных мы используем посимвольный перебор, а решение о том, что символ верный, принимается на основании изменения логики работы приложения или появления временной задержки).
Возможные последствия инъекции:
- Кража данных;
- Обход аутентификации;
- Полный захват сервера.
Для обнаружения таких уязвимостей мы иногда используем программу SQLMAP, но чаще ищем вручную, без использования автоматизированных средств. В нашем случае мы обнаружили SQL-инъекцию на главной странице сайта в элементе поиска.
Причина: отсутствие проверки входных данных.
Последствия: получение полного доступа к базе данных приложения.
Чтение локальных файлов
Мы тестировали многопользовательское приложение, в котором хранились персональные данные пользователей. Приложение было написано с уязвимостями, что позволило нам передавать ему в запросе имя локального файла на сервере и получать его содержимое в ответе.
Нам удалось получить файл конфигурации, который дал нам возможность попасть в абсолютно любой аккаунт в приложении. Поскольку в приложении был реализована функция отправки электронных сообщений, то через механизм сброса пароля мы могли получать ссылки, которые приложение высылало пользователям для смены пароля. Мы переходили по ссылке, меняли пароль и дальше авторизировались в приложении.
Причина: отсутствие проверки входных данных.
Последствия: чтение конфигурационных файлов веб-приложения.
NOSQL-инъекция
Вы уже знаете, что есть SQL-инъекция. А бывают ли NoSQL-инъекции? Конечно!
Redis, MongoDB, memcached относятся к классу нереляционных СУБД, и хакеры, естественно, не могли пройти мимо.
NoSQL ≠ No Injection
Главное отличие в том, что базы данных NoSQL не поддерживают язык запросов SQL. Каждая база данных может использовать свой язык. При этом число потенциальных уязвимостей также растет.
При тестировании приложения мы столкнулись с СУБД MongoDB.
Что же мы нашли?
В приложении было API, которому можно было отправлять запросы. Аутентификация происходила с помощью токена длиной 32 символа. Перебрать его не представлялось возможным. Немного подумав, мы решили проделать манипуляции с параметром. Изучив документацию MongoDB, мы обнаружили, что возможно внедрять регулярные выражения в запрос и таким образом сокращать данные для этого запроса. В итоге 32-символьный параметр мы сократили до 4 шестнадцатеричных символов, которые легко подбирались для аутентификации в приложение.
Причина: недостаточная проверка входных данных.
Последствия: обход аутентификации в приложении.
Состояние гонки
Самая интересная, на мой взгляд, уязвимость, которая была обнаружена в финансовом приложении.
Состояние гонки – ошибка проектирования многопоточного приложения. В результате несколько потоков пытаются одновременно получить доступ к данным, и хотя бы один из них выполняет запись. В результате получается, что читающие потоки получают предыдущее значение, которое было изменено пишущим потоком.
Что мы сделали?
Мы попытались отправить несколько одновременных запросов к веб-приложению. Веб-приложение – хороший пример многопоточного приложения, так как с ним работают много пользователей, которые могут одновременно осуществлять вход в приложение. Важным условием является операция записи либо файла, либо в базу. В нашем случае все записи происходили в базу. Мы отправили несколько запросов на перевод денег и обнаружили, что получили в несколько раз больше, чем планировали. А потратили в итоге ту сумму, которую планировали. Приведем пример: пусть за X монет можно получить Y рублей. Мы делаем 10 одновременных запросов на обмен X монет на рубли. В результате с нашего счета списывается X монет, а получаем 10*Y рублей.
Причина: ошибка проектирования приложения.
Последствия: кража денег.
Чтобы предотвратить подобные последствия и защитить свой программный продукт, мы рекомендуем компаниям проводить предварительные проверки и тестировать ПО на наличие уязвимостей.
Обратившись к
команде профессионалов, вы всегда будете уверены, что ваш продукт не представляет угрозы для данных пользователей.
