Verificando la seguridad - owasp

... Kiddy son insumos, que si el médico infiere la necesidad de ser empleados,
...... o practica de algún examen) los cuales ascienden a $500.000 mensuales.

Part of the document

OWASP Top 10
Las 10 vulnerabilidades de seguridad mas criticas en aplicaciones web version 2007 en español © 2002-2007 Fundación OWASP Este documento se encuentra bajo licencia Creative Commons Attribution-
ShareAlike 2.5 Tabla de contenidos
Tabla de contenidos 2 Sobre esta versión 3 Introducción 4 Resumen 5 Metodología 67 A1 - Secuencia de Comandos en Sitios Cruzados (XSS) 1011 A2 - Fallas de inyeccion 1314 A3 - Ejecución de ficheros malintencionados 1617 A4 - Referencia Directa a Objetos Insegura 2021 A5 - Vulnerabilidades de Falsificación de Petición en Sitios Cruzados
(CSRF) 2324 A6 - Revelación de Información y Gestión Incorrecta de Errores 2627 A7 - Perdida de Autenticacion y Gestion de Sesiones 2829 A8 - Almacenamiento criptografico inseguro 3031 A9 - Comunicaciones inseguras 3233 A10 - Falla de restricción de acceso a URL 3435 ¿Donde sigo Ahora? 3738 Referencias 4041 Sobre esta versión
Esta versión de Top 10 2007 en español ha sido desarrollada como parte de
las actividades del capitulo OWASP Spanish para la comunidad de
desarrolladores y seguridad informática de habla hispana.
Participaron de esta traducción:
. Fabio Cerullo
. Jaime Blasco
. Miguel Tubia
. David Echarri
. Emilio Casbas
. Miguel Macias
. Guillermo Correa
. Luis Martinez Bacha
. Camilo Vega
. Jesús Gómez
. Rodrigo Marcos
. Juan Carlos Calderón
. Javier Fernández-Sanguino
Para saber máas sobre los eventos y actividades desarrolladas por el
capíitulo OWASP-Spanish, suscríbase a la lista de distribución OWASP-
Spanish.
Introducción
¡Bienvenido al OWASP Top 10 2007! Esta versión totalmente revisada lista
las vulnerabilidades más serias de aplicaciones Web, discute como
protegerse de ellas, y provee enlaces para mayor información. Objetivo
El objetivo principal del OWASP Top 10 es educar a desarrolladores,
diseñadores, arquitectos y organizaciones sobre las consecuencias de las
vulnerabilidades más comunes encontradas en aplicaciones Web. El Top 10
provee métodos básicos para protegerse de dichas vulnerabilidades - un gran
comienzo para un programa de seguridad en codificación programación segura.
Seguridad no es un evento único. Es insuficiente codificar programar de
manera segura sólo una vez. En 2008, este Top 10 habrá cambiado, y sin
cambiar una línea de código en su aplicación, usted podría ser vulnerable.
Por favor revise los consejos en la sección ¿Donde sigo ahora? para mayor
información. Una iniciativa de codificación programación segura debe abordar todas las
etapas del ciclo de vida de un programa. Aplicaciones Web seguras sóolo son
posibles cuando es utilizado uun SDLC seguro es utilizado. Los programas
seguros son seguros por diseño, durante el desarrollo, y por defecto.
Existen al menos 300 problemas que afectan la seguridad general de una
aplicación Web. Estos son detallados en la Guía OWASP, la cual es de
lectura esencial para cualquiera desarrollando aplicaciones Web hoy en día. Este documento es sobre todo, un recurso de estudio, y no un estándar. Por
favor no adopte este documento como una política o estándar sin antes
hablar con nosotros. Si usted necesita una política o estándar de
codificación segura, OWASP dispone de proyectos en progreso sobre políticas
o estándares de codificación segura. Por favor considere unirse o asistir
financieramente con estos esfuerzos. Agradecimientos
Quisiéramos agradecer a MITRE por distribuir públicamente y de manera
gratuita los datos de "Vulnerability Type Distribution in CVE". El proyecto
OWASP Top 10 es dirigido y patrocinado por Aspect Security. Líder de Proyecto: Andrew van der Stock (Director Ejecutivo, Fundación
OWASP) Co-autores: Jeff Williams (Presidente, Fundación OWASP), Dave Wichers
(Presidente de la Conferencia, Fundación OWASP) Quisiéramos agradecer a nuestros revisores: . Raoul Endres por su ayuda en poner nuevamente en movimiento el Top 10
y sus valiosos comentarios. . Steve Christey (MITRE) por una extensiva revisión y su contribución de
información sobre MITRE CWE. . Jeremiah Grossman (White Hat Security) por una extensiva revisión y su
contribución de información acerca del éxito (o fracaso) de medios
automáticos de detección. . Sylvan von Stuppe por su revisión ejemplar del presente documento. . Colin Wong, Nigel Evans, Andre Gironda, Neil Smithline por sus
comentarios vía e-mail. Resumen |A1 - Secuencia de |Las fallas de XSS ocurren cuando una aplicación |
|Comandos en Sitios |toma información originada por un usuario y la |
|Cruzados (XSS) |envía a un navegador Web sin primero validar o |
| |codificar el contenido. XSS permite a los atacantes|
| |ejecutar secuencias de comandos en el navegador Web|
| |de la víctima que pueden secuestrar sesiones de |
| |usuario, desconfigurar modificar sitios Web, |
| |insertar contenido hostil, etc. |
|A2 - Fallas de |Las fallas de inyección, en particular la inyección|
|Inyección |SQL, son comunes en aplicaciones Web. La inyección |
| |ocurre cuando los datos proporcionados por el |
| |usuario son enviados e interpretados como parte de |
| |una orden o consulta. Los atacantes "trucan" ael |
| |interrumpen el intérprete para que ejecute comandos|
| |no intencionados proporcionando datos especialmente|
| |modificados. |
|A3 - Ejecución de |El cCódigo vulnerable a la inclusión remota de |
|ficheros |ficheros (RFI) permite a los atacantes incluir |
|malintencionados |código y datos maliciosos, resultando en ataques |
| |devastadores, tales como la obtención de controlun |
| |total compromiso del servidor. Los ataques de |
| |ejecución de ficheros malintencionados afectan a |
| |PHP, XML y cualquier entorno de trabajo que acepte |
| |ficheros de los usuarios. |
|A4 - Referencia |Una referencia directa a objetos ("direct object |
|Insegura y Directa |reference") ocurre cuando un programador expone una|
|a Objetos Insegura |referencia hacia un objeto interno de la |
| |aplicación, tales como un fichero, directorio, |
| |registro de base de datos, o una clave tal como una|
| |URL o un parámetro de formulario Web. Un atacante |
| |podría manipular este tipo de referencias en la |
| |aplicación para acceder a otros objetos sin |
| |autorización. |
|A5 - Falsificación |Un ataque CSRF fuerza ael navegador validado de una|
|de Petición en |víctima a enviar una petición a una aplicación Web |
|Sitios Cruzados |vulnerable, la cual entonces realiza la acción |
|(CSRF) |elegida por el atacante a través de la víctima. |
| |CSRF puede ser tan poderosa como la aplicación |
| |siendo atacada. |
|A6 - Revelación de |Las aplicaciones pueden revelar, involuntariamente,|
|Información y |información sobre su configuración, su |
|Gestión Incorrecta |funcionamiento interno, o pueden violar la |
|de Errores |privacidad a través de una variedad de problemas. |
| |Los atacantes pueden usar esta vulnerabilidad para |
| |obtener datos sensiblesdelicados o realizar ataques|
| |más serios. |
|A7 - Perdida de |Las credenciales de cuentas y los testigos de |
|Autenticación y |sesión (session token) son frecuentemente no son |
|Gestión de Sesiones|protegidos adecuadamente. Los atacantes obtienen |
| |contraseñas, claves, o testigos de sesión para |
| |asumir obtener identidades de otros usuarios. |
|A8 - Almacenamiento|Las aplicaciones Web raramente utilizan funciones |
|Criptográfico |criptográficas adecuadamente para proteger datos y |
|Inseguro |credenciales. Los atacantes usan datos débilmente |
| |protegidos para conducir llevar a cabo robos de |
| |identidad y otros crímenes, tales como fraude de |
| |tarjetas de crédito. |
|A9 - Comunicaciones|Las aplicaciones frecuentemente fallan al cifrar |
|Inseguras |tráfico de red cuando es necesario proteger |
| |comunicaciones sensiblesdelicadas. |
|A10 - Falla de |Frecuentemente, una aplicación solo protege |
|restricción de |funcionalidades sensiblesdelicadas previniendo la |
|acceso a URL |visualización de enlaces o Urls URLs a usuarios no |
| |autorizados. Los atacantes utilizan esta debilidad |
| |para acceder y llevar a cabo operaciones no |
| |autorizadas accediendo a esas Urls URLs |
| |directamente. |
Tabla 1: Las Top 10 vulnerabilidades de aplicaciones Web en 2007 Metodología
Nuestra metodología para el Top 10 2007 fue simple: tomar el MITRE
Vulnerability Trends for 2006, y filtrar los Top 10 problemas de seguridad
en aplicaciones Web. El ranking es el siguiente: [pic] Figura 2: Datos de MITRE sobre las Top 10 vulnerabilidades de aplicaciones
Web en 2006 A pesar de que intentamos preser