Grabación de los eventos de abril 2009

Como les comenté en un post anterior, a principios de abril se estuvo realizando la semana de la seguridad con diversas charlas Microsoft.

Las grabaciones Live Meeting de esas charlas y de otras que se dieron este mes están disponibles en el grupo de facebook de «Comunidades Técnicas Microsoft Chile» , pueden aprovechar de revisarlas pues siempre es bueno aprender un poco más.

Muchas gracias a los oradores de esas charlas y al equipo de comunidades técnicas Microsoft Chile que nos permiten difundir el conocimiento

Recomendaciones sobre validaciones de datos

Hace unos días un colega me preguntaba sobre consideraciones o recomendaciones de seguridad a la hora de diseñar una aplicación.

Aprovechando unos minutos de tiempo libre que tengo, me animo a plasmar un par de recomendaciones sobre la validación de datos, uno de los puntos sensibles en la seguridad de nuestras aplicaciones, sobre todo en las aplicaciones web.

Espero ir agregando material básico que demuestre los problemas que podría generar y también algunas formas de prevenir estos problemas de forma práctica. 

Validación de datos (de fuentes externas en general, como lo que ingresa el usuario, pero también de  datos que provengan, por ejemplo,  de otros sistemas)

·         NO confíe en la validación en el cliente, una de las premisas debe ser “la validación en el cliente no es validación” simplemente porque no se puede asegurar que esta se realice de forma adecuada, o incluso que se llegue a realizar. Hay que recordar que la mayoría de las validaciones en el cliente son hechas con lenguajes de script (javascript principalmente) el cual puede ser deshabilitado en los exploradores.

·         No confíe en los valores extraídos desde recursos susceptibles a ser modificados, esto incluye campos de formulario (como los hidden por ejemplo),  cookies, query strings, HTTP headers, etc.

·         Valide el tipo, formato, rango y largo de los datos. Es decir, si lo que va a ingresar es un email, que lo ingrese tenga la estructura de un email, sea de tipo string y un largo determinado (por ejemplo 50 caracteres). Si va a ingresar un entero, validar que el valor ingresado sea un entero y no un string.

·         Considere usar un sistema centralizado de validación de los datos. Muchas veces encontramos que los mismos puntos dentro de una aplicación son validados de maneras distintas y con distintos procedimientos. Unifiquemos los criterios de validación por ejemplo de fechas, rangos, formatos, etc.

·         Esté atento a los posibles problemas de canonicalización. (** No tiene nada que ver con los santos ni el vaticano, si no sabes por dónde va este tema ya lo explicaré en un post futuro, paciencia)

Mil disculpas por lo resumido del aporte, pero ya lo iremos ampliando de a poco, paciencia 😉

Comentarios de servidor

Uno de los pilares de la seguridad es la confidencialidad, que en pocas palabras significa asegurar que solo la o las personas correctas (que tienen privilegios sobre ella) accedan a la información.

 Una práctica que he visto un par de veces en algunos colegas (bueno, casi todos la hemos hecho alguna vez) es poner comentarios en la vista html.

El gran problema que esto crea es que los comentarios de html son traspasados al cliente, ejemplo:

En la imagen inferior tenemos un comentario html común y corriente

Cuando nuestra página es renderizada al explorador cliente, si vemos el codigo html resultante  veremos que el comentario aparece ahí:

Ahora sustituiremos el comentario html por un comentario de servidor, verán que la diferencia radica en la sintaxis del comentario.

Comentario html:  <!– Recordar que el username es Pepito y la password es P@ssw0rd –>

Comentario de servidor : <%— Recordar que el username es Pepito y la password es P@ssw0rd —%>

la imagen de abajo nos muestra el comentario de servidor en nuestro visual studio

y ahora comprobaremos que nuestro comentario nunca llegó al cliente:

Como dije, la primera regla es no poner datos sensibles en los comentarios, unido a esto una buena barrera es utilizar los comentarios de servidor que evitarán que algún descuido genere alguna brecha de seguridad.

Fábrica de Software

Buscando, siguiendo links y navegando por el web un poco, dí con un portal bastante interesante, dedicado a la Ing de Software y en español (mejor dicho en Chile). http://www.fabricadesoftware.cl/index.php , más allá que su actividad en el último tiempo al parecer es baja, hay documentos y threads de discusión bastante interesantes, dense una vuelta si no lo conocen, 100% recomendado.

Seguridad, bendita eres entre todas las palabras

El día jueves 2 de abril entre 9 y 18 horas se realizó un evento presencial de Microsoft en el auditorio de New Horizons Chile, en el marco de la semana de la seguridad. En la jornada de la tarde (de 14 a 18 horas) estuvo dedicado al desarrollo de software. (si hacen click podrán ver las grabaciones de esos eventos, más otros que se han dado en otras fechas).

Lo que se habló y vio ese día me animó a volver un rato por los ruedos bloggeros para dar mi opinión sobre varios conceptos e ideas que se discutieron ese día.

La masificación de internet y el incremento en la complejidad e interacción entre las aplicaciones y los sistemas, a traído sobre el tapete el tema de la seguridad más seguido. Pero como en todo, el que se hable más de un tema no significa que tenga realmente mayor relevancia o que se haga más al respecto.

 La masificación de internet también ha dado más facilidades a los atacantes para conectarse a nuestras aplicaciones e intentar vulnerar la seguridad de esta.

Como dije, más allá que se habla mucho de seguridad, aún los roles envueltos en la mayoría de los proyectos de desarrollo de software hacen poco por asegurar realmente sus aplicaciones escudándose en que es un proceso altamente costoso o altamente dificultoso.

Planificación

A menudo, en el proceso de planificación del proyecto no se le asigna a la seguridad la relevancia necesaria debido a que muchas veces quienes participan en esta etapa no tienen, o tienen un limitado conocimiento, acerca de las vulnerabilidades que podría poner en riesgo la seguridad de su aplicación, como por ejemplo ataques organizacionales, ataques automatizados en busca de vulnerabilidades, ataques de fuerza bruta, denegación de servicio (DoS) y vulnerabilidades varias debidas a malas o deficientes prácticas de desarrollo.

También sucede que muchas veces están conscientes de las vulnerabilidades pero creen que su aplicación no va a ser afectada por estas o que su aplicación nunca será atacada. Esto es muy habitual cuando se desarrolla software para ambientes corporativos internos o intranets, donde se piensa que al no estar expuestas al mundo (internet) la aplicación está segura, olvidándose del enemigo interno y dejando la aplicación a merced de este.

Finalmente, el último escenario es que se esté consciente de las vulnerabilidades, se sepa que nuestra aplicación va a ser afectada, pero no se tome en cuenta el tema hasta el final (si es que queda tiempo) debido a las restricciones de tiempos en los proyectos (deadlines).  Es importante recalcar que al planificar nuestro proyecto debiésemos planificar con el tiempo necesario para poder realizar los pasos necesarios que aseguren un nivel de seguridad adecuado en nuestra aplicación. Pero además como todos los oradores dijeron ese día (recomiendo oir el material de las sesiones de ese día)  hay muchas técnicas que podemos usar para aumentar la seguridad de nuestra aplicación y que no significan un aumento en nuestros tiempos de desarrollo.

Desarrollo

Así como en la planificación se falla muchas veces en reconocer las vulnerabilidades de seguridad,  otras tantas los desarrolladores fallamos en implementar código seguro por diversas causas.

Así como los planificadores, los desarrolladores muchas veces tampoco son conscientes de las vulnerabilidades potenciales, muchas veces debido a la falta de capacitación y de información con respecto a este tema.

Otro inconveniente habitual es que a menudo los desarrolladores no son capaces de implementar código seguro debido a que la seguridad de la aplicación depende de la cooperación entre los desarrolladores y los administradores de sistemas (nuestros amigos de infraestructura), y eso habitualmente no sucede porque nuestra práctica habitual nos indica que la seguridad es una responsabilidad individual. Si estamos trabajando en una aplicación que funciona en red entonces esperamos que la seguridad sea vista por el administrador del sistema por que la red es concernencia de la gente de infraestructura, lo cual nos lleva a olvidar que una aplicación más segura es responsabilidad de todos los roles que se vean envueltos en el normal funcionamiento de esta (Administradores de sistemas, Arquitectos de solución, Arquitectos de infraestructura, analistas, desarrolladores, etc.)

También como dijimos en el punto de planificación, tal vez los desarrolladores estén conscientes de las vulnerabilidades, pero las restricciones de tiempo o de presupuesto no le permiten implementar al menos la seguridad básica. Mencioné las restricciones de presupuesto pues muchas veces se piensa en que los costos de implementar seguridad son elevados y los beneficios poco palpables o claros, aunque realmente los costos altos se producen al no implementar seguridad, pues si una aplicación no es asegurada adecuadamente y un usuario malicioso posteriormente  explota y/o expone esta vulnerabilidad, los costos de desarrollar parches de seguridad para esta vulnerabilidad incluyen básicamente: los desarrolladores deben arreglar el código, los testers deben aplicar las diversas pruebas de rigor al parche de seguridad y debemos dar aviso al cliente y publicar el parche (con el costo de pérdida de credibilidad asociado).

En resumen descubriremos que los costos mencionados anteriormente serán más altos que agregar características de seguridad en etapas como la de diseño o desarrollo.

 Espero ir habitualmente entregando tips, experiencias, how to, que demuestren lo dicho en este post y que nos ayuden a mejorar nuestra conciencia de seguridad en el desarrollo de software.