usar - unescape php

PHP y mySQL: ¿Cuándo usar exactamente htmlentities?

Question

PLATAFORMA: PHP y mySQL

Para mi experimentación, he probado algunas de las inyecciones de XSS en mi propio sitio web. Considere esta situación en la que tengo mi formulario textarea de entrada. Como se trata de un área de texto, puedo ingresar texto y todo tipo de caracteres (en inglés). Aquí están mis observaciones:

UNA). Si aplico solo strip_tags y mysql_real_escape_string y no uso htmlentities en mi entrada justo antes de insertar los datos en la base de datos, la consulta se está rompiendo y recibo un error que muestra la estructura de mi tabla, debido a una terminación anormal.

SEGUNDO). Si estoy aplicando strip_tags, mysql_real_escape_string y htmlentities en mi entrada justo antes de insertar los datos en la base de datos, la consulta NO se está rompiendo y puedo insertar datos del área de texto en mi base de datos.

Así que entiendo que los servicios deben usarse a toda costa, pero no estoy seguro de cuándo se debe usar exactamente. Con lo anterior en mente, me gustaría saber:

1. ¿Cuándo se deben usar exactamente htmlentities? ¿Debería usarse justo antes de insertar los datos en la base de datos o de alguna manera obtener los datos en la base de datos y luego aplicar htmlentities cuando intento mostrar los datos de la base de datos?

2. Si sigo el método descrito en el punto B) anterior (que creo que es la solución más obvia y eficiente en mi caso), ¿todavía necesito aplicar htmlentities cuando intento mostrar los datos de la base de datos? Si es así, ¿por qué? ¿Si no, porque no? Le pregunto esto porque es realmente confuso para mí después de haber revisado la publicación en: http://shiflett.org/blog/2005/dec/google-xss-example

3. Luego está esta una función PHP más llamada: html_entity_decode . ¿Puedo usar eso para mostrar mis datos de DB (después de seguir mi procedimiento como se indica en el punto B) cuando se aplicaron los htmlentities en mi entrada? ¿Cuál debería preferir desde: html_entity_decode y htmlentities y cuándo?

PÁGINA DE VISTA PREVIA:

Pensé que podría ayudar agregar algunos detalles más específicos de una situación específica aquí. Tenga en cuenta que hay una página ''Vista previa''. Ahora, cuando envío la entrada desde un área de texto, la página Vista previa recibe la entrada y muestra su html y, al mismo tiempo, una entrada oculta recopila esta entrada. Cuando se pulsa el botón Enviar en el botón Vista previa, los datos de la entrada oculta se envían a una nueva página y esa página inserta los datos contenidos en la entrada oculta en la base de datos. Si no aplico htmlentities cuando el formulario se envía inicialmente (pero solo aplico strip_tags y mysql_real_escape_string) y hay una entrada maliciosa en el área de texto, la entrada oculta se rompe y los últimos caracteres de la entrada oculta se ven claramente como " /> en La página, que no es deseable. Por lo tanto, teniendo esto en cuenta, debo hacer algo para preservar la integridad de la entrada oculta de manera adecuada en la página de Vista previa y, sin embargo, recopilar los datos en la entrada oculta para que no la rompan. Hago esto? Disculparme por el retraso en publicar esta información.

Gracias de antemano.

Answer 1

1. Solo antes de que esté imprimiendo valor (sin importar desde DB o desde $ _GET / $ _ POST) en HTML. htmlentities no tiene nada que ver con la base de datos.
2. B es una exageración. Debería mysql_real_escape_string antes de insertar en DB, y htmlentities antes de imprimir en HTML. No es necesario que elimine las etiquetas, después de que se muestren las etiquetas htmlentities en la pantalla como <br /> etc.

Teóricamente, puede hacer htmlentities antes de insertarlo en la base de datos, pero esto podría dificultar aún más el procesamiento de los datos, si necesita texto original.

3. See above

Answer 2

Aquí está la regla general de pulgar.

Escape las variables en el último momento posible .

Desea que sus variables estén limpias representaciones de los datos. Es decir, si está intentando almacenar el apellido de alguien llamado "O''Brien", entonces definitivamente no quiere estos:

O'Brien
O/'Brien

.. porque, bueno, ese no es su nombre: no hay ampersands o barras. Cuando toma esa variable y la imprime en un contexto particular (por ejemplo: inserte en una consulta SQL o imprima en una página HTML), es decir, cuando la modifica.

$name = "O''Brien";

$sql = "SELECT * FROM people "
     . "WHERE lastname = ''" . mysql_real_escape_string($name) . "''";

$html = "<div>Last Name: " . htmlentities($name, ENT_QUOTES) . "</div>";

Nunca querrá tener cadenas htmlentities htmlentities almacenadas en su base de datos. ¿Qué sucede cuando desea generar un archivo CSV o PDF, o algo que no sea HTML?

Mantenga los datos limpios y solo escape para el contexto específico del momento.

Answer 3

En esencia, debe usar mysql_real_escape_string antes de la inserción de la base de datos (para evitar la inyección de SQL) y luego htmlentities , etc. en el punto de salida.

También querrá aplicar la comprobación de cordura a todas las entradas del usuario para garantizar (por ejemplo) que los valores numéricos sean realmente numéricos, etc. Las funciones como is_int , is_float , etc. son útiles en este punto. (Consulte la sección de funciones de manejo de variables del manual de PHP para obtener más información sobre estas funciones y otras similares).

Answer 4

He pasado por esto antes y he aprendido dos cosas importantes:

Si obtiene valores de $ _POST / $ _ GET / $ _ REQUEST y planea agregarlos a la base de datos, use la función mysql_real_escape_string para sanear los valores. No los codifique con htmlentities.

¿Por qué no simplemente codificarlos con htmlentities y ponerlos en la base de datos? Bueno, aquí está la cosa: el objetivo es hacer que los datos sean lo más significativos y limpios posible, y cuando los codificas con htmlentities como Jeff''s Dog se convierte en el "Perro de Jeff", eso hará que el contexto de los datos pierda su significado. Y si decides implementar servicios REST y obtienes esa cadena de DB y la pones en JSON, aparecerá como el Perro de Jeff, que no es bonito. Tendrías que agregar otra función para decodificar también.

Supongamos que desea buscar "Perro de Jeff" utilizando SQL "seleccione * de la tabla donde campo = ''Perro de Jeff''", no lo encontrará ya que "Perro de Jeff" no coincide con "Perro de Jeff". Mal eh

Para generar cadenas alfanuméricas (de tipo CHAR) a una página web, use htmlentities - ¡SIEMPRE!