Month: junio 2007

Categories
.NET ASP.NET Web

Enviar la codificación adecuada en aplicaciones Web (ASP.NET)

Una pregunta que normalmente veo en los foros que participo, se relaciona con el tema de la codificación de una aplicación Web, normalmente se ven preguntas como: configuración para admitir caracteres como la "ñ", codificación de caracteres deseada, problema con tildes, tildes y caracteres especiales o algunas variantes más.

La mayoría de veces intentan establecer esta codificación usando el elemento HTML meta:

html:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

En otros lenguajes de programación como PHP esto funciona sin problemas porque no se envía automáticamente una cabecera HTTP que indique el tipo de documento y la codificación, pero en el caso de páginas que son procesadas por ASP.NET no ocurre esto, puesto que en cada documento que se envía al cliente, se especifica explícitamente el tipo y la codificación de la página. Si observamos parte del código del método GenerateResponseHeaders de la clase HttpResponse, se puede apreciar porque pasa eso.

csharp:

if ((this._statusCode != 0xcc) && (this._contentType != null))
{
        string text2 = this._contentType;
        if ((this._contentType.IndexOf("charset=", StringComparison.Ordinal) < 0) && (this._customCharSet || ((this._httpWriter != null) && this._httpWriter.ResponseEncodingUsed)))
        {
                string charset = this.Charset;
                if (charset.Length > 0)
                {
                        text2 = this._contentType + "; charset=" + charset;
                }
        }
        headers.Add(new HttpResponseHeader(12, text2));
}

Si no se especifica algún otro valor para la codificación (Charset) desde el código, este es tomado del elemento globalization del Web.config o machine.config.

xml:

<configuration>
   <system.web>
      <globalization
         requestEncoding="iso-8859-1"
         responseEncoding="iso-8859-1"/>
   </system.web>
</configuration>

En conclusión, utilizar sólo el elemento meta en páginas procesadas por ASP.NET no es suficiente, puesto que los navegadores -- al parecer -- prefieren el valor que se envía en las cabeceras HTTP.

Categories
CSRF Seguridad Sql Injection Web WordPress XSS

Múltiples vulnerabilidades en la última version estable de WordPress MU

WordPress MU, es una versión de WordPress que soporta múltiples blogs. Tanto WordPress como WordPress MU comparten gran parte de código y por lo tanto, es lógico que casi siempre sufran los mismos problemas de seguridad*.

Luego de mirar un rato el código de la última versión estable de WordPress MU, veo que el casi inofensivo** problema de seguridad que reporté el lunes pasado en WordPress, tiene consecuencias más peligrosas en la versión multiblog puesto que cualquiera puede registrarse en sitios que usen este CMS. Por las pruebas que hice, el exploit funciona sin realizar ningún cambio.

Por otro lado, las versiones menores iguales a 1.2.1 son posiblemente vulnerables a todos los bugs reportados meses atrás. Por tanto, lo más seguro mientras liberan actualizaciones de seguridad es usar la versión en desarrollo.

*: un problema similar existe entre menéame y pligg, este último no ha corregido varios de los fallos reportados en el primero (y viceversa).
**: pocos blogs dejan que los usuarios se registren libremente.

Categories
Firefox

A veces es bueno cerrar el navegador…

Este es el resultado de tener abierto Firefox durante unos días:

Consumo de memoria de Firefox luego de algunos días

Este consumo de memoria no sería problema siempre y cuando me deje trabajar bien, pero al llegar a este punto, el navegador se pone bastante lento al abrir/cerrar pestañas y entrar a cierto tipo de páginas (aquellas que contienen flash o hacen uso intensivo de javascript -- google reader, gmail).

Por el momento, no tengo intenciones de usar Internet Explorer u Opera (ninguno provee la misma funcionalidad que consigo con las extensiones de Firefox), así que tendré que seguir sufriendo hasta que los desarrolladores de este navegador provean mejoras en el consumo de memoria y rendimiento.

Categories
.NET ASP.NET Web

Comentarios de lado del servidor en ASP.NET 2

Existen ocasiones en que para corregir determinados problemas es necesario deshabilitar ciertas partes de una página ASP.NET, esto en algunos casos puede conseguirse usando sólo los comentarios HTML, pero para otros casos en que cierta funcionalidad no está implementada o los nombres de los controles entran en conflicto, se produce un error porque la página sigue su flujo de ejecución.

En el siguiente ejemplo se produce un error porque el identificador texto se repite:

html:

<%@ Page Language="C#" %>

<!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" >
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>

        <!--<asp:Label ID="texto" runat="server">

</asp:Label>-->

        <asp:TextBox ID="texto" runat="server"></asp:TextBox>

    </div>
    </form>
</body>
</html>

Para solucionar este problema, se debe usar comentarios del lado del servidor (<%-- comentario --%>).

html:

<%@ Page Language="C#" %>

<!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" >
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>

        <%--<asp:Label ID="texto" runat="server"></asp:Label>--%>

        <asp:TextBox ID="texto" runat="server"></asp:TextBox>
    </div>
    </form>
</body>
</html>

Al usar este tipo de comentarios, el texto contenido dentro de <%-- --%> no será enviado al navegador.

Referencia: Tip/Trick: Using Server Side Comments with ASP.NET 2.0

Categories
Firefox Internet Explorer Seguridad Web XSS

XSS y las peculiaridades de los navegadores

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.