XSS Cross-site Scripting (II)

()

—Perdona por la interrupción. Como te decía, desde el punto de vista de Alicia, hay poco que pueda hacer. Puede desactivar la ejecución de script en su navegador, lo que la dejará sin poder visitar muchas de las páginas que le interesan. Puede activarlo sólo para los sitios de confianza, asumiendo que éstos no son vulnerables a este tipo de ataques (lo que es mucho asumir) y, por supuesto, ser sanamente desconfiada para evitar la parte de ingeniería social del ataque. Y poco más. La responsabilidad está en quienes han desarrollado el sitio web vulnerable, que deben corregir la aplicación Web para que no lo sea.
—¿Se puede conseguir eso?
—Claro. El éxito del ataque se basa en que el sitio Web devuelve el código script que se le inyecta y que se ejecuta en el navegador de Alicia. Basta con no hacerlo.
—¿No devolver el script que luego se ejecuta?
—Ese es el enfoque que siguen muchos desarrolladores. Aplicar “html encoding“. ¿Sabes lo que significa?
—Sí, claro, se trata de “escapar” un carácter especial de un código html para que se muestre como tal, en lugar de ser interpretado por el navegador. Se utiliza siempre que se muestran ejemplos de html en un sitio Web.
—Exacto. Si quiero que en una página salga “<br />” en lugar de un salto de línea en el navegador, debo escribir “&lt;br /&gt;”, ya que esa secuencia tiene un significado especial. He de indicarle al navegador que no debe interpretarla, sino mostrarla, utilizando &lt; para “<" y lo mismo con el resto de caracteres. —Entonces, basta con “escapar" todos los caracteres especiales. —En principio. Claro que eso tiene el inconveniente de no permitir al usuario que introduzca negritas, cursivas o enlaces dentro de su texto. Quizás un inconveniente aceptable. —Bueno, se pueden permitir algunos de los caracteres especiales o, mejor dicho, determinadas combinaciones, como “<a href=", pero no otras, como “<script>". —Sí, claro. Es la táctica de detectar las entradas no deseables y eliminarlas o neutralizarlas. El problema es que hay más formas de introducir un script en un texto de manera que no se detecte con facilidad. Por ejemplo, se puede introducir “%3D%3C%73%63%72%69%70%74%3E", que es lo mismo que “<script>", como parte de una URL. Pero lo peor es que puedes estar protegiendo la aplicación frente a determinadas formas de introducir un script, pero luego aparecer en el futuro otras que no tenías previstas y no ser capaz de detectarlas. —Pero seguro que sabes una solución y me la vas a contar… —Pues la solución es obvia, si aplicamos una de las buenas prácticas de programación que cualquier buen desarrollador conoce: validar cualquier entrada del usuario contra una especificación de las entradas correctas. O sea, admitir lo que es correcto según las especificaciones del programa y rechazar cualquier otra cosa. —Usando expresiones regulares. —Es uno de los métodos más útiles, sí. —En resumen, que el XSS se evita controlando bien todas las entradas a la aplicación, validándolas según la especificación de lo que se considere una entrada correcta. —Ni más, ni menos.

Comments

  1. Bueno, puede que Alicia pueda hacer algo, si utiliza Firefox :-)

    LocalRodeo -> Evita la redirección de un portal original a otro mediante la ejecución no deseada de un código javascript.
    https://addons.mozilla.org/es-ES/firefox/addon/5055

    NoScript -> Esta utilidad permite bloquear la ejecución de cualquier tipo de script permitiendo solo aquellos que provengan de ciertos dominios de confianza de esta forma se evitan ataques por XSS (sig)
    https://addons.mozilla.org/es-ES/firefox/addon/722

    Firekeeper -> Is an Intrusion Detection and Prevention System for Firefox. It is able to detect, block and warn the user about malicious sites. Firekeeper uses flexible rules similar to Snort ones to describe browser based attack attempts.
    http://firekeeper.mozdev.org/

    Aunque este último no parece tener mucho movimiento …

    Por supuesto, si Alicia configura cierta página web como de confianza pero resulta vulnerable … -> Navegación segura en base a máquinas virtuales – ¡Una máquina virtual para cada página web que visitas y tendrás a salvo tus datos!

  2. Claro que puede bloquear la ejecución de scripts, salvo en sitios de confianza, pero no acabo de ver a un “usuario medio” de la red instalándose ese plugin, ni gestionando la lista blanca de sitios de confianza (¿en base a qué criterio?), ni sabiendo lo que es XSS, etc. En mi opinión, es más de lo que se debe pedir que sepan hacer los usuarios. Y encima, si la web de confianza tiene la vulnerabilidad, ¿cómo se le queda el cuerpo a Alicia?

    Creo que la responsabilidad es de los desarrolladores.

    Lo de la máquina virtual por sitio web es buena idea (capto la ironía ;-P), pero luego querremos que se comuniquen entre ellas y volveremos a estar donde antes.

  3. Después del batacazo de Vista (!?), está claro que al usuario medio no le gustan los avisos incordiantes que aparecen como pop-ups o como sea.

    Coincido que la responsabilidad es de los desarrolladores pero este riesgo siempre va a existir, con lo cual hay que vivir con ello y una de las posibles soluciones es contar con otro desarrollador que haga un plugin para tu navegador web, pero de momento no es transparente al usuario (de hecho dos de los plugins anteriores son testing o alpha).

    Alicia tendrá que seguir pendiente de la Reina de Corazones.

  4. Alberto Hervalejo says

    Muy buena explicación :) Una vez intenté aprender en que consistía, y menudo lío. Gracias :)