Problemas validando el código que genera ASP.NET?

Cuando se procesa una página, ASP.NET examina la información de la solicitud sobre el explorador actual y basándose en el tipo de explorador (cadena de agente de usuario), representa el marcado que es apropiado para dicho explorador.

En versiones anteriores a ASP.NET 2.0, el código HTML generado por defecto era HTML 3.2, ya que se consideraba a Internet Explorer como el único "navegador moderno" (irónico no? :-P), según este artículo de MSDN Magazine, en ASP.NET 1.x las características del navegador se toman de %windir%\System32\inetsrv\browscap.ini (se dá mayor importancia a IE, aunque existen definiciones de versiones muy antiguas de otros navegadores) y de la sección browserCaps del Web.config, para finalmente crear una instancia de la clase HttpBrowserCapabilities, accesible desde el request actual.

Felizmente, en ASP.NET 2, muchas cosas se han corregido en este aspecto, ya que por defecto se incluyen una serie de archivos xml con extensión .browser, donde se especifica el nivel de compatibilidad de distintos navegadores (pueden revisar %windir\Microsoft.NET\Framework\v2.0.50727\Config\Browsers). Por otro lado, también ofrece la posibilidad de modificar la salida de cualquier control (pueden ver un demo en http://asp.net/CSSAdapters/Default.aspx).

Con la breve introducción expuesta, el motivo de la entrada es para comentar que si quieren validar sus páginas hechas en ASP.NET 2, necesitan especificarlo en un archivo, de modo que el navegador del validador sea tratado como uno moderno.

Si envía una página Web ASP.NET a un servicio de validación como, por ejemplo, W3C Markup Validation Service, ASP.NET podría representar una versión de la página que no sea compatible con los estándares de XHTML. Esto es porque el servicio de validación no se presenta como un tipo de explorador que ASP.NET reconozca como, por ejemplo, Internet Explorer o Mozilla. Cuando ASP.NET no puede reconocer el tipo de explorador, toma como valor predeterminado la representación de marcado a bajo nivel, la cual no incluye elementos y atributos compatibles con XHTML, o características como estilos de hojas de estilo en cascada.

Esto es lo que se tiene que incluir en el directorio especial App_Browsers de una aplicación web:

xml:
<browsers>
  <browser id="W3C_Validator" parentID="default">

    <identification>
        <userAgent match="^W3C_Validator" />
    </identification>
    <capabilities>
      <capability name="browser"              value="W3C Validator" />

      <capability name="ecmaScriptVersion"    value="1.2" />
      <capability name="javascript"           value="true" />

      <capability name="supportsCss"          value="true" />
      <capability name="tables"               value="true" />

      <capability name="tagWriter"
         value="System.Web.UI.HtmlTextWriter" />

      <capability name="w3cdomversion"        value="1.0" />

    </capabilities>
  </browser>
</browsers>

Como se menciona en la documentación, aunque ASP.NET genere un marcado compatible con XHTML, algunos controles admiten una funcionalidad opcional que, si se utiliza, podría generar un marcado no compatible.

Espero que esta entrada sirva para los desarrolladores interesados en hacer que sus sitios intenten cumplir con los estándares definidos por la W3C

Recursos de fin de semana (III)

Más recursos para este fin de semana largo, y de paso deseando Felices Fiestas Patrias a mis paisanos peruanos:

Buen fin de semana 😉

IE7 será distribuido mediante actualizaciones automáticas

Los desarrolladores de Internet Explorer, acaban de anunciar que la nueva versión de éste navegador será distribuida mediante actualizaciones automáticas como una actualización de máxima seguridad.

Mirándolo desde el lado malo, para todos los desarrolladores será difícil "testear" sus aplicaciones en otros navegadores antiguos (léase IE6), ya que todo será desarrolado basándose en IE7.

Otro problemita sería para los usuarios que usan Windows "Bamba" (aproximádamente el 90%) no podrán instalar esta actualización.

La actualización está planeada para fines de este año, pero veremos que sucede en estos días.

Hot Capcha: el único captcha a prueba de bots

Ningún CAPTCHA es realmente efectivo, siempre tienen alguna vulnerabilidad que permite a los spammers "romper" el código que se muestra.

Para esto ha salido el ¿único? e infalible Hot Captcha, en el que para identificarnos como humanos sólo nos hace una sencilla pregunta:

"In order to prove to us you are not a robot, select the three hot people"

A ver si tienen suerte y les reconocen como seres humanos.

Enlace: Hot Capcha.

Problema de seguridad en Relay

Hoy, mientras intentaba personalizar Relay -que es un gestor de archivos basado en Ajax- para hacer que funcione como un navegador de código fuente, encontré un bug en la función getFileInfo (relay.php) que permite hacer SQL Injection.

La porción donde se encuentra la falla es: (~ línea 763)

php:
$fileid=mysql_escape_string($fileid);
$query = "select * fr0m $GLOBALS[tablePrefix]filesystem where id=$fileid";

El problema radica en que mysql_escape_string o mysql_real_escape_string sólo escapan los caracteres \x00, \n, \r, \, ', " y \x1a.; por tanto, si $fileid tendría el valor 0 or 1=1 u otra sentencia que no incluya los caracteres mencionados, ya se imaginarán que puede pasar.

Una propuesta para solucionar este problema es hacer un cast explícito de $fileid o encerrar entre comillas el valor de este parámetro en la consulta SQL (digo esto porque se hace uso de mysql_escape_string)

php:
$fileid=intval($fileid);
$query = "select * fr0m $GLOBALS[tablePrefix]filesystem where id=$fileid";

// o   
$fileid=mysql_real_escape_string($fileid);
$query = "select * fr0m $GLOBALS[tablePrefix]filesystem where id='$fileid'";

Si están utilizando Relay, es recomendable que corrijan este error, para evitar molestias por pérdida de datos :-P.