Cómo mitigar un ataque de scripts entre sitios

Si considera que su red es suficientemente segura para desactivar el filtro de contenido activo, utilice una de las opciones de configuración que se describen en este tema para mitigar un ataque en caso de que se produzca.

Acerca de esta tarea

Si decide inhabilitar el filtrado de contenido activo en favor de proporcionar una mayor flexibilidad, deberá realizar pasos para contener un ataque de scripts entre sitios (XSS). Por ejemplo, su organización podría pensar que en tanto que la exposición XSS sólo está limitada al sitio de su blog, el riesgo es asumible. Si éste es el caso, considere la posibilidad de adoptar los siguientes métodos recomendados para contener un ataque:
Usar dominios aislados
Asegúrese de que el componente con riesgo de ataque se instale en un dominio completamente independiente. Por ejemplo, si la aplicación Blogs permite la publicación de contenido activo, instálela en un dominio independiente como por ejemplo: blogs.acme.org. Si la aplicación Actividades permite contenido activo, instálela en un dominio independiente como por ejemplo: activities.acme.org. Asimismo, puede utilizar varios dominios para una sola aplicación, utilizando un dominio diferente para las descargas de archivos de la aplicación.
No utilizar inicio de sesión único
Para contener cualquier ataque, asegúrese de que la autenticación de inicio de sesión único (SSO)no se utiliza para autenticar un usuario en una aplicación que permite contenido activo. Cuando se habilita el inicio de sesión único, se puede almacenar una cookie de usuario y utilizarla para acceder a los datos de otro dominio. Aunque no es recomendable utilizar el inicio de sesión único cuando un componente tiene desactivado el filtrado de contenido activo, es posible utilizar el inicio de sesión único con cookies de tipo Sólo HTTP. WebSphere Application Server versión 6.1.0.11 presenta la posibilidad de generar cookies de tipo "Sólo HTTP" para las cookies de inicio de sesión único. Si esta aplicación se utiliza conjuntamente con un navegador sólo HTTP, la vulnerabilidad XSS podrá contenerse.
Configure los archivos para que se descarguen desde un dominio diferente
Añada reglas de reescritura al archivo de configuración de IBM® HTTP Server para forzar que los archivos descargados sean reconocidos por el navegador web como contenido que es independiente de la aplicación y que, por lo tanto, se debe tratar como tal. Si no se realizan las descargas en un subdominio con una autenticación no compartida, existe una vulnerabilidad ya que otro tipo de contenido puede permitir que se ejecute el contenido con las credenciales del dominio de alojamiento. Un ejemplo de otro tipo de contenido que se puede ejecutar en dominio alojado es Adobe Flash. Si se utiliza Flash Player 9, todo el Flash alojado podrá llamar a los servicios del dominio de alojamiento y ejecutar ataques XSS. Con Flash Player 10, si se utiliza la disposición de contenido en línea continúa existiendo esta vulnerabilidad. Blogs utiliza esta modalidad de disposición de contenido, por lo tanto, para una seguridad máxima en Blogs, se debe utilizar un dominio de descargas diferente o se debe inhabilitar Flash.
Si opta por configurar un subdominio para las descargas de archivos, determine si habilita o no el inicio de sesión único entre el subdominio y el dominio de la aplicación principal:
  • Si opta por habilitar el inicio de sesión único, configure las cookies sólo de HTTP. Para hacer esto, lleve a cabo los pasos siguientes:
    1. Abra WebSphere Application Server Integrated Solution Console.
    2. Expanda Seguridad y seleccione Seguridad global.
    3. Pulse Propiedades personalizadas.
    4. Pulse Nuevo para añadir una propiedad y luego añada los siguientes valores a los campos:
      Nombre
      com.ibm.ws.security.addHttpOnlyAttributeToCookies
      Valor
      true
    5. Pulse Aplicar y luego Aceptar.
  • Si opta por no habilitar el inicio de sesión único, se solicitará a los usuarios que se vuelvan a autenticar cuando descargan un archivo.
Consulte Especificación de un dominio de descarga de archivos diferente para obtener información acerca de cómo crear el subdominio.
  • Especificación de un dominio de descarga de archivos diferente
    Los archivos añadidos a las aplicaciones Actividades, Blogs, Wikis, Foros o archivos podrían contener potencialmente código pernicioso que puede aprovechar las vulnerabilidades de los scripts entre sitios de algunos navegadores. Puede añadir reglas de reescritura al archivo de configuración de IBM HTTP Server para forzar que los archivos descargados sean reconocidos por el navegador web como contenido que es independiente de la aplicación y, por tanto, se ha de tratar como tal.
Tema principal: Protección de las aplicaciones frente a ataques perniciosos
Tareas relacionadas:
Mostrar archivos en línea
Especificación de un dominio de descarga de archivos diferente