2010-09-03 20 views
5

Estoy muy confundido por algo y me preguntaba si alguien podría explicarme.¿Validar la entrada del usuario?

En PHP valigo la entrada del usuario para que htmlentitiies, mysql_real_escape_string se use antes de insertar en la base de datos, no en todo, ya que prefiero usar expresiones regulares cuando puedo, aunque me parece difícil trabajar con ellas. Ahora, obviamente, usaré mysql_real_escape_string cuando los datos entren en la base de datos, pero no estoy seguro si debería usar htmlentities() solo al obtener datos de la base de datos y mostrarlos en una página web, al hacerlo alterar los datos ingresados ​​por una persona que no mantiene su forma original, lo que puede causar problemas si quiero usar esa información más adelante para usarla en otra cosa.

Así que, por ejemplo, tengo un libro de visitas con 3 campos nombre, tema y mensaje. Ahora, obviamente, los campos pueden contener cualquier cosa como código malicioso en etiquetas js, básicamente, cualquier cosa, ahora lo que me confunde es decir que soy una persona malintencionada y decidí usar etiquetas js y código malicous js y enviar el formulario, ahora básicamente tengo maliciosos datos inútiles en mi base de datos. Ahora, al usar htmlentities al enviar el código malicioso a la página web (libro de visitas), eso no es un problema porque htmlentities lo ha convertido en su equivalente seguro pero a la vez tengo un código malicioso inútil en la base de datos que preferiría no tener.

Entonces, después de decir todo esto, mi pregunta es si debo aceptar el hecho de que algunos datos en la base de datos pueden ser dañinos e inútiles y siempre que use htmlentities en la salida todo estará bien o ¿debería estar haciendo otra cosa? .

He leído tantos libros que dicen sobre filtrar datos al recibirlos y escapar de ellos para que se guarde el formulario original, pero solo dan ejemplos como asegurar que un campo sea solo un int usando funciones ya compiladas en php etc. Nunca encontré nada en cuanto a garantizar algo así como un libro de visitas en el que desee que los usuarios escriban lo que quieran, pero también cómo los filtraría aparte de mysql_real_escape_string() para garantizar que no rompa la consulta DB.

¿Podría alguien finalmente cerrar esta confusión por mí y decirme lo que debería hacer y cuál es la mejor práctica?

Gracias a cualquiera que pueda explicarlo.

¡Salud!

Respuesta

2

Ésta es una pregunta mucho, pero creo que lo que en realidad estás pidiendo se reduce a: "¿Debo escapar de HTML antes de insertarlo en mi base de datos, o cuando voy a mostrarlo"

La respuesta generalmente aceptada a esta pregunta es que debes escapar del HTML (a través de htmlspecialchars) cuando se va a mostrar al usuario, y no antes de ponerlo en la base de datos.

La razón es esta: una base de datos almacena datos. Lo que estás poniendo es lo que el usuario tipeó.Cuando llama al mysql_real_escape_string, no altera lo que se inserta en la base de datos; simplemente evita interpretar la entrada del usuario como declaraciones SQL. htmlspecialchars hace lo mismo con HTML; cuando imprima la entrada del usuario, evitará que se interprete como HTML. Si llamaras al htmlspecialchars antes del inserto, ya no serás fiel.

Siempre debe esforzarse para tener la representación de máxima fidelidad que puede obtener. Desde el almacenamiento del código "malicioso" en su base de datos no hace daño (de hecho, le ahorra espacio, ya que el código HTML escapado es más largo que sin protección), y es posible que en el futuro desee ese HTML (¿qué pasa si usa un Analizador XML sobre los comentarios de los usuarios, o algún día dejar que los usuarios de confianza tengan un subconjunto de HTML en sus comentarios, o algo así?), ¿Por qué no dejarlo?

También puede preguntar un poco sobre otros tipos de validación de entrada (restricciones enteras, etc.). El esquema de la base de datos debe imponerlos, y también se pueden verificar en la capa de aplicación (preferiblemente en la entrada a través de JS y luego nuevamente en el lado del servidor).

En otra nota, la mejor manera de hacer escapes de bases de datos con PHP es probablemente usar PDO, en lugar de llamar directamente al mysql_real_escape_string. PDO tiene una funcionalidad más avanzada, incluida la comprobación de tipos.

1

mysql_real_escape_string() es todo lo que necesita para las operaciones de la base de datos. Garantizará que un usuario malintencionado no pueda insertar algo en los datos que "romperán" sus consultas.

htmlentities() y htmlspecialchars() entran en juego cuando se está trabajando con el envío de cosas al cliente/navegador. Si desea limpiar un HTML potencialmente hostil, sería mejor que use HTMLPurifier, que despojará los datos al lecho de roca y lo manará con blanqueador y lo reconstruirá adecuadamente.

+0

Wow, gracias Marc B, nunca supe que obtendría una respuesta tan rápida. Gracias por su aporte voy a verificar ese enlace, pero también esto lo ha aclarado todo. Afortunadamente, mi sitio es muy pequeño, así que no te preocupes, pero al menos ahora puedo cambiar mi código donde sea necesario y hacer básicamente lo que pensé que necesitaría hacer con tu confirmación, así me siento seguro ahora que estoy en la pista del rito :) Obviamente, si alguien más quiere agregar otras sugerencias, por favor. PS. Gran deseo de sitio que encontré hace siglos, simplemente registrado :) – PHPLOVER

+0

Nunca es demasiado pronto para empezar a trabajar en la seguridad e integridad de los datos. Realmente no hay mucho para eso, pero cuanto antes adquiera el hábito de tratar cualquier cosa que provenga del exterior como desechos tóxicos, mejor. Como una capa adicional de seguridad, es posible que desee investigar el uso de declaraciones preparadas y PDO, a menos que tenga que generar consultas que no se ajusten a sus límites. –

+0

Gracias Marc y todos los demás, Realmente he respondido todas mis preguntas y más, he aprendido de hacer esta publicación y me siento relajado por decir lo menos :) Todos ustedes han sido de gran ayuda, así que gracias a todos ustedes. – PHPLOVER

0

No hay razón para preocuparse por tener código JavaScript malicioso en la base de datos si está escapando el código HTML cuando aparece. Solo asegúrate de que siempre escapas de todo lo que sale del DB.

Cuestiones relacionadas