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

XSS: Cross Site Scripting – ¿Cómo se hace?

En un post anterior, introducía los ataques de XSS, en este post comentaré algunas de las formas más habituales de realizar los ataques.

¿Cómo se hace?
Básicamente como en casi todos los ataques, la cuestión radica en encontrar alguna vulnerabilidad en el servidor objetivo. El término vulnerabilidad, para el que este familiarizado con temas de seguridad, es una forma de denominar puntos del sistema que tienen un nivel de seguridad inferior a los de su entorno. Así por ejemplo, podríamos pensar que si un servidor es una prisión de máxima seguridad, una vulnerabilidad podría ser una ventana sin rejas y completamente abierta todo el día.

En cuanto a las formas más comunes de efectuar ataques XSS, encontramos:

• SQL Injection: Quizá uno de los términos más famosos, básicamente hace referencia a la inyección de código SQL. SQL es un lenguaje para la utilización de bases de datos. Permite añadir, modificar y eliminar información.
  
  Se puede utilizar esta técnica cuando se prevee que un campo dentro de una página interviene dentro de alguna consulta en la base de datos. A modo de ejemplo, si suponemos un escenario con una página de login, por ejemplo, gmail.com; es lógico pensar que cuando ponemos nuestro nombre de usuario («usuario») y contraseña («contraseña»), el servidor tendrá que preguntar a la base de datos:

  SELECT identificador
FROM usuarios
WHERE username = 'usuario'
AND password = 'contraseña’

  En este escenario si no se comprueba que el nombre de usuario y la contraseña no sean sentencias SQL se podría escribir como contraseña password’ OR ‘x’=’x’, con lo que la consulta a la base de datos sería:

  SELECT identificador
FROM usuarios
WHERE username = 'usuario'
AND password = 'password' OR 'x'='x'

  Con esto se consigue acceder al sistema únicamente conociendo el nombre de usuario, ya que la condición de si X es igual a X siempre se cumple.

• HTML Injection: Al igual que ocurre en el ataque anterior, se puede utilizar la inyección de código HTML cuando se prevee que el dato que se introduce en algún campo del un formulario o parámetro de la web será mostrado en la página resultado. A modo de ejemplo, la forma más básica de comprobar si un buscador es susceptible a XSS por inyección de HTML es introducir en la casilla del buscador:

  <strong>test</strong>

  Si el buscado muestra en la página de resultados algo así como:

  Resultados para <strong>test</strong>
  o
  Resultados para test

  no es probable que sea susceptible a este tipo de ataques, si por el contrario muestra
  Resultados para test
  es muy probable que el servidor sea susceptible a este tipo de ataques.

• Eliminación de restricciones: Verdaderamente, este punto esta quizá en límite de lo que mucha gente consideraría un ataque de XSS por sí solo, pero al menos es complementario para poder llevar a cabo los anteriores.
  
  Básicamente, el ataque consiste en eliminar restricciones impuestas por la programación de una página web, siempre y cuando estas restricciones se lleven a cabo en el cliente. Es decir, se llevan a cabo en nuestro navegador.

  Existen muchas páginas que la validación de ciertos parámetros se lleva a cabo mediante lenguajes tipo JavaScript con el fin de por ejemplo evitar que un campo de un formulario este en blanco, que la fecha sea válida o que una cantidad sea válida.

  Dentro de la formas de explotar esta vulnerabilidad se pueden encontrar dos tipos. Se puede modificar en «tiempo real» una página web, para por ejemplo sobreescribir una función de validación y siempre de un resultado positivo. O por otro lado, se puede capturar una petición válida al servidor, modificarla a nuestro gusto y volverla a enviar.

Tengo que decir, que los puntos anteriores no profundizan mucho en los distintos ataques, con el fin de poder explicar para alguien no muy familiarizado con el tema en qué consisten estos ataques. Espero en un futuro dedicar un post o serie de post más decentes a explicar con mucha mayor profundidad estos tipos de ataques. Pero como comienzo, creo que no estan mal 🙂

En el próximo capítulo, ¿Cómo evitarlo?

Ahhh y viñeta que espero ahora entienda más gente de xkcd:

Referencias:

1. XSS: Cross Site Scripting – Introducción
2. XSSed: Archivo con ejemplos de ataques reales a distintos servidores vulnerables a Cross Site Scripting

WTF Security: La llave

Supongo que la llave es uno de las formas más básicas de implementar medidas de seguridad física. Es un sistema simple basado en tener un token real que asegure que una persona tiene acceso a un recinto, un aparato o cualquier otra cosa. El problema, pues el habitual: Alguien piensa en una forma de implementar la seguridad, ya sea llaves, contraseñas, tokens físicos, etc. Y el alguien que debe de utilizarlo piensa en como hacer que no le cueste nada utilizarlo.

Si lo pensamos esto ocurre en infinidad de sitios y da igual el ámbito. Como ejemplo límite es un buen ejercicio ir al banco o caja de ahorros y mirar el teclado de la persona que nos atiende. Lo habitual es ver una tarjeta con los códigos del día para autorizar los movimientos del día, pero yo he llegado a ver en una sucursal del BBVA un post-it, a la vista de todo el mundo con esos fantásticos códigos.

Esto viene a resumir el dicho de siempre. «Un sistema es tan fiable y seguro como su punto más débil» Y como no me gustan los post sin imágenes, pongo una foto de un ejemplo real de este tipo de situaciones. Perdón por la no-calidad de la fotografía pero esta sacada con el móvil.

XSS: Cross Site Scripting – Introducción

Para inaugurar la categoría de Seguridad, voy a dedicar varios post a hablar del XSS o Cross Site Scripting.

El cuanto a la definición de qué es el XSS tengo que decir que al igual que ocurre en muchas otras áreas de la informática, el termino no tiene una definición clara. Básicamente cada persona lo utiliza con unos matices u otros pero sin dar una definición concreta de qué es y qué no es el XSS.

Mi definición, el XSS es básicamente el intentar explotar vulnerabilidades habitualmente en entornos web mediante la inyección de código. El término inyección de código, para el que no lo sepa, hace referencia al intentar hacer ejecutar un código ajeno dentro de otro programa.

En entornos web, el XSS se traduce habitualmente como el intentar inyectar código de alguna tecnología web dentro del servidor.

Objetivo:
Al contrario de lo que suelen pensar muchas personas, el realizar un ataque contra un sistema informático no tiene siempre como objetivo la destrucción del mismo. En el caso de XSS existen varios escenarios objetivos, que yo creo se pueden resumir en:

• Destrucción de contenido: Serían ataques en su mayoría mediante SQL injection con el objetivo de destruir partes de la base de datos. Quizá es el escenario más peligroso, pero verdaderamente es el más absurdo. Hay que pensar que la ganancia de cara al atacante es el cese del servicio del elemento atacado.
• Modificación de contenido: Serían ataques destinados a modificar el contenido que es mostrado a través de la interfaz web habitual. Dentro de este tipo de ataques habría que distinguir los que se utilizan para sacar más información de la que da habitualmente el sistema y los que pretenden que esa modificación quede guardada de forma persistente dentro del servidor. Este es quizá uno de los ataques más peligrosos, ya que el poder añadir información al servidor hace posible su uso para por un lado obtener información confidencial y poder emplearla en otras tareas, y por otro lado puede abrir una futura puerta de entrada para futuros ataques.
• Utilización del entorno: Estos ataques estarían destinados a utilizar el entorno únicamente como marco o soporte para introducir nuestro propio código. Estos ataques en mi opinión son bastantes peligrosos y actualmente en aumento, ya que permite mostrar información creada por el atacante haciendo creer al usuario que esa información la proporciona el servicio habitual

Con estos escenarios se puede ver claramente que a veces el objetivo es atacar el servidor que mantiene un entorno web y otras veces el objetivo es utilizar ese entorno para realizar ataques contra los usuarios del mismo.

En el próximo capítulo, ¿Cómo se hace?

Referencias:

1. Definición XSS Wikipedia Inglés

Nueva Categoría: Seguridad

He pensado que para aumentar la organización del blog, es bueno utilizar las categorías que ofrece wordpress. En este caso he creado la categoría de Seguridad y supongo que la pregunta en este punto es: ¿Y eso de qué va?

Tengo que decir, que decir que no soy ni mucho menos un experto en temas de seguridad, pero sí que me interesan bastante y puesto que cada vez más, queramos o no, son temas importantes para la vida diaria creo que es al menos curioso el ir comentando cosillas.

En cuanto a la orientación, espero que puedan ser temas entendidos por la mayoría de los mortales. Tengo que decir, que también admito todo tema de sugerencias acerca de los temas a comentar.

Daniel