php - magic_quotes_gpc - ¿Por qué WordPress todavía usa addslashes(), register_globals() y magic_quotes?

security escaping

Question

Para obtener más experiencia en Wordpress, profundicé en su código base para estudiar su funcionamiento interno y su flujo de trabajo, y quedé bastante asombrado cuando vi que:

1. Implementan register_globals (un extracto de 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. Se basan en comillas mágicas (ejercicio de wp-includes / functions.php. Magic_quotes_gpc se desactiva en el arranque, antes de llamar a esta función):

   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. Se basan en addslashes (pero desde 2.8.0 introdujeron también mysql_real_escape_string, pero la función _weak_escape() que usa addslashes() aún existe en la clase wpdb)
   ACTUALIZACIÓN: veo que emulan las declaraciones preparadas mediante el uso de sprintf() y los marcadores de posición personalizados, por lo que las consultas deberían ser seguras, creo. Todavía estoy desconcertado sobre por qué no proporcionan al menos mysqli, después de todo la detección de la versión de Mysql y PHP ocurre temprano en la secuencia de arranque .

Ahora, desde la frecuentación de un año de SO, aprendí muchas cosas, especialmente que las tres funciones anteriores están "en desuso" y muestran problemas de seguridad, y muchos ven mi horror.

Pero WP debe tener una razón para usarlos. Me gustaría saber de programadores más experimentados si realmente hay problemas de seguridad, o si a veces su uso está demasiado nublado en rumores y falsas declaraciones. Sé que magic_quotes es una herencia del pasado, y lo mismo podría decirse de addslashes (al menos cuando se usa para bases de datos), pero mientras buscaba en Google antes de preguntar esto, encontré muchos sitios web que hablaban de usar addslashes () sobre mysql_real_escape_string ().

Estoy interesado en conocer una razón clara y detallada sobre por qué se usan esas funciones mal representadas; Wordpress había tenido muchas mejoras a través de los años, abordando diferentes aspectos, y aun así estas funciones todavía se usan; Estoy buscando, por lo tanto, una explicación concreta sobre los aspectos positivos que de alguna manera anulan los negativos y justifican el uso de esas funciones.

No estoy buscando opiniones (sé perfectamente que son atípicas aquí), ni estoy despotricando sobre Wordpress, espero que esto esté claro. Me gustaría saber por qué muchos programadores de php consideran que estas funciones son "malas" y, sin embargo, un gigante mundial como Wordpress, que ahora está en la tercera versión, todavía las usa.

¿Esto es compatible con diferentes servidores y versiones de php? (sin embargo, revisan muy earl para esos).
¿Hay algo que extraño sobre estas funciones, qué tan importantes pueden ser en un entorno como wordpress (o en general)? Estoy bastante confundido, para ser honesto.

Answer 1

En complemento a la respuesta @tom.

Cotizaciones Mágicas

Analizar automáticamente las entradas completas y agregar citas mágicas crea errores e inútiles.

• Inútil ya que no puede confiar en las citas mágicas para proteger su entrada (los errores de codificación de varios bytes para inyecciones de SQL son un ejemplo). Por lo tanto, debe aplicar un filtro real antes de guardar sus datos en una base de datos
• Crear errores: si necesita realmente escapar de sus datos antes de guardarlos en la base de datos, debe verificar que no se hayan escapado (y el simple hecho de que esta configuración exista y pueda ser aplicada por el entorno de alojamiento) hace que tenga que verificar que esta configuración establecer o no).
• Crear errores: todos los datos enviados por el usuario no siempre están dedicados a un almacenamiento de base de datos. Escapar puede romper el contenido, pensar en un contenido json por ejemplo, o incluso archivar contenido con el peligroso magic_quote_runtime
• Crear errores: todo el almacenamiento de la base de datos no se escapa de las citas de la misma manera ...

¿ Por qué? ¿Por qué vemos esa función en un CMS?

• vea que aquí se trata de una función add_magic_quotes , que se puede usar en una matriz dedicada, tal vez no en _GET o _POST. Pero efectivamente, el hecho de que esta función solo esté usando addslashes y no una función dedicada de base de datos lo hace bastante malo.
• El hecho de que el proveedor de alojamiento web pueda aplicar una cotización mágica automática es una pesadilla para un desarrollador de CMS. O lo detecta y le dice al usuario que se niega a ejecutar, o tiene que gestionar el hecho de que el contenido puede o no haber sido mágicamente agregado ... y para poner a todos en el mismo estado, ejecuta el contenido no agregado en esta función para que al menos todos estén en el mismo (mal) estado.
• Por lo que puedo ver en Wordpress, antes de guardar se realiza stripslahes_deep en wp_insert_post. Y add_magic_quotes generalmente se realiza en datos extraídos de Db antes de que estos datos se envíen a wp_insert_post. Esto puede hacerme pensar que el problema es, efectivamente, agregar barras antes de eliminarlas ... tal vez porque desinfecte los filtros que suceden antes de guardar el contenido esperado con barras, o quizás porque nadie recuerda por qué el código se está ejecutando de esta manera :-)

register_globals

Parece que esta es la forma de implementar un patrón de registro en wordpress ... Querían que el código fuera simple de entender, y permitir una forma simple de acceder a los objetos importantes como la consulta o la publicación. Y una clase de registro orientada a objetos no estaba en la forma simple de PHP , donde la matriz $_GLOBALS ya es un registro existente.

Tener un registro es una cosa perfectamente válida en una aplicación. una cosa register_global es peligrosa solo si permite que alguna entrada del usuario anule su entrada segura válida. Y, por supuesto, solo si esta entrada segura se toma de $_GLOBALS otro lugar (o con palabra clave global ).

La parte peligrosa de la función aquí es la parte de la función que ha extraído, el ciclo en $query->query_vars . Tendrá que rastrear las llamadas para ver si las claves inyectadas por el usuario podrían ejecutarse a través de wp_parse_args y finalizar en esa función. Pero la siguiente parte de esta función es arreglar el contenido $_GLOBALS para varios objetos:

$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;

Por lo tanto, al menos estas tesis globales no se pueden sobrescribir con la entrada del usuario y son seguras .

Entonces, estas funciones son malas. Pero puedes usarlos si entiendes lo que hacen y lo que debes hacer para evitar los malos efectos. Y cuando desea implementar un marco simple para desarrolladores, disponible en entornos muy amplios, a veces debe usarlos.

Pero seguro que es una mala práctica, sin duda puede encontrar los plugins malos de wordpress usando $ _GLOBALS de la manera incorrecta o haciendo un uso indebido de los add_magic_quotes to data pulled from db concepto add_magic_quotes to data pulled from db wordpress. Pero habrá años antes de que un CMS de Zend Framework haya ganado una gran cantidad de contribuciones.

Answer 2

Este es el lugar equivocado para hacer tal pregunta.
Siempre es una mala idea preguntarle a una tercera persona las razones por las cuales alguien más tuvo otro lugar.

Es obvio que no puede obtener una respuesta aquí a menos que atraiga a algún desarrollador autorizado de WordPress aquí con tal recompensa.

Sin embargo, tu pregunta es demasiado amplia. Sin embargo, es posible responder a su parte abstracta:

Me gustaría saber de programadores más experimentados si realmente hay problemas de seguridad, o si a veces su uso está demasiado nublado en rumores y falsas declaraciones.

¿El lavado de manos realmente previene una enfermedad?
¿Qué pasa si no me lavo las manos? ¿Seguro que estoy enfermo?

La mayor parte del tiempo - no.
Como un hábito general, sí.

Estas características (aunque, de hecho, como cualquier otra característica de nuestro desafortunado lenguaje, demasiado oscurecidas por los rumores) son meramente una higiene que todos deben seguir como instinto básico.

Aunque la mayor parte del tiempo ...

• Los addslashes no causarán ningún daño siempre que su codificación sea utf-8 o cualquiera de byte único;
• registrar globales no hará ningún daño si inicializas todas tus variables;
• las comillas mágicas no causarán ningún daño siempre que tengas todas las variables citadas para el SQL y las barras despojadas para cualquier otro uso;

... cualquier excepción a estas circunstancias puede enfermarte con alta probabilidad.

Answer 3

Lo hicieron por una razón:

Para asegurarse de que Wordpress sea compatible con la mayoría de los proveedores de alojamiento web.

Answer 4

Una de las principales diferencias entre mysql_real_escape_string () y addslashes es que mysql_real_escape_string () funciona junto con el conjunto de caracteres para que sepa cómo escaparse correctamente de los datos en función del conjunto de caracteres.

En general, creo que el mejor enfoque es usar una clase de solicitud y hacer todas tus cosas allí. De esta forma, solo hay un lugar donde tratas con GET, POST, COOKIE, SERVER, etc., lo que hace que sea mucho más fácil de administrar, en contraste con tener un montón de funciones aleatorias haciendo cosas diferentes. Esa es solo una receta para el desastre.

Answer 5

Wordpress. He pasado muchas noches sin dormir tratando de responder la única pregunta: "¿Por qué?"

Desde que me enfrenté con su código fuente, lo odio. Es horrible. Y dejar que mi publicación (y reputación también) se minused pero es verdad.

No tiene núcleo. Hay una basura de código en lugar de núcleo. Recuerda php3. Un enorme montón de funciones no relacionadas y no lógicas se utilizan en él. "Copiar y pegar": el único patrón de diseño se usa en wordpress.

Sí, han emulado el uso de declaraciones preparadas. Pero ¿por qué no usan PDO o mysqli? Han copiado casi todas las funciones de PDO, pero no las han utilizado en su lugar. El uso de mysqli en lugar de mysql requiere aún menos esfuerzos.

Usan myql_real_escape_string. Pero todavía hay algo como protect_string_strongly , protect_string_weakly . No solo hay una función única: do_not_protect_string_i_believe_my_users .

Variables globales: es la filosofía de wordpress. "Si no sabemos cómo cambiar esta var, la marcaremos como global var y todos estarán contentos". - Aquí está lo que los desarrolladores de wordpress pensaron cuando desarrollaron hellpress.

Cada nueva versión contiene muchas novedades en el diseño, agregan nuevos temas predeterminados, cambian el color de fondo en el área de administración de #ccc a #cdcdcd, usan el menú desplegable en el área de administración en lugar de accordeon. Y es increíble. Pero no mejoran su código.

¿Leyó comentarios en WP "core"? ¿No? Y lo hice. Ellos son "asombrosos" Algo así como "¿Para qué sirve esta función? Déjalo ir por si acaso". o "No codificarlo en una nueva versión". y así.

La única respuesta a la pregunta "¿Por qué?" Tengo es: "Porque funciona. Y si funciona, ¡no lo toques!"

wordpress.org es uno de los sitios más visitados del mundo. ¿Por qué? Porque nadie puede entender la lógica de WordPress. Todo el mundo necesita preguntar algo en el foro o leer en el códice.

Espero que entiendas mi punto de vista.

Answer 6

Cotizaciones Mágicas

El siguiente texto está tomado de PHP.net

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

No hay ninguna razón para usar citas mágicas porque ya no son una parte compatible de PHP. Sin embargo, existieron y ayudaron a algunos principiantes felizmente y sin saber escribir un código mejor (más seguro). Pero, cuando se trata de código que se basa en este comportamiento, es mejor actualizar el código en lugar de activar comillas mágicas. Entonces, ¿por qué existió esta característica? Simple, para ayudar a prevenir la inyección SQL. Hoy los desarrolladores conocen mejor la seguridad y terminan usando mecanismos de escape específicos de la base de datos y / o declaraciones preparadas en lugar de confiar en funciones como las comillas mágicas.

addslashes () vs mysql_real_escape_string ()

La razón por la que debe usar mysql_real_escape_string() es porque es una "función MySQL" y se crea especialmente para escapar de la entrada del usuario antes de que se ejecute en una consulta mysql, mientras que addslashes() es una "función PHP". Eso probablemente sonaba un poco raro, pero hay una diferencia importante entre los dos y tiene que ver con el uso de caracteres de un solo byte y múltiples bytes. Todavía puede inyectar bases de datos protegidas por la función addslashes, pero inyectar bases de datos protegidas por mysql_real_escape_string es mucho más difícil. Puedes leer más al respecto HERE

Regístrese Globales

La razón por la que NO debes usar register_globals es porque las variables son accesibles para todos, lo que significa que en el siguiente ejemplo podrás establecer $ access en true si no se ha inicializado antes

<?php
if (isAuthenticated()) { $access = true; }
if ($access == true) {
include(controlpanel.php);
}
?>

¡El código anterior te daría sh #! un montón de problemas, pero si inicializamos la variable primero añadiendo lo siguiente a la parte superior de la página

$access = false;

... deberíamos estar bien incluso si tenemos register_globals en ON

Entonces, si el equipo de Wordpress ha inicializado todas las variables (que probablemente tengan), entonces no tiene que preocuparse por el uso de globales.

Conclusión

Definitivamente es una mala práctica usar cualquiera de esas 3 funciones / características y nunca lo haría yo mismo. ¿Estás seguro de que estás trabajando con la última versión de Wordpress? Al igual que alguien comentó, si está utilizando la última versión es por pereza o peor aún está ahí. Nunca usaría Wordpress para nada más que blogs que no requieren mucha seguridad ...

Answer 7

No hay mejor manera de responder por qué son malos que consultar la documentación de PHP en magic_quotes :

• http://www.php.net/manual/en/security.magicquotes.why.php
• Por qué no usar Magic Quotes

También tenga en cuenta:

Esta característica ha sido DEPURADA a partir de PHP 5.3.0. Confiar en esta característica es altamente desaconsejado.

Entonces, ¿por qué Wordpress todavía usa Magic Quotes?

Los requisitos mínimos de Wordpress usan PHP 4.3 . Sí, es absolutamente una razón de compatibilidad con versiones anteriores.

¿Y las otras funciones?

Sinceramente, no estoy seguro. Confiar en súper globales es una muy mala idea. Esto es simplemente pereza del equipo de desarrollo de Wordpress. Tal vez tengan problemas más importantes para trabajar.

Answer 8

( Entradas abiertas de Wordpress a lo largo del tiempo )

No confíe en la base de código de Wordpress para hacer suposiciones sobre buenas prácticas o estándares actuales en codificación PHP. Lo digo como alguien que ha jugueteado con el desarrollo de wordpress durante un período de tiempo más largo.

La base de código de Wordpress tiene aproximadamente 10 años, está llena de código heredado ^[1] . El programa no puede evolucionar en el nivel de código mucho debido a eso, por lo que hoy en día encontrará muchas soluciones para problemas que ya están resueltos.

Solo toma esta historia: PHP tenía citas mágicas. Los desarrolladores de Wordpress pensaron que era útil. Entonces, para aquellos hosts que no lo tenían configurado, lo agregaron. Finalizando con un código que espera recortar datos de entrada a menudo y en varios lugares. Lo simple es que ahora simplemente no pueden cambiarlo a un procesamiento de entrada y sanitización adecuado fácilmente debido al uso de (super) globales que introducen un estado global estático en casi todas partes.

No puede refactorizar fácilmente dicho código.

Lo mismo para la clase de base de datos. Tiene una larga historia, originalmente basada en una versión temprana de ezSQL. En ese momento no había mysql_real_escape_string y cuando se presentó, los desarrolladores de WP tuvieron el problema de que no todas las bases de instalación lo admiten.

Así que no te preocupes por la práctica de codificación que encuentras dentro del código de Wordpress. Aprenderá cómo se podrían haber hecho las cosas hace años y con versiones PHP más o menos obsoletas. No hace tanto que Wordpress cambió a PHP 5, por ejemplo.

• Compatibilidad al revés.
• Apunte a una gran cantidad de hosts (técnicamente más obsoletos).
• No rompa lo que funciona con defectos.

Esta podría no ser su lista de prioridades (con suerte), los proyectos difieren mucho aquí. Pero tener solo una base de código heredada es una carga independientemente de cómo se establezcan las prioridades del proyecto. Wordpress es solo un ejemplo.

^[1] ver Hitos de WordPress: Early Project Timeline (circa 2000 a 2005) )