Cross Site Scripting (XSS)

[dec]

Hola,

Qué tarea más ingrata, y, sin embargo, necesaria... lo cierto es que estos problemas no los veía venir, pero, sabía de algún modo que no estaba haciendo las cosas bien. Hablo de utilizar el método "Escapar" para todo...

Llevo desde esta tarde liado con el asunto... son las 5:20 de la mañana... estoy un poco cansado, y además hoy no era el día, no era el día y se nota... El caso es que he conseguido evitar el problema de la segunda URL.

Pero, lo he conseguido a medias aún. Es algo que tengo que seguir revisando, pues se ha visto afectado no poco código fuente de la aplicación, para mi mal. Voy a tratar de ser breve pero espero explicarme. Básicamente ya lo he dicho.

El método "Escapar", concretamente, este método:

Código PHP:

    function Escapar($cadena) {
        return mysql_real_escape_string(stripslashes
         (strip_tags($cadena)), $this->enlaceConexionBd);
    } 


Ha de utilizarse cuando tratamos con consultas en la base de datos. Véase la ayuda de la función "mysql_real_escape_string". Pues bien, aunque en Loturak lo estábamos usando medio bien -entre otras cosas estoy revisando esto también- lo cierto es que usábamos este mismo método para cosas como esta:

Código PHP:

$tituloEnlace = $bdatos->Escapar($_POST['enlace-titulo']); 


Y eso es correcto (según empiezo a comprender, que puede que me equivoque) si luego vamos a utilizar la variable "$tituloEnlace" dentro de una consulta SQL. Ojo, que el "Escapar" no es lo mismo que validar la entrada... esto ha de hacerse por otro lado de todas, todas, vamos, si es menester.

Pero, también estábamos usando ese método para mostrar los propios datos de los enlaces en diferentes sitios de la aplicación... es decir, por ejemplo, mostrábamos la variable "tituloEnlace" en una casilla de formulario, pero, no sólo... que no veáis qué odisea, puesto que el problema de la segunda URL, ya sabiéndolo, no se daba sólo en las casillas de los formularios... pero en muchos otros lugares...

Y aquí es donde entreba en juego otro método Escapar... pero no para cadenas a utilizar en consultas SQL, sino para usar tal como vengo diciendo ahora...

Código PHP:

  function Escapar($entrada) {
      return htmlentities(strip_tags($entrada), ENT_QUOTES, 'utf-8');    
  } 


El compañero que me informó de todo este asunto me comentó por correo electrónico que acaso sería posible "juntar" en el método "Escapar" conque contábamos antes lo de antes y el "htmlentities",... pero, aunque esto pudiera haber funcionado, lo cierto es que el compañero olvidaba mi desastrada codificación, pues, como he dicho, estaba usando el método "Escapar" para lo que no debía usarse ni era necesario...

Bien. De mi capote añado que tratándose de consultas SQL no es preciso el "htmlentities", puesto que, como digo, bastaría con escapar las cadenas con "mysql_real_escape_string", "stripslashes" y "strip_tags", como lo hacemos ahora...

En fin. No sé siquiera si llegaré a hacerme entender... la verdad, me desperté hoy con la primera en la frente... ¿recordáis el MD5 de las contraseñas? Pues después de esa taza de caldo otra más... y de qué manera...

Así que creo que voy a dejarlo por hoy, qué coño, que me lo merezco, me parece a mí y ya está bien. Ahora, como digo, aunque aparentemente solucionados los problemas que podían causar las dos URLs indicadas al inicio, comprendo que mañana, si es otro día, me queda no poco trabajo todavía con este asunto...

Bueno. Muchas gracias a todos por vuestra ayuda. Si consideráis que me equivoco en algo me lo hacéis saber con sinceridad, ¿eh? Pues eso.

PD. Román, ciertamente, el grado de "peligro" que pudiera darse con este tema acaso no sea de alarma roja, aunque, me da en la nariz que esto del "Cross Site Scripting" puede ir mucho más allá de mostrar una "alerta" al usuario... el mismo nombre lo puede estar diciendo... pareciera algo peligroso, lógicamente, para alguien que supiera y quisiera explotar algo así.

[roman]

Empezado por dec

PD. Román, ciertamente, el grado de "peligro" que pudiera darse con este tema acaso no sea de alarma roja, aunque, me da en la nariz que esto del "Cross Site Scripting" puede ir mucho más allá de mostrar una "alerta" al usuario... el mismo nombre lo puede estar diciendo... pareciera algo peligroso, lógicamente, para alguien que supiera y quisiera explotar algo así.

Está claro que puede ir mucho más allá de un alert. A lo que me refiero es que quien resultaría afectado sólo sería el mismo que lo puso, es decir, un suicidio.

// Saludos

[dec]

Hola,

Pues muy bien puedes estar en lo cierto Román. La verdad que es que cada día que pasa estoy más verde en todo, me parece, y en esto del Cross Site Scripting... no es que esté verde,... es que da miedo pánico, precisamente, por lo desconocido que resulta para mí.

Acabo ahora de ponerme "en marcha". Vamos a ver cómo se da el día,... que ha vuelto a empezar como ayer... con una bombilla fundida en mi habitación fruto de un cortocircuito en uno de los casquillos de la lámpara... nadie cuida de estas cosas y estas cosas se estropean con el tiempo...

Vale. Seguimos en contacto.

[dec]

Hola,

Voy a hacer una serie de comentarios, explicar unas cuantas ideas, para ver si alguien puede decir "no, amigo mío, en esto y aquello estás confundido". Se lo agradeceré enormemente, puesto que quisiera que todo esto de que ahora hablaré quedara bien claro en mi cabeza.

La clase en la que me basé para llevar a cabo la clase "BDatos" que vengo utilizando ya contaba con un método "Escapar". Yo nunca hasta hoy (si puede decirse luego se verá) he comprendido el significado de dicho método "Escapar" en la clase BDatos. Por mejor decir nunca lo comprendí en su totalidad.

Yo tenía claro que el método "Escapar" no servía para validar las entradas del usuario. Esto era tarea que había que hacer, convenientemente, por separado. Sin embargo no entendía a qué se dedicaba entonces el método "Escapar", y resulta que este método ha de utilizarse para evitar "ataques" de "SQL Injection".

Hasta hace dos días estaba usando la función "mysql_escape_string", por no mirar con detenimiento en el manual de PHP, pues resulta que esta función se considera "obsoleta" y en su lugar hay que utilizar la función "mysql_real_escape_string". Recordad que con esta función pretenden escaparse determinados caracteres para evitar lo que se conoce como "SQL Injection".

Esto es lo que tenía que haber tenido claro desde un principio y nunca lo tuve hasta hoy. No se trata de "escapar" caracteres para entrarlos a la base de datos o algo parecido... se trata de evitar que una consulta SQL no contenga determinados caracteres...

Empezado por Manual de PHP

mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.

Que pueden dar lugar a inyecciones SQL, como vengo diciendo, vamos, y como se dice en el manual de PHP... que yo no leí atentamente ni mucho menos.

Al confundirme yo en ese punto, es decir, al pensar que el método "Escapar" servía para descartar "caracteres peligrosos", así, en general,... y no determinados caracteres de una cadena que luego se usará en una consulta SQL... Y NADA MÁS... como yo estaba equivocado, me puse a utilizar como un loco el método "Escapar"... para casi todo.

Por ejemplo, en la entrada del usuario de un determinado formulario... ¿qué hacía? Escapar los caracteres con el método susomentado. ¿Iba a formar parte la entrada del usuario en una consulta SQL? Ah... unas veces sí, otras veces no... no tenía ningún conocimiento,... mi intención era que en la entrada del usuario no vinieran caracteres "extraños"... y ya está.

Y ya está el lío montado, quiero decir. Porque voy a tener que repasar todo el código de la aplicación, prácticamente, como buenamente pueda, en busca de estas incongruencias.

Y menos mal que al fin y al cabo conocía la diferencia entre la validación de la entrada del usuario y su "escape"... porque lo segundo puede sobrar, pero, lo primero es imprescindible y no sólo por cuestiones de seguridad, sino también porque así lo exige la propia aplicación... por ejemplo, la descripción de un enlace no ha de contener más de X caracteres y esto hay que validarlo. ¡Pero no hay que escaparlo siempre!

Hay que "escaparlo" con el método "Escapar" de la clase "BDatos" cuando dicha descripción va a formar parte de una consulta SQL... entonces sí, pero, si no es así, si únicamente va a presentarse dicha descripción en la página Web, entonces el "escape" se hace innecesario... a lo menos es "escape" que trata de evitar el "SQL Injection"... ¿Cómo iba a darse un ataque de este tipo si no se va a llevar a cabo consulta SQL ninguna?

Y aquí es donde entramos en el "Cross Site Scripting." Es decir, la cadena que vamos a validar no se incluirá en ninguna consulta SQL, pero, sí se mostrará en la página Web... código HTML... al fin y al cabo... al que se le pueden añadir "cosas" como un evento que se dispararse cuando se pasar por encima de determinado elemento. Es decir, justo lo que el compañero que me escribió amablemente para darme luz sobre todo esto propuso en la segunda URL de ejemplo que hay al comienzo de este Hilo.

Es aquí, amigos, donde entra el "Escape" necesario, que esta vez no tiene que ver con el uso de la función "mysql_real_escape_string"... sino con la función "htmlentities", por ejemplo, junto con "strip_tags", si se me apura, o a lo que yo entiendo. Lo que pretendemos al hacer uso de esta función es evitar las posibles etiquetas PHP y HTML (?) que se incluya en la entrada del usuario, así como convertir determinados caracteres en sus correspondientes entidades HTML.

Bien. Ya termino. Os pido disculpas por el rollo. Si habéis leído hasta aquí ya tenéis valor, ya.

Este es el método "Escapar" conque ahora cuenta la clase "BDatos":

Código PHP:

    function Escapar($cadena) {
      // http://es.php.net/manual/en/function.mysql-real-escape-string.php
      if(get_magic_quotes_gpc()) $cadena = stripslashes($cadena);        
        return mysql_real_escape_string($cadena, $this->enlaceConexionBd);
    } 


Y este es el método "Escapar" conque ahora cuenta la clase "XHtml":

Código PHP:

  function Escapar($entrada) {
      return htmlentities(strip_tags($entrada), ENT_QUOTES, 'utf-8');    
  } 


Si tenéis algo que decir sobre ellos soy todo ojos. El trabajo que me queda ahora es revisar lo necesario para que dichos métodos se utilizen donde convengan y no donde no convengan. Voy a ver si no cuesta tanto como me parece que va a costar... porque sigo estando bicho, bicho, bicho. O algo peor.

Bueno. No digo nada. Agur.

[roman]

Pues a mi me parece un estupendo resumen. Si lo sacas un poco de contexto (es decir, quitas las referencias a un proyecto en particular) me parece ideal para aparecer en la sección de trucos del Club. Estas inyecciones son algo que todos deberíamos evitar y que sin embargo muy pocos sabemos no ya como hacerlo, sino de su misma existencia.

// Saludos

[dec]

Hola,

Yo creo que me ha quedado como el culo... Y la verdad es que no tengo todo demasiado claro... de hecho sigo trabajando en esta cuestión... y lo que te rondaré morena. Seguiremos informando. Gracias Román.

[roman]

Creo que hay un problemita dec. Digamos que tu consulta es

Código SQL [-]
select * from usuarios where usuario = 'pepe el toro'

Al aplicarle la función Escapar queda así:

Código SQL [-]
select * from usuarios where usuario=\'pepe el toro\'

Y esto no lo acepta MySql.

// Saludos