Categories
.NET ASP.NET Firefox Internet Explorer Seguridad Web XSS

Mitigar el robo de cookies a través del atributo HttpOnly

El Service Pack 1 y las versiones posteriores de Microsoft Internet Explorer 6 admiten la propiedad HttpOnly para las cookies, que puede ayudar a mitigar las amenazas a las secuencias de comandos entre sitios que originan cookies robadas. Las cookies robadas pueden contener información confidencial que identifique al usuario en el sitio, como el id. de sesión de ASP.NET o el vale de autenticación mediante formularios, que el atacante puede reproducir para hacerse pasar por el usuario u obtener información confidencial. Cuando un explorador compatible recibe una cookie HttpOnly, ésta resulta inaccesible para la secuencia de comandos de cliente.

Establecer la propiedad HttpOnly no evita que un atacante con acceso al canal de la red obtenga acceso a la cookie directamente.

Tal como se puede observar en la cita, al usar este tipo de cookies se ofrece más protección para evitar robo de los mismos a través de ataques XSS, puesto que no es posible acceder a los valores marcados con este atributo desde javascript.

En ASP.NET 2, para habilitar esta característica, se puede hacer a nivel individual o para todas las cookies de la aplicación.

Para el primer caso, sólo es necesario asignar en true la propiedad Secure del cookie.

csharp:

Response.Cookies["test"].Secure = true;

Para que esta característica englobe a todas las cookies de la aplicación, simplemente hay que cambiar la propiedad httpOnlyCookies de la sección httpCookies del Web.config

xml:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <compilation debug="false"/>
    <authentication mode="Forms">
      <forms name="__auth" defaultUrl="default2.aspx" cookieless="AutoDetect" path="/" loginUrl="default.aspx">
      </forms>
    </authentication>
    <authorization>
      <deny users="?"/>
    </authorization>
    <httpCookies httpOnlyCookies="true"/>
  </system.web>
</configuration>

Al hacer estos cambios, las cabeceras que se envían al cliente son las siguientes:

code:

HTTP/1.1 200 OK
Server: ASP.NET Development Server/8.0.0.0
Date: Tue, 13 Feb 2007 13:03:29 GMT
X-AspNet-Version: 2.0.50727
Set-Cookie: test=foo; path=/; secure; HttpOnly     ---> el atributo secure es por Response.Cookies["test"].Secure = true;
Set-Cookie: demo=5; path=/; HttpOnly
Cache-Control: private
Content-Type: text/html; charset=utf-8
Connection: Close

Si se quisiera utilizar este tipo de cookies desde otros lenguajes que no dan soporte para esta característica, lo único que se tiene que agregar en las cabeceras es el texto HttpOnly luego de definir nuevas cookies, por ejemplo en PHP podríamos hacer algo como lo que sigue*.

php:

setcookie('foo', 'test', null, '/;HttpOnly');

Por el momento esta característica está disponible de manera nativa sólo en Internet Explorer, para Firefox tenemos que hacer uso de extensiones como las de Stefan Esser, que en realidad sólo renombra las cookies y encripta el contenido de éstas.

* Al parecer en PHP 5.2 ya hay un soporte para esta característica.

Categories
Humor Seguridad Web XSS

Cosas que te pueden pasar cuando reportas un bug

Es la primera vez que me pasa algo así luego de reportar un bug sobre XSS.

Este es el mensaje que escribí:

Hola,

Existe una vulnerabilidad de tipo XSS en leavesedo.php, esto es
causado porque no filtran adecuadamente el valor de la Url a la que
quieren redirigir.

Prueba de concepto (muestra un mensaje /XSS/):
http://tinyurl.com/2yf8jr

La respuesta:

Estimado Alex,

Le comunicamos que no hemos entendido correctamente su pregunta. Le rogamos
que nos vuelva a enviar un email concretizando más su asunto o problema para
que podamos ayudarle a solucionarlo.

Para más información, no dude en ponerse en contacto con nosotros.

Saludos cordiales,

El Equipo de Sedo

Seguramente tengo parte de culpa al escoger la dirección de correo al que escribí y porque en mi mensaje tampoco está muy claro sobre que trata el asunto, pero me resulta muy curiosa esta respuesta :D.

Categories
.NET ASP.NET Desarrollo de Software Microsoft Web XSS

Cross Site Scripting en ASP.NET y la respuesta de Microsoft

Luego de haber reportado el pequeño bug sobre XSS en asp.net a través de Microsoft Connect, finalmente dijeron que no corregirán ese bug para la siguiente versión de .NET Framework (orcas) por motivos de compatibilidad con versiones anteriores.

En la respuesta -bastante común por cierto- hacen referencia a esta entrada escrita por S. Somasegar en la que se comenta que se realizarán cambios mínimos para la siguiente versión.

Entonces, por lo pronto queda a responsabilidad de los desarrolladores tomar las medidas necesarias para evitar el problema descrito en una entrada anterior.

Nota: el bug necesita intervención del usuario y -me parece que- sólo funciona en Firefox.

Categories
Seguridad XSS

¿Por qué algunos desarrolladores se complican la vida?

Esta semana definitivamente no me fue muy bien, primero porque dejé algunas cosas pendientes en el trabajo y segundo porque -como se habrán dado cuenta- no escribí mucho esta semana, pensaba hacerlo a partir del lunes, pero al ver la solución que le dieron al bug mostrado en la entrada anterior, no puedo dejar de comentar acerca de ésta 😉 .

Por alguna extraña razón, siguen permitiendo insertar HTML en la variable backURL, sólo que esta vez se basaron en algunos ejemplos básicos de la popular página que contiene diferentes vectores de ataques XSS, digo esto porque si usamos un ejemplo anterior que funcionaba, ahora ya no lo hace.

Paso a comentar dos ejemplos que funcionan en Internet Explorer (existen otros para otros navegadores):

  1. En la entrada anterior usamos <EMBED SRC="http://ha.ckers.org/xss.swf" AllowScriptAccess="always"></EMBED> como valor para la variable backURL, con el cual era posible ejecutar javascript, pero si hacemos la prueba en este momento, este valor es descartado por contener la palabra embed. Una forma de saltar esa validación es insertar algo entre esa palabra, pero que ese algo todavía permita ejecutar javascript, si volvemos a nuestra página de referencia :), podemos ver que el caracter nulo (código ASCII 0) sirve para este propósito. Ejm.
  2. Este caso es aún más simple, porque hace uso de CSS -no estandar- para ejecutar javascript. Ejm

Esta lista podría ir creciendo dependiendo de las peculiaridades de cada navegador, lamentablemente los desarrolladores de esa página, usaron una solución compleja e ineficiente para un problema simple de resolver.

Si hay algo que me enseñaron desde mis inicios, es que no sirve corregir un problema en particular -mucho menos si éste depende de otras aplicaciones o componentes, se tiene que cortar el problema de raiz.

Categories
Seguridad XSS

XSS (Cross Site Scripting) en elpais.com

Hace cierto tiempo puse un quiz titulado "cuando los filtros no hacen lo que deberían", en el que preguntaba como explotar la casi nula validación de una variable. Pues bien, ese ejemplo hacía referencia al bug que existe en el sitio web del diario El País de España.

La URL afectada recibe como parámetro la variable backURL, que -supongo- sirve para redireccionar a esa URL una vez hecha la validación de los datos: http://www.elpais.com/clientes2/conectar1.html

Al parecer por la acción de un filtro, esta página envía un error (404) cuando backURL contiene en cualquier ubicación la palabra <script, pero por lo que se ve, los desarrolladores no se dieron cuenta de que existen otros vectores de ataque.

No tengo idea sobre el impacto de este bug en ese sitio, pero lo que está claro es que muchas empresas no le dan demasiada importancia a esto de la seguridad, ya que han pasado aproximadamente 3 meses desde que reporté este problema y hasta el momento ni lo han solucionado, ni he recibido respuesta alguna.