Category: Seguridad

Artículos y opiniones sobre seguridad Web, SQL Injection, XSS, etc.

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
PHP Seguridad Web

Marzo, el mes de los bugs de PHP

Tal y como lo había comentado Stefan Esser luego de su salida de PHP Security Response Team, él revela en una entrevista realizada en securityfocus.com, que en marzo se liberarán alrededor de 31 bugs presentes en el código de PHP.

We will disclose different types of bugs, mainly buffer overflows or double free(/destruction) vulnerabilities, some only local, but some remotely trigger-able (for example, because they are in functions usually exposed to user input). Additionally there are some trivial bypass vulnerabilities in PHP's own protection features. Only holes within the code shipped with the default distribution of PHP will be disclosed. That means we will not disclose holes in extensions that only exist in PECL, while we are sure that those contain vulnerabilities, too. Most of the holes were previously disclosed to the vendor, but not all.

Probablemente se generará mucha polémica por la liberación de estos bugs, habrá que ver como se desenvuelven las cosas.

Categories
Quiz Seguridad

Ejercicio de la Semana: Visualización de perfiles

Continuando con la serie, pongo otro script para que se diviertan.

php:

<?php
include_once './config.php';

if ( empty($_REQUEST['id']) && empty($_REQUEST['nick']) ) {
    die('No user selected');
}

if ( isset($_REQUEST['nick']) ) {
    if ( preg_match('/^[a-z0-9]{3,20}$/i', $_REQUEST['nick']) ) {
        $where = "WHERE nick='" . $bcdb->escape($_REQUEST['nick']) . "'";
    }
    else {
        die('Invalid nick: ' . $_REQUEST['nick']);
    }   
}
elseif ( !preg_match('/\d+/i', $_REQUEST['id']) || ($id = $bcdb->escape($_REQUEST['id'])) < 0 ) {
    die('Invalid user id: ' . $id);
}
else {
    $where = "WHERE id='$id'";
}

if ( ! ($user = $bcdb->get_row("SELECT * FROM users $where")) ) {
    die("User does not exists");
}

header('Content-type: text/html; charset=utf-8');
?>
<html>
<head>
    <title>Profile: <?php echo $user->name; ?></title>
</head>

<body>

<dl>

    <dt>Nombre</dt>
    <dd><?php echo $user->name; ?></dd>

    <dt>Email</dt>
    <dd><?php echo $user->email; ?></dd>
   
    <dt>Página Web</dt>
    <dd><a href="<?php echo $user->url; ?>"><?php echo $user->url; ?></a></dd>
</dl>

</body>

</html>

¿Existe algún problema con el código mostrado? Si es así, ¿cuál o cuáles?

Nota: A sugerencia de Agustí, he puesto una página de prueba. Si desean ver el código fuente de los ficheros php, aumenten una s al nombre. Ej http://test.buayacorp.com/quiz/user.phps

Actualización: Cambios realizados

  • Comillas simples agregadas alrededor de la variable id
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.