15 de febrero de 2011

¡Los 25 Errores de código más peligrosos! - según CWE/SAMS

Una muy importante fuente de información de seguridad de aplicaciones en general es el CWE (Common Weakness Enumeration), una comunidad perteneciente al MIT, que como su nombre lo indica se dedica a enumerar y clasificar los tipos de debilidades y vulnerabilidades de las aplicaciones, incluyendo por supuesto a las aplicaciones web.

Esta organización junto con SANS (SysAdmin, Audit, Network, Security) han publicado una lista muy importante de los 25 errores más graves en desarrollo de aplicaciones, y todos ellos aplican perfectamente a las aplicaciones web.

He traducido en dicha lista para Ustedes los nombres de los errores (excepto cuando la traducción no tiene significado y el término es conocido) para que puedan en nuestro lenguaje verificar cada uno de los errores y su nivel de importancia.
He dejado los enlaces al sitio original para cada uno de los errores de la lista, esperando en próximas entregas poderlos ir traduciendo uno por uno.

Posición Puntuación ID Nombre
[1] 346 CWE-79 Neutralización Impropia del Input Durante la Generación de la Página Web (XSS- Cross Site Scripting)
[2] 330 CWE-89 Neutralización Impropia de Elementos Especiales utilizados en un Comando de SQL (SQL Injection)
[3] 273 CWE-120 Copiado hacia el Buffer sin verificación del tamaño del Input (Classic Buffer Overflow)
[4] 261 CWE-352 Cross-Site Request Forgery (CSRF)
[5] 219 CWE-285 Control de Acceso Inapropiado (Authorization)
[6] 202 CWE-807 Confianza en Inputs no Asegurados en una Decisión de Seguridad
[7] 197 CWE-22 Limitación Impropia del Recorrido de Directorios a un Directorio Específico (Path Traversal)
[8] 194 CWE-434 Capacidad de Subir Archivos de Tipos Peligrosos no Restringida
[9] 188 CWE-78 Neutralización Impropia de Elementos Especiales Utilizados en Comandos de OS (OS Command Injection)
[10] 188 CWE-311 Carencia de Cifrado de Datos Sensibles
[11] 176 CWE-798 Uso de Credenciales en Código Fuente.
[12] 158 CWE-805 Acceso al Buffer con valor Incorrecto de Longitud
[13] 157 CWE-98 Control Indebido de Nombres de archivo para los Comandos Include/Requiere en un Programa en PHP
(PHP File Inclusion)
[14] 156 CWE-129 Validación Indebida de las posiciones de un Arreglo.
[15] 155 CWE-754 Verificación Impropia de Condiciones Inusuales o Excepcionales.
[16] 154 CWE-209 Exposición de Información Delicada a través de mensajes de Error.
[17] 154 CWE-190 Indebido control de 'Giro de Enteros'
[18] 153 CWE-131 Cálculo Incorrecto del tamaño del Buffer
[19] 147 CWE-306 Falta de Autenticación para Funciones Críticas
[20] 146 CWE-494 Descarga de Código sin Chequeo de Integridad
[21] 145 CWE-732 Asignación Incorrecta de Permisos para Recursos Críticos
[22] 145 CWE-770 Asignación de recursos sin límites o con límites excesivos
[23] 142 CWE-601 Redirecciones de URL a sitios no confiables (Open Redirect)
[24] 141 CWE-327 Uso de un Algoritmo Criptográfico Inseguro o Roto
[25] 138 CWE-362 Race Condition

Espero que la lista les resulte útil.
Hasta la próxima...

No muy buen libro para empezar en seguridad de Aplicaciones Web!

Qualsys y Wiley, liberaron  uno se sus famosos libros de la serie "For Dummies" específicamente Web Application Security For Dummies.  El libro se puede descargar gratis llenando un formulario en esta dirección.

La verdad es que el libro trata de una forma muy práctica las políticas defensivas necesarias para proteger las aplicaciones web solamente desde un punto de vista del analista de seguridad. Desde otra óptica este libro tiene un gran defecto, y es que utiliza solo la herramienta de Qualsys (QualsysGuard) para efecto de ejemplos y demostraciones que a mi modo personal de ver, si bien no se trata de una mala aplicación de seguridad y escaneo de vulnerabilidades no necesariamente es una de las mejores herramientas para tal efecto, aparte de que tiene un costo que la mayoría de los que leerán este libro no pueden darse el lujo de cubrir.

El libro está enfocado de forma que no influya para nada la plataforma de desarrollo que usted usa, y básicamente se enfoca en herramientas y formas de escaneo de aplicaciones web, así como ya dijimos en el uso de la herramienta de Qualsys, que no es gratis ni de código abierto y lo único que ofrece es un período gratis de prueba de 14 días. Cuando se trata de evitar problemas de seguridad directamente en código, si bien el libro nos refiere a políticas del ciclo de desarrollo para aplicaciones seguras y a sitios relacionados con el tema, no se extiende demasiado en el punto.

De todas formas usted siempre podrá aprender algo interesante, pero si en realidad desea aprender de forma rápida y eficiente acerca de seguridad web y acerca de desarrollo seguro, este libro no es precisamente la mejor forma de hacerlo. Inclusive me parece que tratar este tema con el título que el libro refiere "For Dummies", dejará a muchos principiantes frustados al no conseguir lo que buscan.

Hasta la próxima...

12 de febrero de 2011

Solución: Mayor integración a nivel corporativo de equipos de seguridad y de desarrollo.

En la experiencia adquiridas en el marco de la seguridad de aplicaciones web para empresas como bancos, administradoras y otros tipos de instituciones financieras, me he encontrado con cierta disociación entre los departamentos de desarrollo de aplicaciones (esos locos que no prueban bien lo que hacen) y de seguridad de datos y sistemas (esos gruñones que nunca aprueban lo que desarrollamos a la primera).

Como si fuera ya una tradición, no es nuevo escuchar que los primeros (desarrolladores) se quejan de la cantidad de protocolos de verificación, metodologías de testeo y lentitud o redundancia de los procesos de validación de los sistemas, mientras los segundos (técnicos en seguridad de datos y aplicaciones) lo hacen acerca de la falta de controles en código, rutinas insuficientemente testeadas en desarrollo, "agujeros" de seguridad heredados en código reutilizado, entre muchas otras cosas.

El cambio actual del tipo de plataforma de aplicaciones convencionales o de entorno manejable a una plataforma aún más abierta y peligrosa como el entorno de aplicaciones web cuyos límites y procesos no son fácilmente controlable, no solo ha afianzado la brecha entre estos dos departamentos, sino pareciera crear en algunos casos conflictos infranqueables.

Mi punto de vista es que en la actualidad ambos tipos de departamentos se encuentran en esta encrucijada debido al mantenimiento de políticas de desarrollo y seguridad en ambos lados que poco o nada tienen que ver con la forma en que las aplicaciones web pueden ser y son atacadas actualmente.

He constatado como empresas de cierta magnitud, no tienen políticas adecuadas para solventar los ya no tan nuevos tipos de ataques a aplicaciones web y a sus usuarios, y he visto personalmente como intentan aplicar en ambos bandos procesos ineficientes y absurdos a la hora de minimizar o anular un ataque (de phishing o pharming por ejemplo). Y por último he visto también como ambos bandos culpan al otro cada vez que se encuentran en este tipo de conflictos.

Desde una mirada exterior experimentada, puedo asegurar que el problema no pertenece a ninguno y a los dos bandos simultáneamente. Las razones son las siguientes:


  • Los protocolos de seguridad actuales no permiten responder con la celeridad necesaria ante ataques al entorno de aplicaciones web. Este tipo de ataques son en su gran mayoría del tipo masivo (phishing, pharming, DDoS, XSS). Son ataques que por sus características, una vez implantados y procesados atacan a un amplio espectro de los usuarios y no a uno o dos. Minutos perdidos son cantidades de dinero que no vuelven, y los protocolos de seguridad convencionales pueden llegar a estorbar más que a ayudar en estos casos.
  • Los desarrolladores y expertos en seguridad, en tiempos anteriores jamás tuvieron que preocuparse por la seguridad de un usuario que se encuentra ante su computador en su propia casa. Este es un concepto radicalmente nuevo para ellos, al punto que por ejemplo los ataques de phishing hasta hace poco eran considerados problema del usuario y no de la empresa.
  • Ambos equipos jamás tuvieron que validar aplicaciones y las interfaces de estas que funcionan simultáneamente en todos los sistemas operativos, bajo al menos una decena de navegadores web diferentes y una miríada de configuraciones diferentes.
  • Ambos equipos jamás pensaron o se imaginaron que sus aplicaciones podrían ser atacadas desde zonas que hasta el momento eran completamente irrelevantes. A nadie le importaba lo que pudiera hacer un hacker en países como Rusia, China y otros que quizás nunca habían escuchado nombrar.
En fin, lo que trato de exponer es que definitivamente la seguridad nunca y mucho menos ahora ha sido un problema interdepartamental. Las empresas necesitan técnicos que manejen ambas áreas de forma actualizada y eficiente y reconduzcan al personal existente a una nueva forma de observar los procesos de desarrollo así como los procesos de validación y testeo.

El enemigo además de ser un enemigo oculto, no es enemigo de un solo departamento. Es un enemigo común que posee tecnología sofisticada que puede obtenerse de forma cada vez más simple, por lo cual su capacidad de ataque se multiplica exponencialmente con el tiempo. 

El trabajo de seguridad (y no hablo solo de aplicaciones web) actualmente debe ser definitivamente compartido. Se necesitan desarrolladores en capacidad de entender los nuevos modelos de seguridad y tipos de vulnerabilidades para ser capaces de prevenirlas en código, así como expertos de seguridad en capacidad de comprobar la existencia de este tipo de vulnerabilidades y de crear procesos dinámicos de validación pero jamás sacerdotes que promulguen tablas de leyes bíblicas inamovibles.

Por otra parte las empresas deben canalizar sus presupuestos de seguridad e invertir más en actualizar su personal en seguridad de aplicaciones web, y proveerlos de mejores herramientas de control y desarrollo para tal fin. Así como pretenden que una gran cantidad de usuarios utilice las nuevas y más económicas tecnologías, deben entender que dicha pretensión conlleva un riesgo mayor y por ende un presupuesto mayor en respaldo de las mismas.

El enemigo actual solo puede ser combatido desde una perspectiva que no es nueva ni mucho menos innovadora, pero que tiende a ser olvidada en el día a día y enterrada por los procesos. Esa perspectiva no es más que la de un verdadero trabajo de equipo por un fin común.


Hasta la próxima...

Entradas populares