Сценарий ниже, test.php, предназначен для размещения в определенном каталоге всех моих сайтов wordpress. Его цель – захватить файл по адресу $ source ниже и извлечь его в каталог, в котором он находится. Это все, что нужно сделать.
Например, у меня будет интерфейс панели инструментов на моем центральном сервере, в котором перечислены все мои сайты, на которых присутствует этот скрипт. Затем я выполняю процедуру cURL, которая выполняет итерацию по каждому сайту и выполняет вызов этого скрипта, эффективно отправляя файл обновления всем им сразу.
Вызов сделан так …
...processing site 1 update... http://targetsite1.com/somedeepdirectory/test.php?query=updates.zip ...processing site 2 update... http://targetsite2.com/somedeepdirectory/test.php?query=updates.zip ...etc until all my sites have been updated. Мой вопрос: (1) насколько безопасным (закаленным) является этот скрипт, как есть. и (2) какие проверки я должен сделать, чтобы сделать больше …
Я думаю, что, как минимум, я бы ограничил количество символов для myquery, а также проверил полезную нагрузку в myquery на наличие вредоносных, неожиданных типов файлов?
<?php
// TEST.PHP
$source = 'http://mycentralserver.com/protected/'.$_GET['myquery']; $target = '.'; $out_file = fopen(basename($source), 'w'); $in_file = fopen($source, 'r'); while ($chunk = fgets($in_file)) { fputs($out_file, $chunk); } fclose($in_file); fclose($out_file); $zip = new ZipArchive(); $result = $zip->open(basename($source)); if ($result) { $zip->extractTo($target); $zip->close(); } ?>
Безопасность этого скрипта в его текущем состоянии довольно хороша. У меня есть несколько проблем. В разделе «NO CONDITION» вы должны случайно загрузить файл .php и сохранить его в своем веб-корне. Это самое худшее, что может случиться для этого скрипта, поскольку это будет уязвимость удаленного выполнения кода. Файлы должны быть загружены в определенный каталог, если вы заинтересованы в другом доступе к этому файлу, вы должны сделать «deny from all» в .htaccess в этой папке. Если в этом скрипте есть какие-либо ошибки, вы должны удалить загруженный файл. На самом деле я рекомендую удалять загруженные файлы как можно скорее.
Меня беспокоит то, что сценарий должен ошибочно ошибочно. Вы должны проверить, чтобы убедиться, что вы получили то, что ищете. Даже если файл не является файлом .php, он может содержать php-код <?php ?> Который затем может быть include () 'ed, который превратит уязвимость локального файла (LFI) в полномасштабное выполнение удаленного кода.
В безопасной конфигурации php allow_url_fopen должен быть выключен, и PhpInfoSec соглашается со мной. Это означает, что fopen () не может использоваться для HTTP. allow_url_fopen включен по умолчанию, и я отключил его на всех производственных системах. Причина в том, что я лично написал эксплойт с удаленным выполнением кода в галерее Coppermine Photo Gallery, который воспользовался этим небезопасным дефолтом. CURL должен ВСЕГДА использоваться для HTTP в PHP, он более безопасен и более стабилен.
Я мог бы пройти
http://targetsite1.com/test.php?query=/tmp/somefile.zip
и clobber ваш сайт с любым файлом я мог бы получить где-то на вашем веб-хостинге.
– На самом деле я не уверен в этом. Он должен быть доступен на веб-сайте mycentralserver.com.
Сайты, о которых идет речь, тупо загружают .ZIP-файл с вашего центрального сервера по команде. Они не подтверждают, что файл .ZIP поступает от вас или что ваш центральный сервер не был скомпрометирован.
Я бы использовал GPG для подписывания ваших ZIP-адресов. Им не нужно зашифровывать (но это никогда не повредит), но их нужно подписать.
Подумайте, что делает ваш скрипт. Вы получаете доступ к некоторому механизму запросов, созданию zip-файла и передаче данных взад и вперед по этому файлу и механизму запросов. К счастью, этот код выполняется на сервере, а не на клиентской машине, поэтому он по крайней мере так же небезопасен, как и доступ к вашему веб-серверу. После рассмотрения вашего веб-сервера он будет настолько же безопасным, как и ваша сетевая архитектура, для доступа к службе, работающей с этим механизмом запросов, или же защищенной, как доступ к этому zip-файлу, создаваемому скриптом.
Если эти хранилища данных не хранят личную информацию, никто не захочет ввязываться в ваш код, если не испортить ваш код, это простое средство для дефрагментации сайта с определенной степенью трафика или репутацией. Итак, какие существуют механизмы, позволяющие людям свободно вводить вредоносный код в ваш механизм запросов или ваш zip-архив?
Попробуйте отключить fopen_wrappers и использовать библиотеки curl или http для доступа к указанному HTTP-контенту.
Это позволит защитить вашу систему от других уязвимостей, когда злоумышленник может получить доступ к веб-контенту внутри сценария, где вы намерены исправить доступ к локальной файловой системе. Если fopen_wrappers выключен, файл означает (локальный) файл и http означает http.
Подумайте также о том, кто может выполнить этот скрипт. Я бы защитил его каким-то образом, чтобы случайный парень / робот в Интернете не мог легко его назвать. Рассмотрите возможность ограничения его по IP-адресу источника или, возможно, выполните проверку пароля, если скрипт предназначен для вызова в интерактивном режиме.
Одна из проблем заключается в том, что вы не проверяете обход каталога, поэтому можно скопировать весь диск (в принципе) в папку «.».
Если ./ доступно из Интернета, у вас есть большая проблема.
Мой совет – рекурсивно удалить все экземпляры .., чтобы избежать обхода каталога
Чтобы быть более точным, если бы я передал в качестве входных данных ../../../../../../etc/passwd, то этот файл будет скопирован в текущий рабочий каталог. Поскольку ваш скрипт имеет доступ к записи там, очевидно, файл passwd будет открыт.
Также не кодирование a. или a / могут быть закодированы по десяткам разных способов, поэтому не выполняйте жесткий поиск и замените на ../