strip_tags o mysql_real_escape_string?

[cocodj69]

He leído algunos artículos acerca de la seguridad respecto a LA ENTRADA DE TEXTO DE LOS USUARIOS EN LOS FORMULARIOS.

Para insertar información en la BBDD algunos dicen que utilices la función strip_tags y otros mysql_real_escape_string. Creo que sería mejor utilizar la segunda, pero me gustaría que me ayudarais en decantarme por una o otra?.

Para visualizar información de la BBDD, existen las funciones htmlspecialchars() y htmlentities(), siendo ambas buenas con la diferencia de que la segunda convierte a HTML más carácteres que la primera. Me he decantado por la primera; supongo que será suficiente.

Un saludo y grácias

[enlinea777]

todo depende del uso.
lee mi firma

[pateketrueke]

así es... definitivamente debes comprender la diferencia de ambas funciones, que ni siquiera sirven para lo mismo por ende no hay comparación alguna...

pues strip_tags() puede funcionar contra ataques XSS/CSRF, mientras que mysql_real_escape_string() evita inyecciones SQL, ¿si notas que no es lo mismo??

[cocodj69]

Supuestamente mysql_real_escape_string sólo sirve para las comillas simples y dobles, pero me pregunto si deberia utilizar la funcion strip_tags para guardar la info en la BBDD?. Utilizo htmlspecialchars para el formato de salida.

¿Es recomendable convertir las etiquetas previa insercíón en la BBDD? o Utilizando htmlspecialchars para el formato de salida ya es suficiente?

Grácias

[pateketrueke]

Iniciado por cocodj69

Supuestamente mysql_real_escape_string sólo sirve para las comillas simples y dobles, pero me pregunto si deberia utilizar la funcion strip_tags para guardar la info en la BBDD?. Utilizo htmlspecialchars para el formato de salida.

¿Es recomendable convertir las etiquetas previa insercíón en la BBDD? o Utilizando htmlspecialchars para el formato de salida ya es suficiente?

Grácias

supuestamente!!

vamos, que así supuestamente por la vida no se debe andar...

con respecto a la duda strip_tags/htmlspecialchars se responde sola... claro, si leyeras el manual de PHP ...

si usamos strip_tags() eliminamos las etiquetas HTML posibles... así que usar htmlspecialchars() esta de sobra... ya que no quedan caracteres HTML especiales para codificar...

si entiendes eso... pues que bien, supuestamente...

[cocodj69]

Muchas grácias paketetrueke,

lo de supestamente era una forma de hablar!! :)

Me ha quedado todo claro, pero una pregunta: ¿que es mejor convertir las etiquetas antes de introducir la info en la BBDD o cuando lo mostramos por pantalla? Supongo que sería más beneficioso realizarlo en el formateo puesto que así la información no ocupa tanto espacio en la BBDD pero la mismo tiempo la información sería más vulnerable a ataques XSS/CSRF. Por tanto, ¿Más practico ejecutar la función strip_tags?

Grácias!!

[blogger]

Aquí lo interesante es el uso que le quieres dar, y el como lo vas a aplicar. Pues, por ejemplo, si lo vas a usar en un textarea con un editor de textos, no te conviene quitar las etiquetas del HTML. Así que consideralo bien.

[Hidek1]

claro ahorras un poco de espacio en la bd pero cada ves que muestres el contenido tendras que pasar por una funcion demas =)
piensa que seria mejor..

[cocodj69]

Grácias de nuevo!!

En caso de ser info de editores de texto no lo convierto. :)

Para los demás casos, el aplicar la función antes o despues de guardar la información dependerá de muchos casos. Bien es verdad que si no lo aplico antes de guardarlo en BBDD tendré que aplicar la función cada vez que se muestre por pantalla, algo que no me gusta!! Será por tanto mas inteligente aplicar la función strip_tagss al guardar la info y así, como ya ha dicho un compañero, aseguarar la aplicación contra ataques XSS/CSRF, que los desconozco y, por tanto, tendré que investigar más sobre ellos.

¿Pero que ocurre, por ejemplo, si aplicamos la función strip_tags sobre el Nombre de un Usuario el cual la longitud del campo en la base de datos es de 64 carácteres y al aplicar la función strip_tags excede el número de carácteres máximo permitido? La consulta fallaria!! Por tanto, ¿Que se suele hacer en estos casos?

[pateketrueke]

Iniciado por cocodj69

[...] ¿Pero que ocurre, por ejemplo, si aplicamos la función strip_tags sobre el Nombre de un Usuario el cual la longitud del campo en la base de datos es de 64 carácteres y al aplicar la función strip_tags excede el número de carácteres máximo permitido? La consulta fallaria!! Por tanto, ¿Que se suele hacer en estos casos?

estas errado... en todo caso (por favor, lee el manual) la función strip_tags() elimina los tags HTML en la cadena, por lo cual... no agrega nada, mas bien.... quita!!

en estos casos, debes usar strip_tags() sobre aquellas variables que no necesitan de HTML, osea... si, un email, nick, etc... (:

ahhh, y por cierto... lo que se suele hacer en estos casos es: consultar el manual y dejar de imaginar cosas sin base...

[Hidek1]

¿Pero que ocurre, por ejemplo, si aplicamos la función strip_tags sobre el Nombre de un Usuario

o.O?

estas medio confundido
a menos que en su de nombre de usuario ponga <span/> no pasara nada x3

[cocodj69]

Muchisimas grácias!!

Siento haber sido algo inoportuno!!

Grácias ya lo tengo claro

[nshadow]

Colega, te diria que las funciones que usas estan bien pero no te da una seguridad realemnte suficiente. Lo que se esta haciendo con estas funciones es sanizar la entrada, o sea escapar caracters potencialmente peligrosos. Ahora lo que habria que hacer es efectuar una validacion de entrada y salida. La validacion es:
1: canonicalizacion: es convertir un entrada en un formado unico, utf-8 por ejemplo
2: sanizacion: es escapar los caracteres potencialmente peligroso y que tienes que permitir, puedes hacerlo con las funciones que propones. Obviamente si no tienes que permitir estos caracteres no necesitas escaparlos ya que en la siguiente fase los detectaria y no acpetas la entrada. Por ejemplo, la comilla en un email no hay que permitirla, pero en un apellido puede que se tenga que permitir, entonces si hay que permitirla se escapa
3: validacion datos entrada y salida: es verificar que lo que te llega es lo que te espera. o sea hay que verificar espacio de caracteres o rango de numeros, formado, tamaño,...Por ejemplo si esperas un identificador (un numero) tienes que verificar que este en el rango de interos.si esperas un email tienes que verificar que es formado sea email , la longitud maxima que permites para este campo y el espacio de caracteres (por ejemplo de a-z mas del 0-9 y algun caracter de puntuacion); esto puedes hacerlo con expresiones regulares.
tambien podrias comprobar que no te estan colando mas direcciones separadas con punto y coma o cosas del estilo.

Hacer una correcta validacion es algo costoso pero es lo que hay que hacer.
Si luego quieres comprobar si es aun posible efectuar ataques de sql injection o XSS, puedes usar herramientas de test de intrusion. hay desde free como xss me o similares a de pago como la de watchfire (que es algo cara). Si quieres monitorizar constantemente tu portal para dormir tranquilo puedes usar el servicio de Security Guardian: http://security-guardian.com,
yo lo tengo y es fenomenal. Es gratuito y lo que hacen es testear periodicamente tu WEB y puedes ver los resultados y solucciones para las vulnerabilidades que detecta desde la consola de administracion que dan (es muy completa y e intuitiva). Ademas te certifican el portal y gracias al sello que te day y que pones en tu web logras un aumento de confianza de tu cliente o visitante y esto se traduce en un aumento en las ventas o altas en el caso que no vendas.
Por cierto la calidad de los escaneos en brutal, nada a que ver con las demas solucciones en el mercado!!!
Espero que te haya ayudado la respuetsa.

[Hidek1]

1: canonicalizacion: es convertir un entrada en un formado unico, utf-8 por ejemplo

concuerdo contigo.. ese punto es poco mencionado pero bastante importante, ya que en si no lo haces y el usuario logra enviarte informacion en utf7 por ejemplo, los signos de < y > no van a ser cambiados ya que no son iguales en ambas codificaciones..

saludos!