Исключение пользовательских данных без магических котировок

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

Очевидно, что с директивой magic quotes, устаревшей в php 5.3.0+ и удаленной в php6, это становится более актуальным, для тех, кто хочет обновить и перейти к новым языковым функциям, сохраняя устаревший код (не любим ли мы Это..).

Однако одна вещь, которую я не видел, – это много дискуссий о теории / лучшей практике с тем, что делать, как только вы защищаете свои данные – например, для хранения с косой чертой или без нее? Я лично считаю, что сохранение безнадзорных данных в БД – плохой ход, но вы хотите услышать обсуждение и лучше прочитать некоторые примеры.

Некоторые ссылки из руководства PHP для справки:

Руководство PHP – mysql_real_escape_string

Руководство PHP – htmlspecialchars

и т.д.

Какие-нибудь советы?

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

http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html

У меня есть еще несколько ресурсов, если вы заинтересованы.

Надеюсь, это то, что вы ищете, tc.

Редактировать:

Одна вещь, которую я могу добавить, – это использовать фильтры в сочетании с подготовленными операторами. Например, чтобы проверить, является ли значение укусом, которое вы используете FILTER_SANITIZE_STRING, или для электронного письма, которое вы используете FILTER_SANITIZE_EMAIL.

Это экономит некоторый объем кода и работает очень хорошо. Вы всегда можете проверить данные, используя свои собственные методы, но есть много фильтров, которые вы можете использовать.

  • Используйте правильный метод экранирования данных при выполнении запросов: mysql_real_escape_string, подготовленные запросы и т. Д. …

  • Хранить данные в базе данных без изменений

  • Используйте правильный метод вывода данных на выходе: htmlspecialchars и т. Д.

Для работы с базой данных проверьте параметризованные запросы и подготовленные операторы. PDO и mysqli хороши для этого.

Htmlspecialchars – это правильный инструмент для отображения некоторого текста в html-документах.

И, как вы упомянули php 5.3, у вас есть доступ к функциям фильтра, которые являются обязательными при обработке пользовательских данных.

Для вставки базы данных решение заключается в использовании переменных привязки .

В общем, всякий раз, когда вы обнаруживаете, что что-то избегаете (аргумент командной строке, команде db, пользовательскому html и т. Д.), Это указывает на то, что вы не используете правильный вызов функции (например, используя system когда можете используйте multi-arg-форму exec ) или что ваша инфраструктура недостаточна. Стандартный подход к работе в недостаточной структуре – это усилить его, чтобы вы могли вернуться, чтобы не думать о цитировании.

Размышление об уровнях побега и уровнях цитирования может быть забавным, но если вам действительно нравится играть в Tcl в свободное время. Для реальной работы вы не должны думать о цитировании, если вы не разрабатываете библиотеку для других людей, и в этом случае вы должны правильно указывать и позволять вашим пользователям избегать думать о цитировании. (И вы должны очень точно документировать то, что вы цитируете, и не делаете)

Это просто. ВСЕ входящие данные должны быть запущены через mysql_real_escape_string (), прежде чем вставлять их в базу данных. Если вы знаете, что что-то должно быть целым числом, например, установите его в целое число перед его вставкой и т. Д. Помните, что это просто для остановки SQL-инъекции. XSS и проверка данных различны.

Если вы хотите, чтобы что-то было электронным письмом, вам, очевидно, нужно проверить его, прежде чем вставлять его в базу данных.

htmlentities () дезактивирует данные, то есть модифицирует данные. Я думаю, что вы всегда должны хранить необработанные данные в базе данных, и когда вы берете эти данные, выберите, как вы хотите его дезинфицировать.

Мне нравится использовать следующую функцию в качестве «обертки» для функции mysql_real_escape_string () .

 function someFunction( $value ) { if ( is_int( $value ) || is_float( $value ) ) { return $value; } return "'" . mysql_real_escape_string( (string) $value ) . "'"; } 

Если значением является float или integer, тогда нет смысла запускать mysql_real_escape_string () . Причина, по которой я передал значение в строку перед передачей ее в mysql_real_escape_string () , заключается в том, что иногда это значение может быть не строкой.

Пример значения, не являющегося строкой:

HTTP: //localhost/test.php привет [] = тест

Внутри test.php вы запускаете mysql_real_escape_string () на $ _GET ['hello'], ожидая, что hello будет строкой. Ну, так как человек задает значение массиву, это фактически вызовет уведомление, поскольку hello не является строкой.