Entradas en la categoría: Internet Explorer

Internet Explorer eliminará la activación manual de controles ActiveX en Abril de 2008

Por: alex | 9 Noviembre 2007 | 1 Comentario

Hace más de un año, Microsoft tuvo que cambiar la forma en que los controles ActiveX eran cargados, este hecho -- causado por un litigio con Eolas Technology -- hizo que muchos desarrolladores web sorteen este problema usando javascript para evitar que los usuarios tengan que activar manualmente los controles.

Internet Explorer: Activación de controles ActiveX

En el blog de Internet Explorer anuncian que a partir de abril del próximo año ya no será necesario la intervención del usuario para activar los controles ActiveX; según ésa entrada, este cambio de funcionalidad en el navegador no va a requerir de modificaciones a los sitios existentes y que a partir de diciembre de este año, estará disponible "Internet Explorer Automatic Component Activation Preview" (¡vaya nombrecito! :D ).

Tags: , , , ,

Cookies

Por: alex | 30 Agosto 2007 | 4 Comentarios

Una cookie es un fragmento de información que se almacena en el disco duro del visitante de una página web a través de su navegador, a petición del servidor de la página. Esta información puede ser luego recuperada por el servidor en posteriores visitas.

No suelo darle importancia a las novedades de Internet Explorer, pero hoy me pareció interesante algunos consejos que dan desde el blog de éste navegador para reducir el tráfico HTTP que se produce entre un servidor y un cliente.

Antes de continuar, estas son las nuevas limitaciones que impone Internet Explorer para el manejo de Cookies:

  • Se incrementó de 20 a 50 el número de cookies que se puede crear por dominio.
  • document.cookie retornará una cadena vacía si el tamaño de las cookies es mayor a 4096 bytes.
  • El navegador ignorará las cabeceras Set-Cookie si éstas exceden de 5118 bytes.

Volviendo al tema anterior, éstos son los consejos que sugieren para reducir el tráfico HTTP:

  • Reducir el tamaño de las cookies: Recomiendan utilizar nombres y si es posible, valores más cortos. Ejm. en lugar de una cookie denominada username, usar sólo u.
  • Servir el contenido estático desde otro (sub)dominio: Una vez que el servidor envía las cookies usando la cabecera Set-Cookie, un navegador convencional enviará de vuelta estos valores en cada petición que se haga al servidor. Como los valores de las cookies son irrelevantes para los archivos estáticos, entonces se genera tráfico innecesario.
  • Usar el atributo path sólo cuando sea necesario: El atributo path permite manejar cookies para rutas específicas de un dominio, por ejemplo si se envían cookies para la ruta /aplicacion, entonces en el servidor se podrá acceder a estos valores sólo desde esa ruta *. Usar este atributo en general va a depender de los requerimientos de la aplicación, pero si quieres ahorrar unos cuantos bytes entonces haz que la ruta sea para todo el dominio.

Las resultados de estos consejos seguramente van a ser más evidentes en sitios con mucho tráfico que en sitios como éste, donde el número de lectores se puede contar con los dedos de la mano. :D

*: En realidad se puede acceder a todos los datos de la petición y por consiguiente a todas las cookies, pero de manera convencional algunos lenguajes abstraen esta funcionalidad para dar acceso sólo a las cookies definidas para una ruta.

XSS y las peculiaridades de los navegadores

Por: alex | 5 Junio 2007 | 0 Comentarios

Hay ocasiones en que la forma como interpreta HTML un navegador puede producir algunos problemas de seguridad, esto normalmente se debe a descuidos de un programador que asume cierta funcionalidad.

Veamos el siguiente ejemplo — basado en una aplicación del mundo real ™ — que muestra un caso de estos:

php:
<?php

if (empty($_GET['el'])) {
        die;
}
/* Función genérica que sirve para eliminar ciertos caracteres */
function clean_input_string($string) {
        return preg_replace('/[ <>\'"\r\n\t\\()]/', '', stripslashes($string));
}
$elemento = clean_input_string($_GET['el']);

?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <title>Demo</title>
        <script type="text/javascript">
            //<![CDATA[
            function ponerFoco(id){
                        var elemento = document.getElementById(id);
                        if (!elemento) return;
                        elemento.focus();
                }
            //]]>
        </script>
</head>

<body onload="ponerFoco('<?php echo $elemento; ?>')">   
        <form method="post" action="foo.php">
            <input type="text" name="usuario" id="usuario" />
                <input type="text" name="contrasena" id="contrasena" />
               
                <input type="submit" name="postback" value="Entrar »" />
        </form>
</body>

</html>

Como se puede observar, el código lo único que hace es intentar poner el foco en el elemento que se especifique en el parámetro el, éste valor antes es filtrado (elimina los caracteres espacio, <, >, ', ", \r, \n, \t, (, ) y \ ) por la función de propósito general clean_input_string — la aplicación de donde se tomó el código hace uso de esa función en varias partes.

Puesto que se eliminan los caracteres \, (, ) y ', en circunstancias normales no debería ser posible ejecutar javascript en el ejemplo mostrado; si el contiene ');alert(document.cookie)// entonces lo que llega al navegador es <body onload="ponerFoco(';alertdocument.cookie//')">, valor completamente inofensivo para nuestros propósitos.

Haciendo unas pruebas con un valor parecido al anterior, pero esta vez usando entidades HTML en lugar de los caracteres que son eliminados por la función clean_input_string, se consiguen resultados interesantes. Por ejemplo, para el = &#39;&#41;;alert&#40;document.cookie&#41;//, el HTML generado es:

html:
<body onload="ponerFoco('');alert(document.cookie)//')">

A simple vista, parece igual de inofensivo que el anterior caso, sin embargo si esa página carga en Firefox o Internet Explorer (no probé con otros navegadores), además de ejecutarse la función ponerFoco, se mostrará un mensaje mostrando las cookies almacenadas.

Este tipo de problemas se pueden solucionar evitando en lo posible enviar directamente los valores que dependen del cliente, definiendo filtros más específicos (formatos de identificadores válidos) o separando la generación de javascript y HTML en documentos distintos.

La (in)seguridad de Internet Explorer

Por: alex | 26 Febrero 2007 | 2 Comentarios

Este último fin de semana, mientras hacía una lectura de los sitios a los que estoy suscrito, encontré una interesantísima entrada en el que describe un bug que hace que Internet Explorer facilite los ataques XSS.

Para los que no siguieron el enlace, intentaré resumir de que trata el bug que se comenta ahí:

En teoría, cualquier documento que es servido por un (valga la redundancia) servidor web, está acompañado por una cabecera Content-type, que indica al navegador el tipo de archivo que es, en base a esto el navegador normalmente asocia una acción (interpretar el documento, pasar el control a otra aplicación o finalmente preguntar al usuario que desea hacer con ese archivo).

El caso es que Microsoft implementó algo que se denomina MIME Type Detection, donde básicamente se usan los primeros bytes de un archivo para intentar determinar el tipo o contenido del mismo, esta característica incluso está mencionado en el RFC 2616 (sección 7.2.1 Type).

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

De la cita, se puede ver que sólo se debe usar esta característica si el servidor web NO envía el Content-type correspondiente para el documento que está enviando al cliente.

Como casi todo en la historia de Internet Explorer, Microsoft tiene su propia forma de interpretar los estándares, y es que gracias a la característica antes mencionada, un archivo de texto plano, imagen u otro tipo de documento puede ser interpretado como HTML siempre y cuando éstos incluyan contenido HTML.

Si alguien tiene Internet Explorer a la mano, puede ver que si entra a http://test.buayacorp.com/xss.txt, se mostrará el mensaje "Esto es un archivo de texto" para un archivo de texto plano que contiene lo siguiente:

code:
<script>alert("Esto es un archivo de texto")</script>

Gracias a este bug, múltiples aplicaciones o sitios que permiten subir contenidos a sus usuarios son vulnerables, entre los que se me vienen a la mente:

  • Fresqui: vulnerable
  • Menéame: al parecer no es vulnerable porque hace una conversión de formato al subir un avatar
  • ANWMP o cualquier sitio que tenga instalado Drupal y permita subir archivos: vulnerable
  • etc, etc.

No recomiendo un navegador en especial (usen Firefox! :D ), puesto que fácilmente podría hacer el ridículo con los últimos bugs reportados en varios navegadores.

Capturar una página Web de manera sencilla

Por: alex | 23 Febrero 2007 | 6 Comentarios

Por si alguien necesita una funcionalidad parecida a lo que ofrecen sitios como WebSnapr o Snap, a continuación pongo la manera de capturar una página web como imagen.

csharp:
string url = "http://www.buayacorp.com/";
using (WebBrowser navegador = new WebBrowser())
{
    // Tamaño del navegador
    navegador.Size = new Size(1024, 768);
    // Deshabilitar la barra de scroll
    navegador.ScrollBarsEnabled = false;

    // Cargar la página
    navegador.Navigate(url);

    // Esperar a que cargue completamente la página
    while (navegador.ReadyState != WebBrowserReadyState.Complete)
    {
        Application.DoEvents();
    }
    // Tamaño de la imagen a capturar
    Rectangle tamaño = new Rectangle(0, 0, 1024, 768);
    Bitmap bitmap = new Bitmap(tamaño.Width, tamaño.Height);

    // Guardar la imagen de la página con el tamaño especificado
    navegador.DrawToBitmap(bitmap, tamaño);

    // Convertir y guardar la imagen como jpg
    Bitmap thumbnail = new Bitmap(tamaño.Width, tamaño.Height);
    Graphics gfx = Graphics.FromImage(thumbnail);
    gfx.DrawImage(bitmap, tamaño, tamaño, GraphicsUnit.Pixel);

    thumbnail.Save(@"E:\demos\demo.jpg", ImageFormat.Jpeg);
}

Esa porción de código hace una captura de 1024x728 pixeles, si se quiere capturar la página completa sólo es necesario jugar con los valores de navegador.Document.Body.ClientRectangle.

Por otro lado, como seguramente saben la clase WebControl usa internamente los controles de Internet Explorer disponibles en la máquina donde se ejecuta la aplicación, así que si un sitio se ve mal con este navegador, la imagen capturada también tendrá este pequeño problema.

Páginas: 1 2 ►