la especificación de las cookies

---

A cuento del post de hace un mes y algo sobre las cookies y sus tamaños, os dejo un post rapidito para mencionar un artículo muy bueno sobre las debilidades en la especificación de las cookies HTTP, en el blog de lcamtuf.

Nos cuenta sobre los orígenes de las cookies, de sus flags más conocidos, y una serie de problemillas de seguridad muy interesantes que surgen debido a la forma en que se especificó su uso. Para no perdérselo.

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS o seguirlo en Twitter...

sdl cc

---

Esta es una noticia para resaltar: Microsoft cambiará el modelo de licenciamiento de su SDL, que ahora tendrá una licencia Creative Commons. Este cambio permite a todas aquellas organizaciones que deseen implantar su propia metodología de desarrollo seguro, utilizar como base (de forma legal) la información que Microsoft acoja a esta licencia. De acuerdo al blog "The Security Development Lifecycle", será bastante.

Otros modelos y guías a seguir son (no necesariamente libres o gratuitos):

• OpenSAMM
• TSP-Secure
• RUPSec
• McGraw's touchpoints
• NIST SP800-64
  

Si algún otro te parece interesante, no dejes de escribir un comentario :) .

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

ESSoS y otros

---

Ha pasado mucho mucho tiempo desde la última vez que escribí algo en el blog (la carga de trabajo no lo permite), y en estos días ha habido muchísimas cosas interesantes en el mundo de la seguridad informática que valía la pena reflexionar y contar. He perdido algunos eventos buenos, como la RootedCon, que al parecer ha sido todo un éxito (¡felicidades a los organizadores!), algunos noticiones como los relacionados con la red Mariposa y cómo ha sido distribuido el malware que la hace posible, o el advenimiento del esquema nacional de seguridad (en Seguridad y Gestión le dieron una vuelta al tema).

Para volver a la carga en el blog, hoy he leído la noticia de una nueva conferencia de seguridad informática: ESSoS estará dedicada al desarrollo seguro, acaba de lanzar su call-for-papers, y se celebrará en Madrid en Febrero 2011. Para no perdérselo.

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

Mejorando frameworks de desarrollo

---

Me gustó hace unos meses este paper: A gap analysis of application security in struts2, desarrollado por el Owasp Intrinic Security Working Group . En él nos contaban cómo el framework Struts2 puede ser utilizado para implementar determinados aspectos de seguridad, como puede ser la validación de entrada, y cómo este framework puede ser mejorado agregándole algunos aspectos que sí están en Owasp ESAPI. (Posteé sobre esto en seguridad en struts).

Como uno no deja de descubrir cosas nuevas, acabo de descubrir gracias a la entrevista a Andrés Riancho en elladodelmal sobre HDIV (HTTP Data Integrity Validator, un proyecto cuyo objetivo es ampliar frameworks de desarrollo como Struts2 o Spring MVC y dotarles de características de seguridad de las que no dispongan. En particular, tiene como misión dar mecanismos para proporcionar:

• Integridad de todos los datos generados por el servidor y que no deben ser modificados en el lado cliente (enlaces, campos ocultos, etc)
• Validación de los datos de entrada: para aquellos datos que sean editables por el usuario (campos de texto), se establecen controles de validación genéricos
• Confidencialidad: garantizar la confidencialidad de datos no editables, pues pueden representar información a proteger: nombres de tablas de BBDD, directorios web, nombres de máquinas de la red interna de la empresa, y un largo etcétera
• Token anti-csrf: en cada formulario y enlace se puede poner un token generado aleatoriamente, como medida de protección adicional contra problemas de CSRF.

entre otras cosas de interés. Merece la pena echarle un vistazo al manual para informarse.

Slds!

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

Reconocer el fracaso en seguridad

---

Leo en VariableNotFound dos entradas buenísimas sobre los programadores con producción neta negativa, y sobre las 101 formas de saber que tu proyecto está condenado al fracaso (proyecto de desarrollo, claro está). Si hacemos una lista parecida sobre fracaso en seguridad, yo pondría las siguientes.

• Agregar características generales al final del proyecto. Por ejemplo, en seguridad: pensar que se puede securizar al final.
• No concienciar al equipo de desarrollo sobre aspectos fundamentales (por ejemplo seguridad)
• No formar al equipo de desarrollo en técnicas de desarrollo seguro que han de utilizar al escribir código, o en las decisiones de diseño que puede ser necesario tomar
• No proporcionar tiempo al equipo de desarrollo para que se forme él solito sobre los temas que les competen, por ejemplo seguridad
  
• Considerar inaceptable el coste en tiempo (y por tanto dinero) que supone el repaso del código, la implantación de medidas de seguridad, o la realización de pruebas de hacking al final, viéndolo como un gasto superfluo en todos los casos, en vez de una inversión
• No seguir un verdadero ciclo de desarrollo seguro, que contemple la seguridad como uno de los aspectos fundamentales en cada una de sus fases

Además de tener razones por las que se fracasa en seguridad por no hacer cosas, se me ocurren ahora mismo razones por las que se fracasa en seguridad precisamente por hacer cosas:

• Considerar que sabemos más que los expertos del mundo mundial, reinventando la rueda. Hay mil ejemplos: usar algoritmos de cifrado de nuestra invención que "nadie puede romper porque sólo los conozco yo", crear identificadores de sesión con formato propio, no usar las funciones de la API para validar entradas porque ya tenemos nosotros las nuestras, etc...
• Hacer un sistema que siendo seguro, molesta constantemente al usuario (de esto, todo el mundo menciona el mismo ejemplo, para qué repetir)
• Hacer un sistema tan seguro que penaliza otros aspectos, haciéndolo menos atractivo o útil al usuario, que por tanto comprará otro producto (¿para qué hacer un producto súper seguro que no comprará nadie?. Aunque de esto, no se me ocurre ningún ejemplo ahora mismo)
  

¿Se os ocurren otras formas?

Slds!

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

Certificaciones de desarrollo seguro

---

Leo hoy vía segu-info que ISC ha lanzado una nueva certificación de seguridad, en este caso, de desarrollo seguro, denominada Certified Secure Software Lifecycle Professional. Tengo que decir: ¡ya era hora!.

Ni una sola certificación de las demandadas habitualmente hasta la fecha es específica de desarrollo de aplicaciones, sino que todas son de redes, de sistemas propietarios (Microsoft, Cisco,...) o de gobierno TI (tipo CISA, CISM).

Había un hueco por cubrir, creo que eso está claro (y si me equivoco por favor deja caer un comentario), dado que ahora mismo, por ejemplo, los problemas en aplicaciones web son los más explotados, como dicen muchas estadísticas, por ejemplo el informe que nos hizo RedIris a principios de año, con los datos del 2007.

Parece ser que han dividido el temario en siete temas:

• conceptos de software seguro
• requisitos de seguridad en el software
  
• diseño de software seguro
  
• implementación/codificación segura
  
• chequeos de seguridad en el software
• aprobación del software
  
• implantación, operación y mantenimiento del software

El primer examen será en Julio 2009.

Mientras, Microsoft ha anunciado que pondrá a disposición de los usuarios, para descarga, su SDL, según nos dicen en Securityfocus. Asimismo, también lanzará una certificación que acredite el conocimiento y experiencia en dicho SDL, dentro de su programa "SDL Pro Network", así como una metodología de análisis de amenazas (threat modeling) basado en este SDL, según nos dice Microsoft en su sitio web.

A mí me parece que ambas certificaciones prometen, la verdad. Pero espero que no se conviertan en otra medalla más, sino que sea algo realmente útil.

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...

Microsoft security development lifecycle

---

Últimamente tengo mucho menos tiempo para dedicar al blog del que me gustaría, así que quizá esto sea para tí una noticia pasada. El caso es que Microsoft ha hecho pública bastante información acerca de su proceso de desarrollo de software, cuyo objetivo es reducir al mínimo la cantidad de problemas de seguridad que sus desarrollos presentan.

Les ha servido bien, cuando en las comparativas que he leído últimamente, por ejemplo el de ENISA del que hablábamos, sale que Microsoft era el que menos problemas de seguridad tuvo últimamente (los datos se referían al 2007, aunque no lo recuerdo con precisión).

Obviamente, un recurso muy interesante al que echar un vistazo :)

Sobre el SDL hay un blog de MSDN, de reciente creación, en el que se pueden leer entradas de autores de relevancia, sobre desarrollo seguro, buenas prácticas de programación, las impresiones de los autores al dar formación sobre el SDL (cómo lo "encaja" el alumnado) etc.

Vía: VirusAttack
Otros recursos: Microsoft Security Developer Center

Cuidado con lo que dicen las herramientas

---

Creo que a estas alturas, todo el mundo se ha enterado del fallo gordo de OpenSSL en Debian (y derivados). Casi nada: el generador de números aleatorios es predecible. Cualquier herramienta que utilizara ese generador para securizar los datos que transmite podría ser vulnerable, al ser posible, offline, descifrar ese tráfico. Cualquier servidor SSH que use claves generadas por el sistema vulnerable podría ser objeto de man-in-the-middle, y el usuario ni se enteraría.

El problema vino al corregir un fallo detectado al usar dos herramientas de análisis dinámico (Valgrind y Purify), que indicaban que se estaba usando memoria no inicializada. Esto sería un defecto en otras aplicaciones, pero en este caso, se estaba usando para inicializar la semilla con que se genera el número aleatorio necesario para crear las claves criptográficas. Para corregir el problema, se eliminó algo más de código del necesario, debido a que no se sabía muy bien qué hacía, con el resultado de que ese número aleatorio tiene muy poca entropía.

A lo que voy: el problema viene por una costumbre muy común en los programadores, y muy mala, que es "comentar y a ver qué pasa", cuando el código no se comprende. ¡Cuidado con lo que dice una herramienta!. El bug original era, en este caso, un falso positivo de las herramientas (yo lo considero así) y hay que discernirlo correctamente. Eso sí, creo que el que sabe hacerlo siempre es un programador de bandera (todos podemos cometer un fallo, ¿no?).

Me ha gustado mucho el chiste que se ha puesto en la página de Metasploit:


Más enlaces:
el fallo reportado
sitio del descubridor
exploit posible

Actualización: preguntas frecuentes