Categories
.NET Desarrollo de Software Utilidades Windows Forms

Zoner & Seguridad de Acceso a Código

Los que han estado desarrollando aplicaciones de escritorio con .NET, seguramente saben que el CLR es el encargado de lo que puede o no hacer una aplicación en función a los permisos que reciba.

Code Access Security

Por si no saben todavía de la existencia de Zoner, ésta es una pequeña herramienta que permite probar si una determinada aplicación funciona o no en una zona determinada.

Este es el código de Zoner:

csharp:

using System;
using System.Reflection;
using System.Security;
using System.Security.Policy;

class App
{
    public static void Main(String[] args)
    {
        try
        {
            SecurityZone zone = SecurityZone.Internet;
            String url = "http://www.IBuySpy.com";
            String exe;
            String[] newArgs = null;

            for (Int32 index = 0; ; index++)
            {
                if (args[index][0] != '-' && args[index][0] != '/')
                {
                    exe = args[index];
                    newArgs = new String[args.Length - (index + 1)];
                    Array.Copy(args, index + 1, newArgs, 0, newArgs.Length);
                    break;
                }

                String setting = args[index].Substring(3);

                switch (args[index].ToUpper()[1])
                {
                    case 'Z': // Set zone
                        zone = (SecurityZone) Enum.Parse(typeof(SecurityZone), setting, true);
                        break;
                    case 'U': // Set url
                        url = setting;
                        break;
                    default:
                        throw (new ApplicationException());
                }
            }
            StartApp(exe, newArgs, zone, url);
        }
        catch (ArgumentException)
        {
            Usage();
        }
        catch (IndexOutOfRangeException)
        {
            Usage();
        }
        catch (ApplicationException) { Usage(); }
    }
    static void Usage()
    {
        Console.WriteLine(
           "Usage: zoner /u:[url] /z:[zone] [Executable File]\n" +
           "[url]\tUrl indicating the source of this .exe");
        Console.WriteLine();
        Console.Write("[zone]");
       
        String[] zones = Enum.GetNames(typeof(SecurityZone));
        foreach (String zone in zones)
        {
            Console.WriteLine("\t{0}", zone);
        }
        Console.WriteLine(
           "\nDefault:  zoner /u:http://www.IBuySpy.com /z:Internet");
    }
   
    static void StartApp(String exe,
       String[] newArgs, SecurityZone zone, String url)
    {
        Evidence evidence = new Evidence();

        evidence.AddHost(new Zone(zone));
        evidence.AddHost(new Url(url));
        AppDomain app = AppDomain.CreateDomain(exe, evidence);
        app.ExecuteAssembly(exe, evidence, newArgs);
    }
}

Lo que hace esta porción de código, es simplemente ejecutar en otro dominio la aplicación que se quiere probar, pero adjuntando información de la zona escogida.

Espero que esta pequeña utilidad les ayude a ahorrar un poco de tiempo :).

Categories
Perú Varios

Charla sobre Plataformas de desarrollo y administradores de contenidos

Si alguien que reside en Perú lee este pequeño blog, puede que le interese ir a charla sobre plataformas de desarrollo y administradores organizada por la ANWMP.

Los temas a tratar son:

El evento se llevará a cabo el día 2 de marzo en el auditorio de CONCYTEC (Calle del comercio 197, San Borja), de 4 a 7 p.m.

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.