Выход из пользовательских данных без магических кавычек - PullRequest
Новая
       20

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

3 голосов
/ 27 ноября 2009

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

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

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

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

Руководство по PHP - mysql_real_escape_string

Руководство по PHP - htmlspecialchars

и т. Д. И т. Д.

Любые советы?

Ответы [ 5 ]

6 голосов
/ 27 ноября 2009

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

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

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

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

Edit:

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

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

2 голосов
/ 27 ноября 2009

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

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

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

2 голосов
/ 27 ноября 2009

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

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

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

1 голос
/ 27 ноября 2009

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

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

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

0 голосов
/ 27 ноября 2009

Все просто. ВСЕ входящие данные должны быть пропущены через 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 ) . "'";
}

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

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

http://localhost/test.php?hello[]=test

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

...