Безопасно ли отключать суперглобальные переменные PHP, если это поведение задокументировано?

Question

Я строю фреймворк PHP, и в нем есть объект запроса, который анализирует URL, а также суперглобальные $_GET, $_POST и $_FILE.

Я хочу поощритьбезопасные веб-привычки, поэтому я защищаю данные от SQL-инъекций и т. д.

Чтобы пользователи этой среды могли обращаться к безопасным, чистым данным через объект запроса, я планирую использовать unset($_GET, $_POST, $_REQUEST);после анализа этих переменных.

Я задокументирую это в комментариях к методу и объясню в документации по фреймворку, что это происходит.

Мой вопрос: это было бы желательным поведением?Какие потенциальные ловушки я не предвидел?

Answer 1

Я знаю, что на этот вопрос уже ответили, но вот мои $ 0,02.

Я бы не сбрасывал и не очищал входные массивы. Однако то, что я сделал, это заменил их объектом. Поэтому вместо необработанного массива я заменяю его объектом, который реализует ArrayAccess и Iterator. Таким образом, подавляющее большинство кода, использующего собственные массивы, будет по-прежнему работать с объектом достаточно хорошо.

Смысл в том, что по крайней мере вы можете проверить, что пути кода работают правильно с помощью тестов. Вы можете заменить эти объекты на фиктивный объект, чтобы вызвать исключение во время тестирования, чтобы вы могли обнаружить неправильный доступ к этим массивам (если вы определите, что это «плохая практика»). Таким образом, он позволяет вам работать во время производства без наложения ненужных ограничений, но также позволяет включать его для проверки передового опыта во время тестирования.

И хотя я согласен с @JW по поводу побега, вы должны фильтровать ввод. Фильтр-выход, выход-выход. Каждый раз, когда данные поступают в вашу программу (либо через пользовательский ввод, либо из БД), фильтруйте их до ожидаемых значений. Каждый раз, когда данные поступают (либо в БД, либо к пользователю), вам необходимо правильно экранировать их для этого носителя. Поэтому использование объекта запроса, позволяющего легко фильтровать отправленные данные, может быть очень полезным.

Пример использования беглого интерфейса (который вы можете или не можете хотеть):

$id = $request->get('some_id')->filter('int', array('min' => 1));

И это не включает в себя преимущества компенсации различных платформ и конфигураций (например, если magic_quotes_gcp включен или нет, и т. Д.) ...

Во всяком случае, это только мое мнение ...

Answer 2

Я не уверен, какой смысл препятствовать доступу к массивам $ _GET или $ _POST.В них нет ничего вредного.Если вы создаете основу для предотвращения внедрения SQL или межсайтового скриптинга, вам следует избегать данных при создании запроса SQL или HTML-документа.

Экранирование данных GET / POST в начале слишком рано;вы не знаете, как будут использоваться данные, поэтому вы не можете избежать их или правильно закодировать.

Сказав это, у вас все еще могут быть веские причины, чтобы люди могли получить доступ к данным GET / POST черезваш код.В таком случае я бы все равно их не сбросил.Вы можете включить сторонний код, который опирается на них.Вместо этого просто поощряйте своих пользователей избегать их (как они должны избегать глобальных переменных в целом).

Answer 3

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

Answer 4

Звучит как стиль мышления magic_quotes.За исключением того, что по крайней мере magic_quotes был на 99% обратимым во время выполнения.Ваши "очищенные" данные могут быть с потерями, которые действительно отстой.

Answer 5

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