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

Question

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

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

Для того, чтобы обеспечить пользователям этой структуры имеют доступ к безопасной, чистой данные через объект запроса, I планируете использовать 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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

Похоже, что стиль мышления magic_quotes. Кроме того, по крайней мере magic_quotes на 99% обратимо во время выполнения. Ваши «очищенные» данные могут быть потерянными, что действительно отстойно.