• Tweet

La próxima versión de la suite de productividad de Microsoft replantea como las aplicaciones de escritorio deben de orientarse a la seguridad.

Sigo estando impresionado con los cambios que vienen en Office 2010 (actualmente en versión beta). Previamente, expliqué cómo Microsoft se baso con datos de uso real para elaborar las actualizaciones de la versión beta. La seguridad es por otra parte otra prioridad del próximo lanzamiento, y mientras las mejoras no se visualizan aparentemente, para los desarrolladores son igualmente dignos de mencionarse.

La suite de Office es compleja y rica en características, convirtiéndolo en un propicio blanco para malware y otras vulnerabilidades de seguridad. Dados los vastos y diversos usuarios, para Microsoft el eliminar las existentes características en el nombre de la seguridad estaría fuera de dudas.

En cambio, el equipo de desarrollo del producto Office 2010 se concentró en desarrollar una nueva estrategia de seguridad. Estudiaron vulnerabilidades pasadas para aprender como eran explotadas y que se podía hacer para prevenir casos similares en el futuro.

El resultado fue un nuevo modelo de seguridad de múltiples niveles basado en cinco principales principios. -- los cuales cuaquier desarrollador de aplicaciones debería de recordar:

1.- Validar todas las entradas de los usuarios antes de actuar sobre ella.

Cuaquier buen programador conce que las validaciones de entradas son cruciales. Las entradas que no se verifican pueden saturar el buffer, ataques de inyección de código, y cualquier otra cantidad de fallos en el software. Sin embargo muchos programadores piensan solamente en validar campos de forms, cajas de text input, y otros elementos de UI. ¿Qué pasa entonces con los documentos-

La forma en que Office 2010 evita sorpresas no deseadas de seguridad es prevalidar los documentos en contra de una librería de esquemas de documentos con características conocidas – tanto buenas como malas. La idea es que Office será capaz de reconocer los tipos de documentos específicos y realizar las medidas de seguridad necesarias antes de que empieze a interpretar el código – or ejemplo, al desabilitar las macros cuando encuentre que en los documentos estos coincidan con las características e un conocido virus de Word.

2.- Buscar por errores aleatorios y escenarios atípicos.

Casos de uso bien elaborados son cruciales en un examen de software, aún así los más astutos ingenieros QA pueden pensar en todo. Los peores errores pueden aparecer de áreas inesperadas – y a veces basta con unos pocos inesperados bytes para que los provoquen.

Es por eso que el equipo de Offiec utiliza una técnica llamada “file fuzzing” para detectar situaciones no previstas. Fuzzing toma los documentos que son conocidos y por lo tanto válidos y los cambia aleatoriamente – por ejemplo, al intercambiar los contenidos de los campos o simplemente al introducir aleatoriamente datos innecesarios en la mitad del archivo.

Idealmente, las aplicaciones deben de ser aptas para manipular archivos fuzzed sin problema. En el peor escenario, sin embargo, al abrir un archivo fuzzed conduce a un accidente – y esto es una bandera roja para una posible explosión de seguridad.

De acuerdo a Microsoft, el Office 2010 beta puede manejar satisfactoriamente archivos fuzzed 10 veces más que Office 2007.

3.- No confíe en librerías de terceros

Los formatos de archivos basados en XML de Office son bastante fáciles. No obstante en la práctica, los documentos del mundo-real de Office contienen algo más que datos ASCII. Tal vez puedan contener imagénes, audio, video o incluso objetos de código embebidos en otras aplicaciones.

Años de pruebas sobre Office 2007 permitieron a los ingenieros de Microsoft a llegar a una conclusión inesperada: La mayoría de los errores críticos que encontraron no eran culpa del código per se de Office, pero eran el resultado de defectos en las librerías de procesamiento de imágenes utilizadas para hacer JPEGs, GIFs, y otros gráficos.

Para Office 2010, Microsoft ha cambiado estas librerías a Windows Imaging Component, que esta basado en pluggable codecs. Para los desarrolladores de otras aplicaciones, sin embargo, la lección es clara: No asuma que incluso una librería muy utilizada este libre de defectos. Pruebe el código que obtenga de otras fuentes, así como el suyo.

4.- No confíe en los usuarios para reforzar la seguridad.

La mayoría de las aplicaciones de escritorio usan un modelo que pregunta al usuario: “La acción que esta a punto de realizar representa un riesgo de seguridad. ¿Desea continuar de todos modos (S/N)-”

Este enfoque no es solamente perezoso si no peligroso. ¿Qué hace a una específica acción un riesgo de seguridad- ¿Qué tan riesgoso es- Y para el caso, ¿que significa “seguridad” en este contexto- A falta de una guía útil, el usuario promedio dará click en Sí.

Ofrecer más detalles de mensajes de advertencia no ayuda. Los usarios solo esperan que la computadora obedezca sus comandos. No quieren arguir, y no tienen tiempo para leer ensayos acerca de vulnerabilidades de software.

En su lugar, Office adopta un enfoque proactivo de seguridad. El objetivo principal de los procesos como la validación de los archivos es impulsar más las opciones de seguridad en el background, que las confrontaciones de los usuarios con cajas de dialogo. Las decisiones racionales detrás de las escenas, antes de la interacción con el usuario, las nuevas aplicaciones de Office ayuda a eliminar las conjeturas de la gestión de la vulnerabilidad.

5.- Preferir la experiencia del usuario a la negación pura y simple

Cuando en las versiones anteriores de Office encontraron riesgos de seguridad, los usuarios realmente sólo tenían dos opciones: Podrían proceder como de costumbre - sucumbir a la amenaza - o no podíanabrir el archivo en absoluto. Ninguna elección era la ideal.

Office 2010 intenta ofrecer un punto medio siempre que sea posible, dando a los usuarios una experiencia de degradación en vez de negar las acciones de riesgo absoluta.

Por ejemplo, si Word 2010 encuentra un documento que contenga macros peligrosos, que podrían abrir el documento con las macros con desabilitadas. El usuario todavía recibe un mensaje de advertencia, pero el documento se abre de todas formas. El texto es visible, pero las macros permitidos requieren pasos de confirmación adicional.

Esta filosofía de "meeting the user halfway" es uno de los conceptos más importantes que subyacen en el modelo de seguridad de Office.

Mientras que los procedimientos de seguridad crean un tira y afloja entre los usuarios y el software, los usuarios siempre encontrarán la manera de "ganar" - por lo tanto, subvertir las medidas de seguridad destinadas a protegerlos.

Al ofrecer una forma gradual, el modelo de seguridad de varios niveles, Office 2010 intenta hacer de la seguridad una asociación con el usuario - y eso es una lección que cualquier desarrollador de aplicaciones puede tomar en serio.

Fuente: infoworld  MVR/RS