Почему WordPress все еще использует addslashes(), регистровые глобалы() и магические кавычки?

Чтобы получить больше опыта в Wordpress, я углубился в его кодовую базу, чтобы изучить его внутреннюю работу и рабочий процесс, и я был весьма удивлен, когда увидел, что:

  1. Они реализуют register_globals (выдержка из wp-includes/class-wp.php ):

     // The query_vars property will be extracted to the GLOBALS. So care should
 // be taken when naming global variables that might interfere with the
 // WordPress environment.
 function register_globals() {
    global $wp_query;
    // Extract updated query vars back into global namespace.
    foreach ( (array) $wp_query->query_vars as $key => $value) {
        $GLOBALS[$key] = $value;
    }

  2. Они полагаются на магические цитаты (выдержка из wp-includes/functions.php .magic_quotes_gpc отключается при начальной загрузке, перед вызовом этой функции):

    function add_magic_quotes( $array ) {
    foreach ( (array) $array as $k => $v ) {
    if ( is_array( $v ) ) {
        $array[$k] = add_magic_quotes( $v );
    } else {
            $array[$k] = addslashes( $v );
    }
  3. Они полагаются на добавляет косые черты (но с 2.8.0 они также ввели строку mysql_real_escape_string, но функция _weak_escape(), которая использует addslashes(), все еще существует в классе wpdb)
    ОБНОВЛЕНИЕ: Я вижу, что они эмулируют подготовленные операторы с использованием sprintf() и пользовательских владельцев мест размещения, поэтому, я думаю, запросы должны быть безопасными. Тем не менее, я озадачен тем, почему они не предоставляют по крайней мере mysqli, в конце концов, обнаружение версий Mysql и PHP происходит в начале последовательности начальной загрузки.

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

Но у WP должна быть причина для их использования. Я хотел бы узнать у более опытных программистов, действительно ли существуют проблемы с безопасностью, или иногда их использование слишком затуманено слухами и ложными убеждениями. Я знаю, что magic_quotes - это наследие прошлого, и то же самое можно сказать о дополнительных косых чертах (на по крайней мере, когда используется для баз данных), но во время поиска в Google, прежде чем задавать этот вопрос, я обнаружил, что многие веб-сайты говорят об использовании addslashes() через mysql_real_escape_string().

Мне интересно узнать четкую, подробную причину того, почему используются эти плохо изображенные функции; За эти годы в Wordpress было много улучшений, затрагивающих различные аспекты, и все же эти функции все еще используются; Поэтому я ищу конкретное объяснение положительных аспектов, которые каким-то образом переопределяют отрицательные и оправдывают использование этих функций.

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

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

Author: Peter O., 2012-02-23
Source

8 answers

Wordpress Open Tickets over Time
(Wordpress Открывает билеты с течением времени)

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

Кодовой базе Wordpress около 10 лет, она полна устаревшего кода[1]. Из-за этого программа не может сильно развиваться на уровне кода, поэтому вы находите множество обходных путей для решения проблем которые в настоящее время уже решаются гораздо лучше.

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

Вы не можете легко рефакторировать такой код.

То же самое для класса базы данных. Он имеет долгую историю, изначально основанный на ранней версии ezSQL. В то время не было mysql_real_escape_string, и когда он был представлен, разработчики WP столкнулись с проблемой, что не все базы установки поддерживают его.

Так что не удивляйтесь практике кодирования, которую вы найдете в коде Wordpress. Вы узнаете, как все могло быть сделано много лет назад и с более или менее устаревшими версиями PHP. Это не так давно, например, Wordpress перешел на PHP 5.

  • Обратная совместимость.
  • Нацелен на большое количество (технически более или менее устаревших) хостов.
  • Не ломайте то, что работает с дефектами.

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

[1] видишь Основные этапы WordPress: Ранняя временная шкала проекта (примерно с 2000 по 2005))

 31
Author: hakre, 2012-02-27 01:23:26

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

Волшебные Цитаты

Автоматический анализ целых записей и добавление магических кавычек одновременно создают ошибки и бесполезны.

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

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

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

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

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

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

Опасная часть в функция здесь - это часть функции, которую вы извлекли, цикл $query->query_vars. Вам нужно будет отслеживать вызовы, чтобы увидеть, могут ли введенные пользователем ключи выполняться через 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 dbwordpress. Но пройдут годы, прежде чем CMS Zend Framework получит такое большое количество вкладов.

 12
Author: regilero, 2013-06-03 09:30:29

Волшебные Цитаты

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

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

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

Добавить косые черты() против mysql_real_escape_string()

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

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

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

<?php

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

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

?>

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

$access = false;

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

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

Заключение

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

 11
Author: Tom, 2012-02-23 22:34:07

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, они используют выпадающее меню в админке вместо аккордеона. И это потрясающе. Но они не улучшают его код.

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

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

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

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

 7
Author: Ruslan Polutsygan, 2012-02-28 22:27:32

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

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

Эта функция УСТАРЕЛА с версии PHP 5.3.0. Полагаться на эту функцию крайне не рекомендуется.

Так почему же Wordpress все еще использует волшебные кавычки?

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

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

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

 3
Author: Levi Morrison, 2012-02-22 23:23:19

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

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

 1
Author: I'll-Be-Back, 2012-02-23 00:07:07

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

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

И все же ваш вопрос слишком широк. Тем не менее, можно ответить на его абстрактную часть:

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

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

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

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

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

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

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

 0
Author: Your Common Sense, 2012-02-25 13:57:18

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

Как правило, я думаю, что лучший подход - использовать класс запросов и делать все свои вещи там. Таким образом, есть только одно место, где вы имеете дело с получением, отправкой, файлами COOKIE, СЕРВЕРОМ и т. Д., Что Значительно упрощает управление, в отличие от множества случайных функции, делающие разные вещи. Это просто рецепт катастрофы.

 0
Author: gus, 2012-02-25 14:23:34