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

Question

PLATAFORMA: PHP MySQL &

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

A). 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 está rompiendo y me aparece un error que muestra la estructura de mi tabla, debido a la terminación anómala.

B). 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 está rompiendo y puedo insertar datos del área de texto en mi base de datos.

Por lo tanto, entiendo que las funciones se deben usar a toda costa, pero no se sabe exactamente cuándo se deben usar. Con lo anterior en mente, me gustaría saber:

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

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), aún tengo que aplicar htmlentities cuando intento mostrar los datos de la base de datos ? Si es así, ¿por qué? ¿Si no, porque no? Lo pregunto porque es muy confuso para mí después de haber pasado por el puesto en: http://shiflett.org/blog/2005/dec/google-xss-example

3. Luego está esta función una más llamada PHP: 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) ya que htmlentities se aplicó en mi entrada? ¿Cuál debería preferir de html_entity_decode y htmlentities y cuándo?

previa de la página:

pensé que podría ayudar a añadir algunos detalles más específicos de una situación específica aquí. Considere que hay una página 'Vista previa'. Ahora cuando presento la entrada desde un área de texto, la página Vista previa recibe la entrada y la muestra html y, al mismo tiempo, una entrada oculta recoge esta entrada. Cuando se presiona el botón de enviar en el botón Vista previa, los datos de la entrada oculta se transfieren 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 se aplican 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 visiblemente como " /> en la página , lo cual es indeseable Así que, teniendo esto en cuenta, tengo que hacer algo para preservar la integridad de la entrada oculta correctamente en la página de Vista previa y aún recopilar los datos en la entrada oculta para que no la rompa. ¿Cómo hago esto? Disculpa por el retraso en publicar esta información.

Gracias de antemano.

Answer 1

Esta es la regla general.

Variables de escape en el último momento posible.

Desea que sus variables sean representaciones nítidas de los datos. Es decir, si usted está tratando de almacenar el apellido de alguien llamado "O'Brien", entonces definitivamente no quiere siguientes:

O'Brien 
O\'Brien 

.. porque, bueno, eso no es su nombre: no hay ampersands o barras en él. Cuando toma esa variable y la emite en un contexto particular (por ejemplo: insertar en una consulta SQL o imprimir en una página HTML), que es 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 se desea tener htmlentities cadenas codificados con almacenadas en su base de datos. ¿Qué sucede cuando desea generar un CSV o PDF, o cualquier cosa que no sea HTML?

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

Answer 2

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

También deseará 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. (Vea la sección variable handling functions del manual de PHP para más información sobre estas funciones y otras similares.)

Answer 3

1. Sólo antes de imprimir el valor (no importa de DB o desde $ _GET/$ _ POST) en HTML. htmlentities no tienen nada que ver con la base de datos.
2. B es exagerado. Debe mysql_real_escape_string antes de insertar en DB, y htmlentities antes de imprimir en HTML. No es necesario pelar las etiquetas, después htmlentities etiquetas se mostrarán en la pantalla como < br /> etc

Teóricamente es posible hacer htmlentities antes de insertar a DB, pero esto podría hacer más difícil el procesamiento de datos, si necesitaría texto original.

3. See above 

Answer 4

He pasado por esto antes y aprendí dos cosas importantes:

Si usted está recibiendo valores de $ _POST/$ _ GET/$ _ REQUEST y planificar para añadir a DB, utilice la función mysql_real_escape_string para desinfectar los valores . No los codifique con htmlentities.

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

Suponga que desea buscar "Jeff's Dog" con SQL "select * from table where field = 'Jeff \' s Dog '", no lo encontrará porque "Jeff's Dog" no coincide con "Jeff & es perro ". Malo, ¿eh?

Para enviar cadenas alfanuméricas (desde el tipo CHAR) a una página web, use htmlentities - SIEMPRE!