Введение
Мы знаем важность безопасности приложений, которые используются для сохранения данных и активов организации. Для реализации безопасности приложения существует множество фреймворков, таких как SANS, OWASP и т. Д. Каждый фреймворк указывает разработчику важность проверки пользовательского ввода, такой как дезинфекция пользовательского ввода, синтаксиса, длины и бизнес-СОП для принятия этого ввода. Проверка ввода может применяться от самых разных атак. Пройдем через уязвимости манипуляции, возникающие из-за проверки ввода
Что такое уязвимости манипулирования путями?
В этой уязвимости злоумышленники получают доступ к тем файлам и каталогам, которые хранятся вне папки Webroot. В основном, если какой-либо из параметров приложения получает файлы и для него нет проверки ввода, злоумышленник может манипулировать путем с помощью последовательности «../» или ее шаблона кодирования, используя абсолютные пути к файлам. Злоумышленники могут использовать этот метод для доступа к файлам за пределами корневого веб-каталога и благодаря этому могут получить доступ к конфиденциальным файлам. К конфиденциальным файлам относятся файлы исходного кода приложения, важные файлы операционной системы, такие как / etc / passwd или / etc / shadow.
Почему они возникают?
- Злоумышленники, способные обойти проверку ввода или приложение, не имеют никакой проверки ввода.
Пример: приложение принимает вводимые пользователем данные для чтения файла, но не выполняет никакой проверки. В этом коде имя файлов берется в качестве входных данных, а затем приложение добавляет «.txt» к файлам и затем обращается к ним. Поскольку для параметра имени файла нет проверки ввода, злоумышленник может использовать методы обхода проверки «.txt» для доступа к файлам.
User_File = new FileInputStream (cfg.getProperty («sub») + ». txt»);
User_read = User_File.read (arr);
out.println (arr);
Если программа запускается с высокими привилегиями, злоумышленники могут получить доступ ко всем файлам на сервере с помощью инъекции нулевого байта в имя файла и могут обойти реализацию «.txt». Злоумышленник может использовать обозначение «../» для доступа к файлам за пределами корневого веб-каталога.
Как мы можем это использовать?
- В приложении нет проверки ввода:
У нас есть приложение «test.com». Приложение было создано с использованием PHP, и мы собираемся изучить его единственную функцию, в которой приложение отображает изображения:
‹img src =” / images.php? filename = bless.png ”›
img: тег HTML для представления файлов изображений.
Src: представляет собой исходный URL-адрес, откуда берется изображение.
Имя файла: параметр, который принимает имя изображения и возвращает его содержание. В приведенном выше фрагменте будет возвращено изображение bless.png.
Изображения хранятся в папке / var / www / images /. Параметр «Имя файла» извлекает изображение по указанному ниже пути:
/var/www/images/logo.png
Без какого-либо параметра «Имя файла» выберите изображение из вышеупомянутого места.
Желаемый путь выглядит так:
https://test.com/images?filename=/etc/passwd
Злоумышленники предоставляют этот путь и получают значение «/ etc / passwd» независимо от изображения «logo.png».
- Использование записи с косой чертой (../) для обхода защиты LFI: это основной сценарий атаки, который может использовать злоумышленник. злоумышленник может использовать нотацию ../ для доступа к файлам вне корневого каталога.
Поэтому, когда злоумышленник пытается получить конфиденциальные файлы, он предоставил последовательность «../../../» в параметре «Имя файла».
Как выглядит желаемый путь:
https://test.com/images?filename=../../../etc/passwd
Как только злоумышленник предоставляет эти входные данные, он выходит из корневого веб-каталога и извлекает конфиденциальный файл «/ etc / passwd». Эти три последовательных «../» идут вверх от 3-х каталогов «/ var / www / images», где он находится в настоящее время. Таким образом, злоумышленник может получить доступ к каталогу «/ root» и прочитать оттуда файлы.
- Использование кодирования для обхода защиты LFI: Если Приложение реализовало защиту от «../», поэтому злоумышленник, который блокирует этот тип синтаксиса, то злоумышленник использует кодировку «../».
Кодирование преобразует текст в закодированную строку «%», что помогает обойти ограничение, установленное разработчиком.
Как выглядит желаемый путь:
https://test.com/images?filename=..%2F..%2F..%2Fetc%2Fpasswd
Как только злоумышленник предоставляет эти входные данные, он успешно обходит реализацию разработчика и извлекает конфиденциальный файл «/ etc / passwd».
- Использование двойного кодирования для обхода защиты LFI: если администратор приложения реализовал защиту от кодирования, злоумышленник не сможет получить доступ к файлам напрямую. Тогда злоумышленник может использовать двойное кодирование «../».
Метод двойного кодирования иногда помогает обойти ограничение, установленное разработчиком, он декодирует данные только один раз и кодирует ввод в недопустимые символы, которые могут помочь в обходе ограничения.
Как выглядит желаемый путь:
https://test.com/images?filename=..%252F..%252F..%252Fetc%252Fpasswd
Как только злоумышленник предоставляет эти входные данные, он успешно обходит реализацию разработчика и извлекает конфиденциальный файл «/ etc / passwd».
- Использование оболочки PHP для обхода защиты LFI: Разработчик уже реализовал проверку нотации «../» и ее кодировки, поскольку злоумышленник предоставляет все вышеупомянутые методы, которые приложения обнаруживают, и злоумышленник не может видеть конфиденциальные файлы из указанного места.
Злоумышленники могут использовать «PHP Wrapper» также для обхода проверки. Оболочка PHP имеет встроенную локальную файловую систему, которую можно использовать, когда злоумышленник предоставляет относительный путь, и этот путь не начинается с /, \, \\ или любой буквы диска Windows, к которой будет применяться указанный по времени путь. текущий рабочий каталог. В основном путь работает там, где в настоящее время находится скрипт.
С параметром FileName, когда злоумышленник проходит оболочку PHP, указанный путь выглядит так:
https://test.com/images?filename=php://filter/convert.base64encode/resource=etc/passwd
«php: //filter/convert.base64encode/resource» эта полезная нагрузка заставляет PHP кодировать в base64 упомянутый файл перед использованием или визуализацией в пользовательском интерфейсе.
Таким образом, после внедрения PHP Wrapper злоумышленник может успешно обойти ограничения разработчика.
Исправление
- Добавьте в белый список файлы, к которым можно получить доступ.
- Используйте вызовы «файловой системы» для функций без ввода данных пользователем.
- Не включайте [../] в пути, указанные пользователем при вводе. Если функция видит, этот тип ввода производит там дезинфекцию.
- Проверяйте вводимые пользователем данные также по синтаксису, длине и т. Д.
- Реализуйте строгие политики контроля доступа, чтобы ограничить пользователей, чтобы они не могли получить доступ к каталогам, в которых будут сохраняться файлы.
Заключение
Может быть несколько способов, которыми злоумышленник может обойти уязвимость обхода пути, но если разработчики реализуют лучшие практики LFI, злоумышленник не сможет ее обойти. Согласно раскрытым данным, уязвимость LFI / обхода пути может быть серьезной. Если злоумышленник успешно раскрыл PII или конфиденциальные данные организации, это может быть уязвимость высокой степени опасности. Поэтому применяйте его с небольшими предосторожностями.
