«Странная» дыра в безопасности с длинным и трудночитаемым названием.
Что странно?
Эта дыра в безопасности «странна» тем, что находится в топ-4 OWASP, но о ней очень мало документации. Он не известен как XSS, CSRF или SQL Injection (хотя его рейтинг OWASP намного выше, чем XSS или CSRF).
Я сам никогда раньше не слышал, чтобы в прессе или новостях упоминалась эта ошибка. Возможно ли, что нет известных случаев, связанных с ним, или это потому, что ошибка имеет много сложных вариаций?
Основной причиной этой уязвимости является невнимательность разработчика или сисадмина (Если вы столкнулись с этой ошибкой, то сначала нужно тащить разработчика на рез, а потом уже тестера).
Эта уязвимость возникает, когда программа позволяет пользователям незаконно получать доступ к ресурсам (данным, файлам, папкам, базе данных) через данные пользователя.
Как воспользоваться уязвимостью
Очень случайно я обнаружил эту ошибку, когда помогал младшему брату тестировать веб-проект по продажам.
В разделе Управление заказами адрес заказа будет выглядеть так: http://shop.com/user/order/1230. Сервер прочитает идентификатор 1230 из URL-адреса, затем найдет заказ с идентификатором 1230 в базе данных и выгрузит данные в HTML.
Подражая хакеру, я немного «поиграл», заменив 1230 на значения от 1 до 2000. Система просто прочитала и отобразила все заказы с идентификаторами от 1 до 2000 (включая заказы других клиентов). ). Вредно еще!
Недостаток: программа позволяет мне получить доступ к нелегальным ресурсам (чужим заказам), через данные (ID), которые я предоставляю через URL. Программа должна была проверить, есть ли у нее доступ к этим данным.
Хакеры могут использовать множество уловок, таких как изменение URL-адресов, изменение параметров API и использование инструментов для сканирования незащищенных ресурсов. Мой старый лотерейный кинотеатр работает аналогично, заменяя URL-адрес именем пользователя в файле cookie.
Есть несколько редких случаев; хакеры могут сканировать репозиторий git, расположенный на сервере. Git доступ, он получает имя пользователя, пароль базы данных и другую важную информацию.
Профилактика
Некоторые превентивные меры:
Тщательно проверьте — причиной ошибки часто является небрежность разработчика. Однако, если продукт выходит из строя, это вина тестировщика. Это ошибка в коде, поэтому тестировщик несет ответственность за то, чтобы эта ошибка произошла с пользователем.
Защита данных «чувствительны к переходу» — для «конфиденциальных» данных, таких как источник код, конфиг, ключ базы, надо ограничить доступ. Лучший способ — разрешить внутренним IP-адресам доступ к этим данным, а хакерам — подальше от компьютера.
Самое важное: строго проверяйте разрешения пользователей
Избегайте раскрытия ключа объекта. — В приведенных выше случаях идентификатор объекта представляет собой целое число, поэтому хакер может угадать идентификатор других объектов. Чтобы предотвратить это, мы можем зашифровать идентификатор, используя GUID в качестве идентификатора. Хакеры не могут определить идентификатор другого объекта.
