Cross Site Scripting (XSS)

[[seoane]]

Empezado por dec

¿Cómo se consigue al cabo que se ejecute el JavaScript?

Pues insertando el script dentro del código de tu pagina.

Donde debería de aparecer esto:

<a href="/compartir?p=1" title="Mostrar la página anterior">

Pasa a aparecer esto otro

<a href="/compartir?demo"><script>alert(123)</script>=&amp;p=1" title="Mostrar la página anterior">

En tu código php tienes esto

$url = Servidor::PhpSelfSinExtension() .'?';
$url .= Servidor::PropagarVariblesGet(APP_VAR_REQUEST_NUM_PAGINA_ENLACES);
$url .= APP_VAR_REQUEST_NUM_PAGINA_ENLACES.'=';
$url = Servidor::UrlParaXhtml($url);

Como ves metes todas las variables get sin comprobar si algún listo añadió alguna por su cuenta.

Y en este otro tramo:

<a href="'.$url.$i.'" title="'._r('Mostrar la página siguiente').'">

Así que aprovecha esto para insertar parámetros de mas en la url, estos parámetros contienen caracteres como < y " que tu insertas directamente en tu pagina. De esta manera cierra la etiqueta del enlace e inserta el código del script.

Empezado por dec

¿Hasta qué punto compromete la seguridad esto?

Un script podría hacer que en tu pagina se mostraran cosas que no tienen nada que ver contigo. Con el consiguiente riesgo que esto conlleva. Por ejemplo Cross Site Scripting se utiliza para el phising.

[[seoane]]

Vale, todo mi trabajo de detective a la porra ...

[dec]

Hola,

Para nada Seoane. Ni mucho menos.

Por otro lado la segunda URL es curiosa. Se consigue el mismo efecto escribiendo en la casilla de búsqueda de Loturak: demo" onmouseover=alert(123) "

Al cabo en la página se termina escribiendo el siguiente código:

<input name="b" value="demo\" onmouseover="alert(123)" \="" id="casillabusqueda" class="inputtext" type="text">

Y el evento, lógicamente, funciona...

Y acabo de confirmar lo que me temía... funciona lo mismo con el resto de casillas de formularios... acabo de probar con el formulario para añadir enlaces y funciona... ¡ay diosito ayúdame!

[dec]

Hola,

Vale. Pues la segunda cuestión (la que plantea la segunda URL) se me está atragantando. Y es que si en el primer caso podíamos actuar en un mismo punto, en una función en concreto, en este segundo caso no parece que sea así.

He conseguido escapar la cadena de búsqueda (en que se incluye el JavaScript) con la función "htmlentities", de manera que aparentemente se soluciona el tema. Empero, he dicho antes que todas las casillas de los formularios de la aplicación están comprometidas...

Y sólo hay una función que "controle" cada una de estas casillas. El método "Escapar" que hemos visto antes. Sin embargo, aunque pareciera que esto iba a servir de ayuda, en realidad no lo parece. Véase el método "Escapar" tal y como está ahora:

Código PHP:

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


Pues bien, si lo dejáramos tal que así:

Código PHP:

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


Funcionaría por un lado, es decir, ya no tendría efecto el JavaScript de las casillas, de las variables que nos llegasen vía "HTTP GET", quiero decir, pero,... ay diosito si es que todo lo hago mal...

Resulta que el mismo método "Escapar" que usamos para las variables que nos llegan de entrada, también lo usamos cuando mostramos la información de dichas variables en las correspondientes casillas.

Me explico. Cuando vamos a mostrar la búsqueda realizada por el usuario escribimos en la casilla de búsqueda la búsqueda actual... o sea, trabalenguajes aparte, hacemos algo como esto:

Código PHP:

$casillaBusqueda = $bdatos->Escapar(BUSQUEDA); 


Pero, al hacer esto, pareciera que la función "htmlentities" codificara la cadena que se muestra en la propia casilla, de manera que esta no se muestra bien... creo que una imagen vale más que mil palabras en este caso.

Conseguimos que el JavaScript no tenga efecto, pero, los datos de las casillas se muestran malamente:



Total,... yo llevo creyendo hace tiempo que igual que usamos un método "Escapar" deberíamos utilizar un método "Desescapar"... o que en todo caso no estamos haciendo un buen uso del método "Escapar"... lo usamos un poco sin ton ni son, me parece a mí...

[dec]

Hola,

Bueno. Disculpad mi pesadez, pero, es que me parece curioso, la verdad. Respecto del problema con la segunda de las URLs resulta que no ocurría sólo en las casillas de los formularios... no. Cuando se realiza una búsqueda en la página Web de que hablamos se indica al usuario que los enlaces están filtrados por dicha búsqueda.

Una de las formas en que se indica es haciendo uso de diversos iconos, que tienen un "título", es decir, cuando el usuario pasa el ratón por encima le aparece el típico "hint" que le muestra algo como: "Buscando enlaces por: Delphi". Donde "Delphi" es la cadena que se está buscando.

Pues bien, lo mismo que para las etiquetas, servía para los de los títulos, así que en la medida de lo posible lo estoy corrigiendo, aunque tengo que revisar algunas cosas. Empero,... lo de las casillas... en fin. Seguiremos informando.

[roman]

No sé yo si diré una burrada, pero a mi me parece que no hay por qué preocuparse por este segundo tipo de "ataque". Por un lado parece más difícil de evitar porque no intervienen etiquetas html, sólo atributos, pero por otro, me da porque a quien "afecta" es sólamente al que le apetezca colocar tal texto en la caja, pero a nadie más, no al menos mientras esta información no se guarde permanetemente en algún lugar.

// Saludos

[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í.