XSS: Cross Site Scripting – ¿Cómo evitarlo?

En un post anterior, hablaba de tipos básicos de ataques de XSS, la pregunta que normalmente aparece en la mente después de leer eso es ¿cómo lo evito?En general, y dada la importancia de estos ataques, la mejor defensa es una buena prevención. Esto aunque suene quizá a "muy buenas prácticas" es verdaderamente un hecho. La idea fundamental para evitar XSS es:

Todas las entradas proporcionadas por el usuario deben de ser validadas antes de ser utilizadas.

Pero como la idea fundamental habitualmente es olvidada, creo que un checklist es mucho más clarificante. Decir que como siempre, el checklist contiene una serie de puntos que pueden ser comprobados, pero no pretende ser una lista completa ya que muchas cosas dependen de tecnologías web concretas, simplemente unos primeros sitios por donde empezar.

• Bases de datos
  • Evitar que se puedan ejecutar más de una sentencia SQL en un mismo comando.
  • Utilización de Prepared Statements: ¿Y eso qué es? Básicamente el término prepared statement hace referencia a un tipo de consultas SQL que no se ejecutan concatenando cadenas de caractares.El funcionamiento es primero construir el esqueleto de la sentencia SQL y luego decir qué parametros van en cada punto.

    De esta forma el ejemplo anterior quedaría:

    SELECT identificadorFROM usuariosWHERE username = ? AND password = ?

    Ahora sólo quedaría decir qué es cada uno de los parámetros, lo importante es que en esta operación se dice de qué tipo son los mismos, por lo que por ejemplo introducir un número cuando se espera un cadena daría error. En Java por poner un ejemplo, se realizaría con:

    preparedStatementObject.setString(1, "usuario");
preparedStatementObject.setString(2, "contraseña");

  • Comprobar las entradas aunque hayan sido comprobadas en la parte cliente. El objetivo sería prevenir posibles problemas relacionados con buffer overflows.
• Servidores o Aplicaciones Web
  • HTTPS no evita XSS. HTTPS es un protocolo que asegurará que la conexión entre el servidor y el cliente es segura, pero no asegura nada de los datos intercambiados.
  • Filtrado de código HTML que se permite introducir por los usuarios. Esto es especialmente problemático en componentes encargados de los comentarios en un blog o foro.
  • Se puede utilizar un pre-filtrado en código cliente (que será ejecutado en el navegador del usuario), pero sólo como medida adicional de prevención.
  • Evitar utilizar sólo parámetros que viajan con la página para autenticar un usuario. El ejemplo más típico es que aunque exista un parámetro &ID=[cadena de caracteres], eso sólo debe ser utilizado como media adicional
  • En ocasiones sería recomendable comprobar el campo REFERER de la petición HTTP para saber de dónde viene una petición, pero también hay que tener en cuenta que es un campo opcional.
  • Evitar filtrar por codificaciones, este ejemplo quizá parezca bastante absurdo, pero se dan casos donde por ejemplo se filtra por ejemplo un tag que contenga javascript, pero no se filtra jav[caracter x09]ascript y a efectos prácticos es lo mismo.

Y aquí acaba la introducción a XSS, espero que al menos no haya resultado excesivamente técnico Como comentario final, simplemente añadir que al final lo mejor es estar al tanto de los ataques que se realizan. El tema de seguridad, siempre es un mundo que se mueve deprisa y en el que algo que se hacía hace un año o 1 mes, es muy probable que ya no tenga validez.

Referencias:

1. Tutorial Prepared Statements en Java
2. XSS Cheatsheet con ejemplos varios
3. XSS: Cross Site Scripting – ¿Cómo se hace?
4. XSS: Cross Site Scripting – Introducción

Java 6 en Leopard = WTF

La verdad, creo que ahora sí que siento algo de cabreo en el mismo nivel que en mis tiempos en Windows. Todo comienza al intentar instalar la versión 6 del JDK de Java. En Tiger (versión anterior del SO), el proceso era básicamente ir al Apple Developer Connection y bajarse JavaSE6Release1.pkg para instalarlo.

El problema es que ahora no existe tal paquete en el Apple Developer Connection, los últimos paquetes disponibles para su descarga hacen referencia a actualizaciones de J2SE 5.0, por lo que ahora mismo no es posible localizar un instalador de Java 6.

Creo que esto es altamente inaceptable, y espero que se solucione pronto. En un principio me he puesto en contacto con Apple Developer Connection, con Apple Support y con Sun y estoy a la espera de noticias, por lo que iré actualizando el post a medida que conozca nuevas cosas.

PS: No creo que nunca más sea un early-adopter de nuevas versiones, al final es mejor esperar una semana o dos y ver qué efectos tienen la novedades

Actualización: ¿Quién es el culpable?

He estado viendo cosillas por Internet y al final, creo que hay algo que no esta claro, la víctima en este caso es el usuario o mejor dicho desarrollador que se ve sin su entorno deseado, pero ¿quién es el culpable? Por un lado, se podría decir que Apple por no dar la opción de instalar Java 6, pero por otro lado, Apple se encarga de sus productos como cualquier fabricante. ¿No sería Sun? La verdad es que en este punto no se a quién determinar como culpable. Tampoco me parece lógico que Sun se olvide de Mac en su página de descargas (no he encontrado ninguna referencia a MacOsX tanto Tiger como Leopard). ¿Opiniones?

Actualización: Información de Apple

Parece que con el perfil actual que tengo dentro del Apple Developer Connection, no es posible acceder a los denominados Software Seed Keys, qué básicamente vienen a ser una forma de tener acceso a versiones pre-release de distintos software. Así por tanto, espero que en un futuro próximo sea posible a la descarga de Java 6 con el perfil normal. Tampoco sé realmente si existe un pre-release de Java 6, es simplemente una suposición, ya que todo el tema del ADC esta bajo aceptación de licencias de confidencialidad y por tanto la información esta bastante limitada. En fin, al menos he recibido respuesta de Apple, que a mi parecer no es poco.