Оценка рисков allow_url_include или альтернатив

0

Я пытаюсь понять фактические риски allow_url_include или найти практическую альтернативу для этого сценария:

Сервер A имеет веб-страницу на основе php, которая извлекает данные с нескольких удаленных серверов (серверы B-J) об их текущем состоянии. Затем сервер A анализирует возвращаемые данные и отображает сводку. Код для получения данных и отправки его - это PHP-скрипт, который находится на серверах B до J, и по мере добавления большего количества серверов становится больно обновляться - всякий раз, когда на странице резюме требуется новая функция, этот файл должен быть обновлен на каждом сервере, чтобы он соответствовал ожидаемому возврату сводного кода.

Одним из очевидных решений является include кода для получения данных, поэтому код на серверах B-J выглядит так:

include("http://ServerA/stats/getData.php.source");
echo base64_encode(serialize(getData()));

Но почти каждый вопрос SO относительно allow_url_include просто говорит: "Не делай этого". Я изо всех сил пытался найти конкретные риски, связанные с этим, и как их смягчить.

Цель здесь состоит в том, чтобы иметь весь код на сервере A, так что добавление обслуживания/функций становится намного проще в обращении. Монтирование nfs может быть практичным, но кажется немного чрезмерным для одного файла. Написание сценария на сервере A для использования ssh для ввода нового кода на каждый сервер также является возможностью, но замедляет цикл разработки.

На серверах B до J нет других разработчиков, так что allow_url_include действительно такой риск? Что еще он мог сделать?

Теги:
security

1 ответ

1
Лучший ответ

Если уровень приложения и системный уровень ОБОИХ обеспечены до такой степени, что вы считаете, что никто не может войти - тогда нет ничего плохого в том, чтобы разрешить что-то вроде allow_url_include

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

Другие вещи, которые помогут:

Если вы на 100% не уверены, что можете защитить свой сервер на более чем разумный уровень, я бы предложил использовать альтернативу, например cURL.

  • 0
    Я также нашел этот ответ после публикации, который имеет некоторую дополнительную информацию - в основном, если вы можете полностью контролировать URL, который выбирается, он должен быть в порядке stackoverflow.com/questions/12274174/… . URL для извлечения - это строковый литерал, хранящийся на серверах BJ, не зависящий от пользовательского ввода. Если кто-то взломает Сервер A, откуда он взялся, я все равно облажался :) Учитывая, что конечным результатом является выполнение кода на одном сервере, который пришел с другого сервера, я думаю, что в любом другом решении также есть небольшая разница.
  • 0
    Когда вы сказали альтернативу, такую как cURL, вы хотели получить нужный код? Это все еще должно быть eval () ed не так ли? Это лучше, чем включить? Фактически, сейчас я использую file_get_contents () и eval (), чтобы избежать необходимости устанавливать allow_url_include в любом случае.
Показать ещё 5 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню