Уязвимости безопасности в php fwrite?

Question

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

Вместо того, чтобы постоянно просматривать журнал ошибок "Файл не существует", относящийся к этому домену - у нас около 15 или около того хостов на этих серверах - мне было интересно, может быть проще сделать следующее когда происходит ошибка 404:

• перенаправить на страницу php и передать исходный URL-запрос
• иметь новую страницу php, которая выводит URL в файл журнала

Когда я набираю это, я все меньше и меньше убеждаюсь, что это стоящее начинание. Независимо от основного вопроса, есть ли потенциальные проблемы безопасности с использованием fwrite? Должен ли быть какой-либо вид очистки пользовательского ввода, если этот ввод будет добавлен в файл? Этот вход не будет находиться рядом с базой данных, чего бы это ни стоило. Заранее спасибо.

Answer 1

Пока вы определяете, в какой файл вы записываете (а не определяете его по URL) , не должно быть большого риска: единственное, что вы Пользователь получит содержимое, которое вы напишете в файл, и если вы не запустите этот файл, а просто прочитаете его, все будет в порядке.

Идея регистрации 404 ошибок таким способом не нова: я видел, что это делалось довольно много раз, и никогда не сталкивался с какой-либо серьезной проблемой с этим (самой большой проблемой, которую я видел, был файл, который стал довольно большим быстро, потому что было слишком много ошибок ^^)

Например, Drupal делает следующее: регистрируется 404 ошибки, но в базу данных, поэтому их проще анализировать с помощью веб-интерфейса.

Answer 2

Ну, просто обычные вещи в файловой системе: не позволяйте пользователю указывать, куда файл пойдет: такие вещи, как script.php?filename=../../../../../../../etc/passwd, даже не должны иметь возможности записи в / etc / passwd (также скрипт не должен для этого есть разрешения ФС). Кроме этого, fwrite () не имеет специальных символов, которые позволили бы ему перейти в какой-либо командный режим.

Кроме того, страница 404 довольно проста (в httpd.conf):

ErrorDocument 404 /error_page.php

и просто выведите REQUEST_URL в файл

Answer 3

Вы уже должны записывать 404 ошибки в вашем error_log.

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

Answer 4

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

1. Убедитесь, что файл, который вы пишете, не может быть обработан как HTML веб-сервером
2. Рассмотрим кодировку URL или HTML-кодировку URL.

Answer 5

Существует потенциальная проблема, на которую стоит обратить внимание, если вы пишете журналы в формате HTML (или другой тип файла, который позволяет внедрить код). Эти файлы, конечно, уязвимы для атак XSS.

Answer 6

Если все, что он делает, - это запись на диск, единственное, что кто-то извне - это заставляет его записывать на диск. Очевидно, что имя файла не должно быть параметром, который передается с неверным URL. Кто-то может попытаться использовать его, просто отправляя тонны запросов на неверные страницы с очень длинными URL-адресами. Но они должны были бы знать, что вы делаете это, и заботиться, когда есть другие способы, которые были бы более эффективными, например, обычные атаки.

Answer 7

fwrite должен быть довольно безопасным.

В качестве альтернативы вы можете использовать некоторый анализатор журнала доступа, который обычно перечисляет не найденные страницы.