Confiar en que el viewState de una página en Asp.NET está cifrado: ¡Error!

Uno de los errores más comunes de seguridad de los programadores de Asp.NET que utilizan "web forms" en sus aplicaciones, es creer que el "viewState" (ese campo oculto que se puede ver en todas las páginas desarrolladas con "web forms" que contiene un cantidad apreciable de caracteres ilegible) está cifrado.

El viewState es un repositorio de información en el que se apoyan los "web forms" para guardar los datos de los diferentes componentes o áreas de una página entre llamada y llamada al servidor. Incluso es accesible desde el código y podemos guardar información allí para usarla en de forma eficiente en nuestras páginas por ejemplo:

ViewState["password"] = thepassword;

Pero no es una buena práctica colocar información sensible como un password en dicho repositorio, debido a que la creencia de que el viewState está cifrado es completamente errónea. El viewState no es cifrado entre viaje y viaje al servidor sino codificado. Si usted conoce algo de criptografía entenderá que la diferencia entre cifrar y codificar es muy obvia, caso contrario permítame explicarle de forma muy resumida un importante detalle a la hora de proteger sus datos: para descodificar solo es necesario conocer el algoritmo en el cual el texto fue codificado, mientras que pare descifrar es necesario conocer una clave de cifrado además del algoritmo y esta no viaja junto al texto cifrado. 

Por lo anterior entenderá que si sabemos el algoritmo con el que el viewState es codificado, solo tenemos que usarlo en reversa para decodificarlo. Y bien ese algoritmo es el conocido Base64. Compruébelo usted mismo introduciendo el viewState de una página Asp.NET en este decodificador de viewState gratuito en línea: http://ignatu.co.uk/ViewStateDecoder.aspx 

Ante este problema tenemos dos soluciones: 

1. No colocar nunca información delicada en el viewState
2. Cifrar el viewState o cifrar la información que coloquemos en él.

La primera opción no necesita explicación, la segunda si amerita de algo de información adicional. El viewState, desde la versión de Asp.NET 2.0 en adelante también puede ser cifrado. Usted puede decidir hacerlo en absolutamente todo el sitio web colocando el siguiente atributo en la sección <pages> del archivo web.config:

<pages viewStateEncryptionMode="Always">

Sin embargo hay que tomar en cuenta que el cifrado puede reducir la velocidad de respuesta sobretodo si estamos en un sitio de alto consumo, por lo que podemos también utilizar el cifrado del viewState a nivel de cada página colocando el siguiente atributo en la cabecera <% @ Page >

<% @ Page Language="C#" AutoEventWireup="true" CodeBehind="login1.aspx.cs" ViewStateEncryptionMode="Always" %>

Espero que este truco e información sean de utilidad para los desarrolladores en Asp.NET.

¿Qué es la autentificación bidireccional y para qué sirve?

No se trata de explicar en este artículo lo mal que la han pasado desde hace ya más de dos o tres años, una innumerable cantidad de instituciones de todo tipo, debido a la proliferación de tipos de ataques "client side" como el Phishing, XSS, Pharming, y otros que no vamos a mencionar por lo largo de la lista, dirigidos específicamente a sus clientes y usuarios. Pero quizás no es tan obvio como lo primero entender que todos estos ataques pudieron haber sido reducidos en un alto porcentaje si se hubieran implementado a tiempo soluciones de autentificación bidireccionales.

¿De qué trata este nuevo término? La idea es muy simple:
No se trata solo de que la aplicación web autentifique y valide que el usuario es quien dice ser, se trata además de que el usuario pueda de igual forma validar y autentificar que la aplicación web sea la que aparentemente es.

Lo extraño de esto es que a pesar de ser una idea básica y muy simple, ha sido implementada en muy pocas aplicaciones y el sufrimiento del usuario ante las técnicas de robo de información y usurpación de atributos de uso y acceso continúa tan vivo como siempre.

Pues bien, para que vean que no es tan compleja la idea y menos su aplicación voy a dar un ejemplo.

Para empezar el banco o institución A, en el proceso de registro de sus usuarios, agrega una simple rutina mediante la cual cada uno de ellos seleccione de una librería de imágenes simples y fáciles de recordar, aquella que más se identifique con él. No quiero complicar esto en este momento, pero el usuario podría inclusive modificar algunos aspectos de la interfaz de la aplicación, "personalizándola", y asociar por ejemplo a la imagen "una frase célebre".

Luego de este proceso el usuario para ingresar a la interfaz privada de la aplicación debe pasar por un sistema de ingreso algo diferente a lo convencional que podemos denominar "doble capa de acceso". Este proceso no significa más que proporcionar los pasos de acceso en dos fases:

1. En la primera fase el usuario insertará su identificador de usuario (login) y algún otro detalle a discreción del banco A, como por ejemplo el número o nombre de la agencia en la que abrió su primera cuenta. 
2. Mediante los datos proporcionados en la primera fase por el usuario, el sistema pasa a una segunda fase en la que le muestra a este los cambios realizados a la interfaz y la imagen seleccionada por él en el proceso de registro. Solo si los anteriores corresponden entonces el usuario debe procede a colocar la pieza más crítica de sus datos: su clave de acceso.

Por tanto si no aparecen correctamente la interfaz y la imagen que el usuario seleccionó, seguramente estará ante la presencia de una página falsa y no procederá a insertar el resto de los datos de acceso. Un par de buenos mensajes como: "Si usted no puede ver su imagen de identificación o si nota algún cambio en su interfaz, no coloque su clave de usuario bajo ningún pretexto", son suficientes para que el usuario sepa que hacer en caso de un intento de phishing.

¿Es este proceso demasiado complejo de implementar?

Una de las principales razones que se esgrimen para no hacerlo, es que el proceso de ingreso debe ser realizado en dos etapas o dos páginas, con lo que se hace algo más lento. Esta es en realidad una excusa muy burda, ya que el usuario agradece y con creces este proceso que ya ha sido implementado en algunas instituciones y lo agradece de forma radical, es decir utilizando esas aplicaciones mucho más que otras quizás de mayor funcionalidad pero no tan seguras (al menos en apariencia).

Otro punto a favor de la idea y en contra de la anterior excusa es que este doble proceso puede ser simplificado radicalmente con técnicas actuales como AJAX, que además le ponen el proceso de emulación del sitio al atacante algo más cuesta arriba. No es tan sencillo hacer phishing de un sitio que cambia según lo que agregamos en él y mucho menos si esperamos ver cambios que solo la aplicación y nosotros conocemos.

Además el hecho de que el campo de introducción de la clave aparezca en una segunda fase y solo si los primeros datos coinciden, reduce drásticamente la superficie de ataque hacia los campos más sensibles de una segunda etapa.

Es así de sencillo, pero a pesar de ello las estructuras mentales de los que toman este tipo de decisiones siguen prefiriendo pelear semi-desnudos contra el el phishing y otros flagelos. No me gustaría tener que darle la razón a los hackers cuando mencionan como un hecho que "los code grinders tienen la creatividad de una rana".

Hasta la próxima!

OWASP Dirbuster - Escaneando directorios y archivos ocultos de una aplicación web

Uno de los problemas más comunes a la hora de programar es la creencia de que una página o directorio al que no lleva ningún enlace, jamás serán vistos. Pues si esto fuera cierto, lo sería solo en parte, y esa parte dependería de la facultad del programador de escoger nombres complejos y difíciles de adivinar por los expertos en seguridad y por supuesto los atacantes.

La idea de este artículo, es la de encarar al programador con herramientas capacitadas para descubrir la mayor parte del árbol de directorios de nuestra aplicación así como muchas de las rutinas y páginas de esta, por el simple motivo de que todos los programadores usamos casi las mismas herramientas, venimos de una misma corriente de pensamiento o leemos los mismos artículos y vemos las mismas películas y libros. En pocas palabras que debido a que usamos Macromedia Dreamweaver o Visual Studio, nombramos los directorios y archivos de una forma específica.

Este tipo de herramientas trabajan con diccionarios de nombres de archivos y directorios (en varios idiomas) los cuales se prueban solos o con extensiones comunes. Por ejemplo, este tipo de aplicaciones no tardaría prácticamente nada en descubrir un archivo cuyo nombre fuera "admin.zip" en donde un programador incauto podría haber dejado copia de respaldo de todas las rutinas del backoffice de su aplicación. Ejemplos como este hay muchos y algunos espeluznantes, ya que los aciertos no necesariamente son tan sencillos de imaginar como el anterior.

En fin, la intención es que ustedes mismos puedan descubrir cuan vulnerables son esas rutinas administrativas que damos por ocultas o inalcanzables desde la web, y para ello no hay mejor maestro que la experiencia. Y precisamente para que podamos experimentar con nuestras aplicaciones web,  OWASP (quien más podría ser) ha puesto uno de sus proyectos  de seguridad al alcance de todos, y en este caso se trata específicamente del Proyecto "Dirbuster". Disbuster (según palabras de sus creadores) es una aplicación Java multi hilo diseñada para obtener por fuerza bruta los nombres de directorios y archivos en servidores de aplicaciones web.

Puede descargarla en formato comprimido zip en este enlace.

Recuerde, Dirbuster no es más que una aplicación eficiente que nos muestra las posibles fallas de seguridad en la forma en que nombramos nuestras rutinas y directorios, pero cualquier herramienta de análisis de vulnerabilidades seria cuenta con rutinas para el mismo fin y algunas veces suelen ser muy superiores a esta.

Ejecute Dirbuster sobre su aplicación web de forma local, para evitar demoras por problemas de ancho de banda o bloqueo de firewalls, y verá como su forma de nombrar sus archivos y directorios cambiará para siempre.

Hasta la próxima...

OWASP Top 10 Mobile Security Risks

Nuevamente OWASP pone a disposición de los programadores interesados en desarrollar código seguro (debiéramos ser todos, pero tristemente no es así) un proyecto interesante, pero esta vez haciendo énfasis en la programación de aplicaciones móviles. Este proyecto no es más que el OWASP Mobile Security Project, que al igual que el Web Application Security Proyect ofrece una serie de utilidades, consejos y material didáctico muy interesante. 

Dentro de los recursos que ofrece sin fines de lucro este proyecto, no podía faltar la lista de los 10 riesgos más importantes a tomar en cuenta por los programadores al desarrollar aplicaciones para plataforma móviles.

Estos riesgos según OWASP son los siguientes:

• M1: Insecure Data Storage - Almacenamiento de datos inseguro
• M2: Weak Server Side Controls - Controles del lado del servidor débiles
• M3: Insufficient Transport Layer Protection - Insuficiente Protección en la Capa de Transporte
• M4: Client Side Injection - Inyección del lado cliente
• M5: Poor Authorization and Authentication - Autorización y Autentificación Pobres
• M6: Improper Session Handling - Manejo indebido de sesión
• M7: Security Decisions Via Untrusted Inputs - Desiciones de seguridad a trávés de entradas no confiables
• M8: Side Channel Data Leakage - Pérdida de datos por canales laterales
• M9: Broken Cryptography - Criptografía Rota
• M10: Sensitive Information Disclosure - Divulgación de información confidencial

Es una lista muy interesante que todo programador de aplicaciones móviles debiera conocer independientemente de a plataforma para la cual desarrolle. La lista fue publicada en Junio 2013, y como es lógico todos estos puntos forman parte también del curso de Seguridad de Aplicaciones Web y Móviles.

Desarrollo de aplicaciones móviles con frameworks multiplataforma: lo bueno, lo malo, lo feo...

A lo largo de estos últimos dos años hemos visto como en el ámbito de desarrollo de aplicaciones móviles, las herramientas multiplataforma han jugado un papel interesante para muchos programadores abrumados por la cantidad de diferentes lenguajes, APIS y kits de desarrollo propuestos por las diferentes plataformas móviles, quienes queriendo quizás adoptar un estándard se encuentran con que el mismo aún no existe.

Al querer abarcar mayor cantidad de público para sus aplicaciones, los desarrolladores se encuentran con por lo menos tres o cuatro diferentes plataformas, cada una con un sistema operativo, lenguaje de programación y un kit de desarrollo completamente diferente, por lo que en muchos casos en vez de dedicarse al desarrollo de aplicaciones nativas para cada sistema, optan por desarrollar con herramientas multi-plataforma como Apache Cordova/PhoneGap, Appcelerator's Titanium, Sencha Touch y otras.

Aún así no todo lo que brilla es oro, y existe una larga lista de asuntos pendientes por aprobación que hacen de las aplicaciones desarrolladas con esta técnica algo como una especie "secundaria". Indudablemente la opción de desarrollar con esta técnica depende directamente del tipo de aplicación a desarrollar y del propósito específico de cada equipo de desarrollo.

Los pros del desarrollo multi-plataforma de aplicaciones móviles pueden resumirse en los siguientes:

• Código reutilizable:Solo tienes que escribir el código una vez y aplicarlo en cada plataforma. Esto indudablemente significa una reducción drástica de tiempo y esfuerzo a la hora de calcular los costos de desarrollo.
  
• Fácil acceso a Plug-ins:Los principales entornos de trabajo le permitirán utilizar extensiones y módulos para mejorar el alcance funcional de su aplicación.
  
• Facilidad de trabajo en grupo:La gran mayoría de los entornos de trabajo multiplataforma utilizan Javascript, HTML5 y CSS3, haciendo más sencillo el proceso de aprendizaje y la comunicación entre desarrolladores ya que estos son estándares muy conocidos y ampliamente utilizados.
  
• Reducción de costes:Aunque ya mencionamos esto de pasada en el primer punto, la razón primordial de este punto es la no dependencia de programadores específicos para cada ecosistema y por consiguiente el pago por separado por cada versión de la aplicación según sistema operativo.
  
• Integración con la nube:Marcos de desarrollo como PhoneGap, Secha y Titanium ofrecen una fácil integración con los servicios de nube, lo que significa que una vez llevado a código el proceso, cualquier versión de la aplicación manejará esta integración casi transparentemente.

Los contras del desarrollo multi-plataforma de aplicaciones móviles también deben tomarse en cuenta:

• Su aplicación podría no soportar todas las características esperadas para cada sistema operativo:Este es un serio problema con las aplicaciones multi-plataforma, o bien se tienen que ajustar a la velocidad con la que el entorno multi-plataforma se adapte a los nuevos cambios en las versiones de los sistemas operativos, o simplemente hay opciones que no existen o no soporta un sistema operativo determinado. El típico problema de tener que escoger el mínimo común divisor, o decidir fragmentar el código en opciones diferentes para cada sistema operativo.
  
• Restricciones de la herramienta:En algunos casos por ejemplo en el caso de adoptar librerías de terceros, sobretodo aquellas desarrolladas para lectores de tarjetas, impresoras y componentes externos hay serias limitaciones que en las aplicaciones nativas simplemente no existen.
  
• Su código podría ser algo más lento:Generalmente el código generado en este tipo de herramientas se apoya en una "traducción" a código nativo, pero en ocasiones el intérprete debe trabajar en tiempo real, haciendo que exista una capa adicional de procesamiento y por ende el código ejecutado sea algo más lento.
  
• Carecen de gráficos y soporte para 3D:Si piensa desarrollar algún tipo de juego 3D, definitivamente estas herramientas no son la mejor solución. También podría tener problemas si necesita utilizar funciones criptográficas avanzadas ya que cada sistema operativo y lenguaje poseen características que diferencian la parametrización de las líbrerías de cifrado aunque se usen los mismos algoritmos.
  
• Alta dependencia del prooveedor:La mayoría de los entornos de desarrollo multi-plataforma usan su propio sub-conjunto JavaScript. Esto significa que si en un futuro deseara cambiar de herramienta le sería bastante difícil.

En conclusión, queda claro que los entornos de desarrollo "híbridos" tienen aún muchos retos por delante, pero si dentro de las necesidades de su empresa no se afectan por los inconvenientes de este tipo de herramienta, pueden ser una buena opción si se necesita una solución rápida y económica.

Redactado por Mauro Maulini R.