Как защититься от атак Log Injection в PHP? - PullRequest
9 голосов
/ 10 марта 2019

Каков наилучший способ защиты от атак Log Injection в PHP?Конечно, мы должны очистить входные данные, но вопрос заключается в том, как и что следует очищать?

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

Я смотрю на фильтры очистки PHP как на возможное решение, но я не знаю, что мне отфильтровать.Какие персонажи могут быть опасными?

Ответы [ 3 ]

9 голосов
/ 16 марта 2019

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

Вам необходимо убедиться в следующем:

  • Никогда не используйте include, require или eval для отображения содержимого вашего файла журнала; прочитайте файл (ы), используя fopen или file и распечатайте содержимое.
  • отфильтруйте вывод перед его отображением, что-то вроде htmlentites, которое изменяет кавычки и html открывающие / закрывающие теги, было бы хорошо.
  • если вы можете отобразить вывод в текстовой области, браузер отобразит данные без выполнения сценариев, если присутствует какой-либо xss или другой вредоносный код.
  • убедитесь, что вы храните файл журнала в папке, которая не является общедоступной / доступной через Интернет, и удалите разрешения на выполнение для пользователя / группы и все разрешения для «других».
  • Последнее предложение: попытайтесь взломать ваши журналы, чтобы убедиться, что вы охватили все базы, и пока вы там, используйте фаззер для проверки на автоматические атаки.
1 голос
/ 20 марта 2019

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

Как уже упоминалось @ahmad, это становится проблемой, если вы используете что-то вроде eval для отображения файла журнала, потому что это может очень хорошо выполнить код, а знак доллара может позволить злоумышленнику сделать гораздо больше, чем только межсайтовый скриптинг. .

Но fopen обязательно лучше? Нет! Потому что примеры из прошлого это наглядно показали. Кто-то может подумать, что cat - это безопасный способ отображения текста на консоли, но даже это оказалось неправильно , и если даже самый простой инструмент для печати какого-либо текста сломан, вам не следует доверять во что угодно, верно?

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

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

1 голос
/ 19 марта 2019

При хранении или отображении пользовательского ввода всегда проверяйте, чтобы фильтровать HTML-теги, такие как <script>, которые могут выполнять внешний код javascript на вашем сайте, это может привести к краже сессии / cookie.

Также фильтруйте теги, такие как <style>, которыеможет не причинить вреда, но может помешать макету вашего сайта.

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

...