OWASP

De Wikipedia, la enciclopedia libre

Tienes mensajes nuevos (Dif. entre las dos últimas versiones).

OWASP significa Open Web Application Security Project (Proyecto Abierto de Seguridad de Aplicaciones Web), es una comunidad abierta dedicada a encontrar y combatir las causas de la inseguridad en el software. Todas las herramientas, foros, documentos y Chapters (significa capítulos pero hace referencias a las organizaciones nacionales de cada país) son gratis y de código abierto para todo el mundo. Al ser una organización sin fines de lucro, le permite ser imparcial y práctico sobre la información acerca de la seguridad. OWASP no está asociado con ninguna compañía tecnológica, a pesar que utiliza la información que ellos el suministran. La fundación provee servidores de banda ancha, facilidad para realizar proyectos y los antes mencionados Chapters. Además realiza una conferencia mundial OWASP Application Security Conference (Conferencia de seguridad en aplicaciones OWASP). Una distinción que hace OWASP son los Amenazas. El uso de la palabra amenaza lo utiliza para describir un potencial (o probable) peligro o de que algo salga mal. Para poder entender bien el concepto de seguridad y todo lo que lo rodea debemos poder distinguir entre riesgo, ataque, vulnerabilidad, impacto y otros términos de manejo de riesgos. Hay tres categorías de amenazas:

Naturales (Incendio, tornado, rayo),
Humano No intencional (accidentes, descuidos),
Humano Intencional (de adentro, de afuera),

El análisis de amenazas es una actividad que identifica amenazas y estima la probabilidad de que ocurran. La amenaza existe aun si el sistema esta protegido o no. Ejemplos de Amenazas:

Un empleado puede robar información
Una persona ajena puede generar un ataque denegando del servicio,
Un desarrollador de software puede robar el código fuente,
Un desarrollador de software puede insertar un [back door] (puerta trasera),

Otro concepto a destacar son los ataques. Los ataques son técnicas que los atacantes usan para explotar las vulnerabilidades de una aplicación. Esto ataques son comúnmente confundidos con vulnerabilidades; esto puede llevar a tratar de contrarrestar una ataque cuando solo hay que mejorar una debilidad de la aplicación. Ahora bien, las vulnerabilidades, son un hueco o una debilidad de una aplicación, la cual puede ser una falla de diseño o un bug de implementación, todo esto como se describió arriba, le permite al atacante poder causar daño a la información que incluye la aplicación; tales como: el dueño, usuarios y otras entidades que dependan de esa aplicación. Ejemplos de Vulnerabilidades:

Falta de validación en el ingreso de usuarios,
Falta de suficientes mecanismos de logging,
No cerrar la conexión de la base de datos correctamente,

OWASP también propone entre sus proyectos planes y medidas de contingencia. Los planes o medidas de contingencia son tecnologías o módulos defensivos que pueden ser usados para detectar, detener o denegar un ataque. Hay planes necesarios en una aplicación que deben identificar amenazas, usando análisis de amenazas, para así, proteger a la aplicación en contra de cualquier tipo de ataque basado. Una debilidad o una falla en el plan de contingencia, incluso la falta de un plan adecuado, puede resultar en una vulnerabilidad que deja susceptible a la aplicación.
Ejemplos de planes de contingencia:

Autentificación,
Control de Acceso,
Administrador de Sesión,
Validación del ingreso,
Manejo de errores,
Logging,
Criptografía,

OWASP tiene varios principios; se entiende por principios de seguridad de aplicaciones a las reglas fundamentales de seguridad que describen el correcto comportamiento y/o diseño de una aplicación, las cuales se pueden mejorar cambiando las posturas sobre seguridad. Estos principios son generales, deben tomarse solo como una guía y no como una manual de procedimientos a seguir. Con esta herramienta que OWASP presenta se tiene una ayuda más; en los momentos de tomar decisiones en nuevas situaciones, usando estas ideas básicas.

Algunos principios de seguridad en aplicaciones que han sido probados:

Tabla de contenidos

1 Defensa en profundidad
2 Usar un modelo de seguridad positiva
3 Fallar con Seguridad
4 Correr la aplicación con menos privilegios
5 Evitar la oscuridad en la seguridad
6 Mantener la seguridad simple
7 Detectar intrusos
8 No confíe en las infraestructuras
9 No confíe en los servicios
10 Establezca seguros por defecto
- 10.1 Métrica propuesta
11 Chapter de OWASP
12 Enlaces externos

[editar] Defensa en profundidad

La defensa en profundidad es una práctica estratégica para conseguir seguridad de la información en las redes actuales. Esta es la mejor práctica estratégica, la cual recaen en la aplicación inteligente de las técnicas y tecnologías que existen. Esta estrategia recomienda un balance entre la capacidad de protección, costo, perfomance y consideraciones operacionales. Este principio sugiere que en donde un control podría ser razonable, muchos controles que combatan los riesgos en diferentes formas son mejores. Los controles, cuando son usados en profundidad, pueden hacer que varias vulnerabilidades sean extraordinariamente difíciles de que sucedan o incluso imposible. Para resistir ataques contra la información y la información del sistema de forma efectiva, una organización necesita caracterizar: sus adversarios, sus potenciales motivaciones y sus clases de ataque. Los potenciales adversarios pueden incluir: el Estado de alguna Nación, terroristas, criminales, Hackers o competidores corporativos. Sus motivaciones pueden ser: robo de propiedad intelectual, denegación de servicio, entre otras. Sus clases de ataques pueden ser: monitores pasivos de la comunicación, ataques activos a la red, ataques close-in y ataques a través de los proveedores de recursos de tecnología de la información, entre otros. También es importante resistir a los efectos detrimentes de los eventos no malicioso como fuego, inundaciones, falta de corriente eléctrica y errores de usuarios. Asegurar la información se alcanza cuando esta y la del sistema son protegidos contra cualquier ataque a través de la aplicación de servicios de seguridad como: Disponibilidad, Integridad, Autentificación, Confidencialidad, y que no haya rechazo al uso de la aplicación. La aplicación de estos servicios debe estar basada en la protección, detección, y el paradigma de la reacción. Esto significa que, además de tener mecanismos de protección; la organización necesita esperar ataques e incluir herramientas de detección de ataques y procedimientos que permitan reaccionar y recuperarse ante los ataques. Un importante principio de la estrategia de defensa en profundidad es que para alcanzar la seguridad de la información esto requiere un balance centrado en tres elementos primarios: personas, tecnología y operaciones. Con una codificación segura, todo este tema puede tomar la forma de una validación basada en capas (tier-based validation; esto se refiere a una división lógica de una aplicación compleja en capas. Cada capa es parte de la arquitectura, y su separación es solo de forma lógica. En una empresa grande, cada capa puede estar en una computadora distinta para incrementar la seguridad y confiabilidad), con controles centralizados de auditoría y requerir que los usuarios se loggen en todas las páginas web de la aplicación.

[editar] Usar un modelo de seguridad positiva

Un modelo de seguridad “positivo” (también conocido como “whitelist” lista blanca) es en donde se define que es lo que esta permitido, y todo lo demás simplemente se lo rechaza. Esto debe ser contrastado con un modelo de seguridad “negativo” (o “blacklist” lista negra), el cual define que es lo que no esta permitido, mientras implícitamente permite todo lo demás. El modelo de seguridad positivo puede ser aplicado a un número diferente de áreas de seguridad en aplicaciones. Por ejemplo, cuando se realizan validaciones en las entradas, el modelo positivo dictamina que es lo que usted debe especificar como características de entrada que tendrán que ser permitidas, así como también que debe ser filtrado como un mal ingreso. En las áreas de control de acceso, el modelo positivo es para denegar a todo, y solo permitir el acceso específico a recursos o funciones autorizadas. El beneficio de usar un modelo positivo es que para los nuevos ataques, no anticipados por el desarrollador, serán prevenidos. Sin embargo, el modelo negativo puede ser bastante tentativo en el momento de intentar prevenir un ataque en un sitio. En última instancia, adoptar un modelo negativo significa que usted nunca estará seguro de que su modelo es totalmente completo. Además este modelo negativo termina por ser una enorme lista de firmas negativas en un bloque que debe ser mantenido. Si un programa no esta bien restringido en los datos que se le ingresan, esto puede ofrecer un riesgo, ya que los atacantes pueden encontrar que tiene un modelos de seguridad negativo. Muchas categorías superiores de la seguridad del software son en definitiva problemas de la validación de las entradas; tales como: buffer overflows, ataques de inyección a SQL (SQL injection attacks) y otros. Los datos que se ingresan a un programa pueden ser validos o inválidos. Lo que define su validez puede depender de las semánticas del programa. Una buena práctica de seguridad es identificar definitivamente todos los datos inválidos antes de cualquier acción que use información; y si los datos son inválidos, se debe actuar apropiadamente. Hay muchos niveles en donde se puede efectuar validaciones, los lugares más comunes incluyen:

Usos (esto se refiere a todos los lugares en el código en donde se hace uso de los datos, sobre todo los externos).
Puntos de entrada de las aplicaciones (justo antes o después de pasarle información a la aplicación, como un motor de validación en un servidor web para un web service).
Red sistemas tradicionales para la detección de intrusiones IDS (intrusion detection system).

A niveles más elevados se recomienda el uso de los ya nombrados Whitelist y Blacklist, pero además OWASP sugiere el uso de la validación criptográfica en todos los datos que use la aplicación web.

[editar] Fallar con Seguridad

Manejar errores en forma segura, es la clave principal para codificar de forma segura. Hay dos tipos diferentes de errores que merecen una atención especial. El primero son las excepciones que pueden ocurrir en el proceso de medidas tomadas en contra del mismo. Es importante que estas excepciones no generen comportamientos, que las medidas en contra de ellos normalmente no permitirían. El desarrollador, debe considerar que estas son generalmente tres posibles resultados de los mecanismos de seguridad:

Permitir la operación,
No permitir la operación,
Excepciones,

En general, se debería designar un mecanismo para que si llegara a fallar, le siga en la misma ejecución una operación que deniegue la operación. Por ejemplo: un método de seguridad como EstaAutorizado(), EstaAutenticado(), y Validado() debería devolver falso si existe una excepción durante el proceso. El otro tipo relevante de excepción en seguridad, es un mecanismo específico de seguridad del exterior; pero estos pueden afectar el flujo de control que invoca a esos mecanismos. Por ejemplo:

isAdmin = true; try { codeWhichMayFail(); isAdmin = isUserInRole( “Administrator” ); } catch (Exception ex) { log.write(ex.toString()); }

Si codeWhichMayFail() falla, el usuario será tomado por defecto como administrador. Esto es obviamente un riesgo en la seguridad. Cualquier mecanismo de seguridad debe ser diseñado de tal forma que, cuando falle, este sea un fallo cerrado. Esto significa que cuando falle debe caer en un estado de rechazo a todas las subsecuentes peticiones de seguridad en lugar de permitirlas. Un ejemplo puede ser la autenticación del sistema. Si no se puede procesar la petición de autenticación de un usuario o entidad y el proceso falla, todo pedido de autenticación posterior no debe retornar negativo o algún criterio de autenticación nula. Una buena analogía es un firewall. Si un firewall falla, debe tirar todos los subsecuentes paquetes.

Unas de las Top Ten vulnerabilidades de OWASP es: el inapropiado manejo de errores; las condiciones de un error pueden ocurrir durante una operación normal y esta puede no estar apropiadamente manejado. Si un atacante puede causar que ocurra un error, que la aplicación Web no maneja, el atacante puede ganar información detallada del sistema, denegar servicios, causar que los mecanismos de seguridad fallen o tirar el servidor.

[editar] Correr la aplicación con menos privilegios

En las ciencias de la computación y otros campos de investigación, el principio de privilegios mínimos, también llamado principio de menos privilegios, requiere en particular una abstracción de las capas de todos los entornos de computación; los cuales pueden ser: un proceso, un usuario o un programa, estos deben ser vistos como información o recursos necesarios. La idea de este principio es dar solo la menor cantidad de privilegios posibles para permitir acciones legítimas, y así proteger los datos y funcionalidades contra fallas y comportamientos maliciosos. En otras palabras es dar solo los permisos que el usuario necesita para hacer su trabajo adecuadamente. El principio de privilegios mínimos también es conocido como POLA: principle of least authority (principio de menos autoridad). Un ejemplo, si un servidor middleware solo requiere acceso a una red, permiso de lectura a una base de datos y poder escribir en un log, esto describe todos los permisos que debe tener concedidos. Bajo ninguna circunstancia debe el middleware tener permiso de administrador. Otro principio relacionado con esto es el de ventanas de vulnerabilidad. Esto significa que, cuando algún riesgo se debe introducir, se debe introducir solo por un corto tiempo. En el contexto de los privilegios, esto se traduce como que las cuentas de usuarios pueden recibir más privilegios, pero solo se les puede otorgar en situaciones que lo ameriten. Con todo esto, el principio de privilegios mínimos se mantiene, ya que solo cuando es necesario se les otorga e inmediatamente después de su uso, los privilegios son revocados. Una técnica muy efectiva para reforzar estos principios es la noción de separación de privilegios. Esta idea es que una aplicación se divida en dos partes, el núcleo de privilegios y la aplicación principal.

[editar] Evitar la oscuridad en la seguridad

La seguridad a través de la oscuridad es un control débil de seguridad, el cual casi siempre falla cuando se trata del control. Con esto no solo se trata de decir, que mantener secretos es una mala idea, simplemente significa que la clave para la seguridad del sistema no debe recaer sobre como mantener los detalles ocultos. Por ejemplo, la seguridad de la una aplicación Web no debe cimentarse en el conocimiento de que el código fuente se mantenga en secreto. La seguridad deber basarse en muchos otros factores, entre ellos políticas razonables de contraseñas, defensa en profundidad, límite de transacciones por trabajos, una sólida arquitectura de redes, y controles para detectar fraudes y realizar auditorías. Un ejemplo práctico de esto es Linux. El código fuente de Linux es ampliamente conocido y difundido, sin embargo cuando de seguridad se trata, este sistema operativo es seguro y robusto.

[editar] Mantener la seguridad simple

Ciertos softwares de ingeniería prefieren acercamientos demasiado complejos a lo que podría, ser de otra forma, relativamente directos o con hechos con una codificación simple. Los desarrolladores podrían evitar el uso de dobles negaciones y arquitecturas complejas cuando un acercamiento más simple puede ser más rápido o simple. Por ejemplo, a pesar de que puede estar más de moda tener una gran cantidad de entidades de un solo elemento, los cuales son reutilizable y modulares; corriendo en servidores middleware separados, es más seguro y más rápido simplemente usar variables globales con un apropiado mecanismo mutex (transmutador) para proteger contra las “condiciones de carrera”. Una de las vulnerabilidades que existen en este ámbito, también nombrada en el Top Ten de OWASP es: Inyección de Fallas; las aplicaciones Web pasan parámetros cuanto hacen un acceso a un sistema externo o a un sistema operativo local. Si un atacante pudiera embeber de código malicioso en estos parámetros, el sistema externo puede ejecutar esos comandos en nombre de la aplicación Web. Cada característica que pueda adicionarse a una aplicación, también le suma un cierto riesgo a la aplicación. El objetivo de la seguridad debe desarrollarse para reducir el riego global a través de la reducción del área de ataque. Por ejemplo, una aplicación web que implemente ayuda online con una función de buscar. Esta función puede ser vulnerable a los ataques de inyección de SQL (SQL injection attacks). Si la función solo se limita a los usuarios autorizados, las probabilidades se reducen. Si la función fue dada a través de rutinas centralizadas de validación de datos, la habilidad para realizar inyecciones SQL es dramáticamente reducida. Sin embargo, si la función de ayuda esta re-escrita para eliminar la función (a través de una interfaz de usuario, por ejemplo), esto prácticamente elimina el área de ataque.

[editar] Detectar intrusos

A través del loggueo de todos los usuarios se puede mantener información como IP, Nombre de Usuario, Tiempo, que sitio Web pidió, etc. Con toda esta información además de poder realizar estadísticas de la aplicación Web y del sitio; también sirve sobre todo como un resguardo, en un momento de crisis, y por crisis se entiende que el sitio ha sido bajado/hacheado, quien fue la ultima persona que tuvo acceso al sitio, etc. Al tener esta información se puede rastrear al malhechor (hacker) que causo la crisis. Incluso si el hacker usó un servidor Proxy todo esto puede ayudar. Unas de las vulnerabilidades que hay en cuanto al loggue son: Autentificación rota y manejo de sesión rota: Las credenciales de la cuenta y los [tokens] de la sesión no están correctamente protegidas. Los atacantes que puedan comprometer contraseñas, keys, cookies de sesión u otro token pueden derrotar la restricción de la autentificación y asumir la identidad de otro usuario. Fallas Cross site scripting (XSS): La aplicación Web puede usar mecanismos para transportar un ataque hasta el browser de un usuario. Un ataque victorioso puede mostrar el token de sesión del usuario, atacar a la maquina local, o mostrar información falsa para engañar al usuario. Estas también forman parte del OWASP top ten vulnerabilities. El control clave para detectar fraudes es la separación de tareas. Ciertos roles tienen diferentes niveles de confianza que los usuarios normales. En particular, los administradores son diferentes a los usuarios normales. En general, el administrador debe ser un usuario de la aplicación. Por ejemplo, un administrador debe estar habilitado a encender o apagar el sistema, disponer y acordar la política de password pero no debe poder logguearse como un usuario súper privilegiado y así poder hacer compras en nombre de otros usuarios.

[editar] No confíe en las infraestructuras

Esto se refiere a la apropiada administración de la configuración de la infraestructura del servidor Web, lo cual es muy importante para preservar la seguridad de la aplicación Web en sí misma. Si los elementos como el software del [servidor Web], el servidor de la [base de datos back-end] o el servidor de [autenticación] no están adecuadamente revisados y asegurados, estos pueden introducir un riesgo indeseado o introducir nuevas vulnerabilidades que pueden comprometer la aplicación misma. Por ejemplo, una vulnerabilidad del servidor Web puede permitir a un atacante remoto tener acceso al código fuente de la aplicación (esta vulnerabilidad puede estar en ambos el servidor Web o el servidor de la aplicación), puede comprometer la aplicación haciéndose pasar por usuarios anónimos pueden usar la información a la vista en el código fuente para desatar ataques contra la aplicación o a sus usuarios. En orden para testear la administración de la configuración de la infraestructura OWASP recomienda seguir los siguientes pasos:

Los diferentes elementos que hacen la infraestructura necesitan ser determinados para así entender como ellos van a interactuar con la aplicación Web y como ellos afectan la seguridad.
Todos los elementos de infraestructura necesitan ser revisados para poder asegurar que ellos no tienen o esconden alguna vulnerabilidad.
Se necesita hacer una revisión de todas las herramientas administrativas que serán usados para mantener a los diferentes elementos.
Si existe un sistema de autenticación, éste necesita ser revisado para poder asegurar que sirva a todas las necesidades de la aplicación y que no puede ser manipulado a través del acceso externo de los usuarios.

Otro punto dentro de la arquitectura es la revisión de la arquitectura de la aplicación. La aplicación puede tener muchas combinaciones con respecto a la configuración de sus servidores; algunos complejos, como tener: un servidor proxy, un servidor Web front-end, un servidor para la aplicación y un servidor de base de datos o un servidor LDAP. Cada uno de estos servidores serán usados para diferentes propósitos y podrán incluso ser divididos en diferentes redes con firewalls entre ellos creando así diferentes DMZ (zonas desmilitarizadas); todos estos elementos de la arquitectura pueden ser aislados de manera que no comprometerán a toda la arquitectura. Tener conocimiento de la arquitectura de la aplicación puede ser fácil, si esta información es provista para los equipos de testeo por los desarrolladores de la aplicación en documentos desde o a través de entrevistas y otras formas de documentación. Con toda esa información se puede mejorar la configuración de los servidores para brindar una mayor protección de acuerdo a las necesidades y arquitectura de la aplicación Web. Además es importante rever y testear la seguridad de la autentificación back-end para determinar que información se está almacenando, y que no puede ser recuperada de ninguna forma. Esto significa asegurar que la información de autentificación esta almacenada y encriptada, especialmente los password. Por supuesto los backup de la autentificación del sistema deben también estar encriptada para prevenir la pérdida de información.

[editar] No confíe en los servicios

Por servicios se refiere a que puede ser cualquier sistema externo. Muchas organizaciones utilizan la capacidad de procesamiento de terceros (compañías dedicadas a esa tarea en particular), quienes pueden tener políticas de seguridad distintas y posturas distintas a las que se vienen usando. Es poco probable que se tenga que influenciar o controlar a un tercero, cualquiera de ellos pueden ser home users o proveedores mayoristas o socios. Por eso, confiar implícitamente de sistemas que corren exteriormente, no tiene garantías. Todos los sistemas externos deben ser tratados en una manera similar. Por ejemplo, un proveedor confiable de programa, que provee datos, que pueden ser usados por [Internet Banking], que se encargue de la parte de promociones, en donde a esté se le encarga de los puntos de regalos a los usuarios y lista de premios potenciales. No obstante, los datos deben ser chequeados para asegurar que si esto es seguro para mostrar al usuario, y que los puntos de recompensa son números positivos, y no enormes.

[editar] Establezca seguros por defecto

Hay muchas maneras para hacer experiencias “out-of-the-box” (“fuera de la caja” se refiere a un producto que no se puede comprar en cualquiera tienda. La configuración para el usuario sería construido según especificaciones, las cuales son los requisitos mínimos para el usuario. También se puede decir que los seguros por defectos que sean creados tienen que estar dirigidos a un tipo de usuario). No obstante, por defecto, la experiencia debe ser segura, y esta debe ser para que los usuarios puedan reducir su propia seguridad; si están permitidos. Por ejemplo, por defecto, el tiempo de caducación y la complejidad del password deben estar permitidos. A los usuarios, se les puede permitir cambiar estos atributos del password para simplificar el uso de la aplicación y así incrementar el riesgo. Un sistema con seguridad por defecto no debe exponer a los usuarios a riesgos innecesarios y debe ser tan seguro como sea posible. Esto significa que todas las funcionalidades de seguridad deben estar encendidas, y todas las características opcionales que puedan dar a suponer un riesgo deben estar deshabilitadas por defecto. Esto también significa que, si hay algún tipo de falla en el sistema, el comportamiento no debe causar que el sistema se comporte de manera insegura, esto está reflejado en el principio de Fallar con seguridad. Por ejemplo, si una conexión no puede establecerse con el protocolo SSL (Secure Sockets Layer), no es una buena idea tratar de establecerla una conexión plaintext. La filosofía de seguros por defecto no interactúa bien con la usabilidad ya que, este es mucho más simple para los usuarios, los cuales pueden inmediatamente hacer uso del sistema, si todas las funcionalidades están permitidas. El usuario puede hacer uso de las funcionalidades, las cuales necesita e ignora las restantes. Sin embargo, los atacantes no podrán ignorar esta funcionalidad. Un sistema desarrollado con una configuración por defecto insegura asegura que una gran mayoría de los sistemas, que están completamente depurados, son vulnerables. En muchas circunstancias, esto puede llegar a ser muy difícil hacer un parche antes de que el sistema se vea comprometido. Por lo tanto, si hay varios riesgos de seguridad, que los usuarios no están dispuesto a aceptar, se debe preferir una configuración por defecto. Sino, al menos alertar a los usuarios de los riesgos y señalarle a través de documentación con estrategias para mitigar los riesgos. Hay que resaltar que, en un sistema con seguridad por defecto, el usuario deberá activarse cualquier funcionalidad que incremente su riesgo. Esas operaciones deben estar relativamente escondidas; por ejemplo tener un panel avanzado con preferencias de seguridad.

Por ultimo OWASP propone también dentro de sus proyectos, algunos ya terminados, el uso de actividades para la seguridad en las aplicaciones. Las actividades de seguridad son las prácticas primordiales que deben ser realizadas durante el ciclo de desarrollo del software, para así reducir riesgoso incrementar certeza y exactitud de la aplicación. OWASP tiene varios proyectos tanto como de documentación como de desarrollo entre ellos están:

OWASP AJAX Security Project (Proyecto de seguridad con AJAX de OWASP) – Este investiga la seguridad en las aplicaciones que puede proveer AJAX.

OWASP Application Security Assessment Standards Project (Proyecto para estandarizar la valoración de la seguridad en las aplicaciones).

OWASP .NET Project – Este proyecto está centrado en ayudar los desarrolladores de .NET en construir aplicaciones seguras, lamentablemente esta en una etapa alfa.

OWASP Pantera Web Assessment Studio Project – Focalizado en combinar capacidades automatizadas con un completo manual de testeo para obtener resultados óptimos.

OWASP PHP Project - Este proyecto está centrado en ayudar los desarrolladores de PHP en construir aplicaciones seguras.

OWASP Java Project - Este proyecto está centrado en ayudar los desarrolladores de Java y J2EE en construir aplicaciones seguras.

OWASP Risk Management Project – Un reciente proyecto centrado en el proceso para manejar riesgos en la seguridad de las aplicaciones.

OWASP Testing Project – Este proyecto se focaliza en procesos para testear la seguridad en las aplicaciones.

OWASP Validation Project – Este proyecto provee de una guía y herramientas relativas a la validación de las aplicaciones.

OWASP WASS Project – Un proyecto estándar para el desarrollo de criterios más concretos para la seguridad de las aplicaciones

OWASP WebGoat Project – Un proyecto online para entrenarse y conocer sobre la seguridad de las aplicaciones.

OWASP WebScarab Project – Esta es una herramienta para realizar todo tipo de testeo de seguridad en una aplicación Web y en Web service.

OWASP Application Security Metrics Project (Proyecto para realizar Métricas en la seguridad de las aplicaciones) – El objetivo es identificar y proveer un conjunto de métricas para medir la seguridad de las aplicaciones.

OWASP AppSec FAQ Project (Proyecto de Preguntas frecuentes echas sobre la seguridad de las aplicaciones) – Cuestionario con sus respectivas respuestas abarcando varios tópicos de seguridad.

OWASP CAL9000 Project (Proyecto CAL9000) – Es un programa echo en JavaScript para testear la seguridad de una aplicación.

OWASP CLASP Project (Proyecto CLASP) – El proyecto se focaliza en definir elementos de proceso que puedan reforzar la seguridad en una aplicación. CLASP (Comprehensive, Lightweight Application Security Process; Proceso de seguridad de aplicaciones liviano y comprensivo.

OWASP Code Review Project – Un proyecto nuevo que captura las mejores prácticas para revisar código.

OWASP Guide Project – Un enorme documento en el cual se cubren todos los aspectos sobre aplicaciones Web y seguridad en Web service.

OWASP Honeycomb Project – Este proyecto se dedica a realizar una guía para construir bloques de seguridad para aplicaciones.

OWASP LAPSE Project – El proyecto está acotado al desarrollo de una herramienta de condigo abierto para auditar Java.

OWASP Legal Project – Este proyecto provee de material relativo a los aspectos legales del software seguro, incluyendo contratación, la obligación y la conformidad.

OWASP Logging Project – Este define las mejores practicas para realizar logging y administración de log.

OWASP Top Ten Project – Un documento que describe el top 10 de las vulnerabilidades en las aplicaciones Web:

1. Ingreso no Validado: La información desde los pedidos de la Web no son validados antes de empezar a ser usados por una aplicación Web. Atacantes pueden usar esta falla para atacar los componentes backend de las aplicaciones Web.

2. Acceso de control roto: Las restricciones en cuanto a autentificar de los usuarios no esta debidamente reforzado. Los atacantes pueden utilizar esta falla para acceder a las cuentas de otros usuarios, ver archivos ocultos o usar funciones no autorizadas.

3. Autentificación rota y manejo de sesión rota.

4. Fallas Cross site scripting (XSS).

5. Desbordamiento del Buffer: En algunos lenguajes los componentes de una aplicación Web no validan apropiadamente el ingreso, que en algunos casos puede ser desastroso, en otras esto puede permitir el control de un proceso. Entre estos componentes están CGI, librerías, drivers, y los componentes del server de la aplicación Web.

6. Inyección de Fallas.

7. Inapropiado manejo de errores.

8. Almacenamiento inseguro: Las aplicaciones Web normalmente usan funciones de criptografía para proteger la información y las credenciales. Estas funciones y el código integrado resultan muy difícil de realizar, y frecuentemente terminan siendo una debilidad en la protección.

9. Denegación de Servicios (DOS): Los atacantes pueden consumir recursos de la aplicación Web a un punto donde los usuarios legítimos no pueden tener acceso o usar la aplicación. Los atacantes pueden también encerrar a un usuario fuera de su cuenta o incluso causar que toda la aplicación falle.

10. Configuración insegura de administración: Tener una fuerte configuración estándar del servidor es algo crítico para asegurar la aplicación Web. Estos servidores pueden tener opciones en la configuración, las cuales afectan la seguridad.

OWASP Metrics Project – El proyecto define métricas manejables para la seguridad en las aplicaciones. Desafortunadamente este proyecto como otros está estancando y con problemas para lograr un resultado aceptable. Como todo software es difícil medir la calidad del mismo o la del código, esto conlleva a un atraso y mucho debate en cuanto a una métrica que pueda medir a todas las aplicaciones, o en su defecto a poder tipificar las aplicaciones para así poder tener una métrica correcta que otorgue valores relevante.

[editar] Métrica propuesta

Por todo esto la autora sugiere la siguiente métrica, tomando como parámetros el proyecto OWASP top ten vulnerabilities, antes mencionado. En esta métrica se mide que tan vulnerable es una aplicación. Este tipo de métrica es LB (Lower is better), lo que significa que mientras “menos tenga, mejor”. El máximo es 100%, esto quiere decir que la aplicación es totalmente vulnerable y con un 0% que no lo es. De estas 10 vulnerabilidades, que puede tener una aplicación si posee 1, entonces tiene un 10% y de ahí se va incrementando hasta el máximo. A su vez cada vulnerabilidad tiene porcentajes del 0 al 100%. Por ejemplo se puede dar el caso que una aplicación tenga ingreso no validado en solo un ingreso; lo cual nos da un 1% del porcentaje de la vulnerabilidad, pero nos daría un 0.1% de la vulnerabilidad de toda la aplicación. Esta métrica es solo es un esbozo.

[editar] Chapter de OWASP

Unos de los Chapter es ASIRA [1] el cual es el perteneciente a la Argentina. ASIRA comparte los mismos objetivos e ideales que OWASP. Las reuniones de ASIRA son con los profesionales y especialistas en seguridad de la información enfocadas a los cuestionamientos, las fórmulas de solución y especialmente a la divulgación de los resultados. La sede esta ubicada en, Av. Córdoba 1439 1º piso, Capital Federal. El estudio de OWASP ARGENTINA esta dirigido a: Análisis de las nuevas tecnologías de la información y las comunicaciones. Investigación de fallas y vulnerabilidades sobre las TIC. Análisis de productos (Software & Appliances). Errores y vicios en programación que conducen a errores de seguridad. Análisis de bugs de seguridad. Desarrollo de programas y técnicas de exploit relacionadas. Documentación de soluciones de seguridad. Desarrollo de herramientas de seguridad. Conferencias. Demostraciones. Debates y desarrollo investigativo. Las actividades OWASP giraran en torno al desarrollo de grupos de estudio en dos modalidades: In-site. A través de reuniones y desayunos de trabajo dentro de las instalaciones de ASIRA. Out-site – online. Dentro de la asociación existen canales IRC dedicados a distintas temáticas y se instaurará un canal dedicado a las actividades OWASP.