Una interesante lista de plugins para desarrollo web en los principales navegadores.
Category: Internet Explorer
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.
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! 😀 ).
Categories
Cookies
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.cookieretornará una cadena vacía si el tamaño de las cookies es mayor a 4096 bytes.- El navegador ignorará las cabeceras
Set-Cookiesi é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ólou. - 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
pathsó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. 😀
*: 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.
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 = ');alert(document.cookie)//, 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.
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
ANWMPo cualquier sitio que tenga instalado Drupal y permita subir archivos: vulnerable- etc, etc.
No recomiendo un navegador en especial (usen Firefox! 😀 ), puesto que fácilmente podría hacer el ridículo con los últimos bugs reportados en varios navegadores.