Почему WordPress до сих пор использует addlashes (), register_globals () и magic_quotes?

В дополнение к ответу @tom.

Магические цитаты

Автоматический анализ всех записей и добавление магических кавычек - это создание ошибок и бесполезность.

• Бесполезно, поскольку вы не можете полагаться на магические кавычки для защиты вашего ввода (примером может служить многобайтовая кодировка ошибок для SQL-инъекций). Поэтому перед сохранением данных в базе данных вам необходимо применить реальный фильтр.
• Создание ошибок. Если вам нужно действительно избавиться от своих данных перед сохранением в базе данных, вам нужно проверить, что она еще не сбежала (и простой факт, что эти настройки существуют и могут быть применены в среде хостинга, заставит вас проверить этот параметр был установлен или нет).
• Создание ошибок: все данные, отправленные пользователем, не всегда предназначены для хранения базы данных. Эвакуация может сломать контент, подумать о json-контенте, например, или даже содержимое файла с опасным magic_quote_runtime
• Создание ошибок: все хранилище базы данных не экранируют кавычки одинаково...

Итак Почему?, почему мы видим такую ​​функцию в CMS?

• см. здесь функцию add_magic_quotes, которая может использоваться в выделенном массиве, возможно, не на _GET или _POST. Но эффективно тот факт, что эта функция просто использует addlashes, а не функцию, предназначенную для базы данных, делает ее довольно плохим.
• Тот факт, что хостинг-провайдер может применять автоматические магические кавычки, - это кошмар для разработчика CMS. Либо вы обнаружите это, либо сообщите пользователю, которого вы отказываетесь запускать, или вам нужно управлять тем фактом, что контент может или не может быть волшебным - добавлено... и чтобы все были в одном состоянии, вы запускаете не-добавленный контент в этой функции, чтобы по крайней мере все были в одном и том же (плохом) состоянии.
• Из того, что я могу видеть в Wordpress, до сохранения a stripslahes_deep выполняется в wp_insert_post. И add_magic_quotes обычно выполняется на данных, выведенных из Db, прежде чем эти данные будут отправлены на wp_insert_post. Это может мне показаться, что проблема заключается в том, чтобы эффективно добавлять косые черты перед их удалением... возможно, потому что санируют фильтры, которые происходят до сохранения ожидаемого контента со слэшами, или, может быть, потому, что никто не помнит, почему код работает таким образом: -)

register_globals

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

Наличие реестра - это совершенно правильная вещь в приложении. Функция register_global опасна, только если вы разрешите некоторому вводу пользователя переопределить действующий безопасный ввод. И, конечно, только если этот безопасный ввод взят из $_GLOBALS в другом месте (или с ключевым словом global).

Опасная часть функции здесь - часть функции, которую вы извлекли, цикл на $query->query_vars. Вам нужно будет отслеживать вызовы, чтобы увидеть, может ли пользователь вводить ключи через tt wp_parse_args и заканчивать эту функцию. Но следующей частью этой функции является фиксация содержимого $_GLOBALS для нескольких объектов:

$GLOBALS['query_string'] = $this->query_string;
$GLOBALS['posts'] = & $wp_query->posts;
$GLOBALS['post'] = (isset($wp_query->post)) ? $wp_query->post : null;
$GLOBALS['request'] = $wp_query->request;

Таким образом, по крайней мере тезисы глобалов не могут быть перезаписаны пользователем и безопасны.

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

Но, конечно же, это плохая практика, вы наверняка найдете плохие плагины WordPress с неправильным использованием $_GLOBALS или неправильное использование концепции add_magic_quotes to data pulled from db wordpress. Но уже задолго до того, как Zend Framework CMS получила такое большое количество вкладов.

Магические цитаты

Следующий текст взят из PHP.net

http://www.php.net/manual/en/security.magicquotes.why.php

Нет причин использовать магические кавычки, потому что они больше не являются поддерживаемой частью PHP. Тем не менее, они действительно существовали и помогали нескольким новичкам в блаженном и неосознанном виде писать лучше (более безопасный) код. Но, имея дело с кодом, который опирается на это поведение, лучше обновить код вместо того, чтобы включать магические кавычки. Так почему же эта функция существует? Простой, чтобы помочь предотвратить инъекцию SQL. Сегодня разработчики лучше осведомлены о безопасности и в конечном итоге используют механизмы экранирования, специфичные для базы данных, и/или подготовленные операторы вместо того, чтобы полагаться на такие функции, как магические кавычки.

addslashes() vs mysql_real_escape_string()

Причина, по которой вы должны использовать mysql_real_escape_string(), заключается в том, что она является "функцией MySQL" и создана специально для экранирования ввода пользователя перед ее выполнением в запросе mysql, тогда как addslashes() является "функцией PHP". Вероятно, это звучит немного странно, но существует одно важное различие между ними и оно связано с использованием однобайтовых и многобайтовых символов. Вы все же можете вводить базы данных, защищенные функцией addlashes, но вводить базы данных, защищенные mysql_real_escape_string, гораздо сложнее. Вы можете узнать больше об этом ЗДЕСЬ

Регистрировать глобалы

Причина, по которой вы НЕ должны использовать register_globals, состоит в том, что переменные становятся доступными для всех, а это означает, что в следующем примере вы могли бы установить $access для true, если он не был инициализирован до

<?php

if (isAuthenticated()) { $access = true; }

if ($access == true) {
  include(controlpanel.php);
}

?>

Вышеприведенный код даст вам sh #! множество проблем, но если мы сначала инициализируем переменную, добавив в верхнюю часть страницы

$access = false;

... мы должны быть в порядке, даже если у нас есть register_globals ON

Итак, если команда Wordpress инициализировала все переменные (что они, вероятно, есть), вам не нужно беспокоиться об использовании глобальных символов.

Заключение

Это определенно плохая практика, использующая любую из этих 3 функций/функций, и я бы никогда не сделал это сам. Вы уверены, что работаете с последней версией Wordpress? Как кто-то прокомментировал, если вы используете последнюю версию, это из-за лени или еще хуже, он все еще там. Я никогда не использовал Wordpress для чего-либо, кроме блогов, которые не требуют большой защиты.

Wordpress. Я провел много бессонных ночей, пытаясь ответить на единственный вопрос: "Почему?"

Поскольку я столкнулся с его исходным кодом, я ненавижу его. Это ужасно. И пусть мой пост (и репутация) будет миноваться, но это правда.

У него нет ядра. Вместо ядро ​​есть мусор кода. Это напоминает php3. В нем используется огромная куча несвязанных и нелегальных функций. "Копировать и вставить" - единственный шаблон дизайна используется в wordpress.

Да, они эмулируют использование подготовленных операторов. Но почему они не используют PDO или mysqli? Они копировали почти все функции PDO, но вместо этого не использовали его. Использование mysqli вместо mysql требует еще меньше усилий.

Они используют myql_real_escape_string. Но есть еще что-то вроде protect_string_strongly, protect_string_weakly. Существует не только одна функция - do_not_protect_string_i_believe_my_users.

Глобальные переменные - это философия Wordpress. "Если мы не знаем, как изменить этот var, мы будем отмечать его как глобальный var, и все будут счастливы". - вот что подумали разработчики Wordpress, когда они разработали hellpress.

Каждая новая версия содержит много нового в дизайне, они добавляют новые темы по умолчанию, они меняют цвет фона в области администратора С#ccc на #cdcdcd, они используют выпадающее меню в области администрирования вместо accordeon. И это потрясающе. Но они не улучшают его код.

Вы читали комментарии в WP "core"? Нет? И я сделал. Они замечательные ". Что-то вроде" Для чего нужна эта функция? Пусть на всякий случай уйдет ". или" Не печатайте это в новой версии". и т.д.

Единственный ответ на вопрос "Почему?" У меня есть: "Потому что это работает. И если это работает, не трогайте его!!!"

wordpress.org - один из самых посещаемых сайтов в мире. Зачем? Потому что никто не может понять логику Wordpress. Каждый раз каждый раз нужно что-то задавать на форуме или читать в кодексе.

Надеюсь, вы понимаете мою точку зрения.

Нет лучшего способа ответить, почему они плохи, чем ссылаться на документацию PHP на magic_quotes:

• Почему мы использовали магические кавычки?
• Почему не использовать магические кавычки

Также обратите внимание:

Эта функция была DEPRECATED с PHP 5.3.0. Опираясь на эту особенность, очень не рекомендуется.

Итак, почему Wordpress по-прежнему использует магические цитаты?

Минимальные требования Wordpress использует PHP 4.3. Да, это абсолютно обратная совместимость.

Как насчет других функций?

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

Они сделали это по одной причине:

Чтобы убедиться, что Wordpress совместим с большинством поставщиков веб-хостинга.

Одно из главных отличий между mysql_real_escape_string() и добавками - то, что mysql_real_escape_string() работает в сочетании с набором символов, чтобы он знал, как правильно удалять данные на основе набора символов.

Как правило, я считаю, что лучший подход - использовать класс запроса и делать все, что у вас есть. Таким образом, существует только одно место, где вы имеете дело с GET, POST, COOKIE, SERVER и т.д., Что значительно упрощает управление, в отличие от того, что куча случайных функций выполняет разные вещи. Это просто рецепт катастрофы.

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

Очевидно, что вы не можете получить ответ здесь, если вы не соблазните некоторого авторизованного разработчика Wordpress здесь с такой щедростью.

Но ваш вопрос слишком широк. Однако на него можно ответить абстрактной частью:

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

Действительно ли мытье рук предотвращает болезнь?
Что, если я не буду мыть руки - неужели я буду болеть?

Большая часть времени - нет.
Как общая привычка - да.

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

Хотя большую часть времени...

• addslashes не принесет никакого вреда, пока ваша кодировка будет либо utf-8, либо однобайтовой;
• Регистрировать глобальные переменные не повредит, если вы инициализируете все свои переменные;
• магические кавычки не будут наносить никакого вреда, если у вас есть все ваши переменные, котируемые для SQL, и косые черты, снятые для любого другого использования;

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