Professional Documents
Culture Documents
G O
U R R M I D T A I D C
INTEGRANTES: LADY RUTH CABEZAS RODAS NERY MONTENEGRO CARRASCO JUAN ORJEDA RAMIREZ
I S N E F
G O
U R R M I D T A I D C
Es una metodologa de seguridad abierta y colaborativa, orientada al anlisis de seguridad de aplicaciones Web, y usada como referente en auditoras de seguridad. La Fundacin OWASP es un organismo sin nimo de lucro que apoya y gestiona los proyectos e infraestructura de OWASP. La comunidad OWASP est formada por empresas, organizaciones educativas y particulares de todo mundo.
I S N E F
G O
U R R M I D T A I D C
METODOLOGA
I S N E F
Paso 1: La identificacin de un riesgo El primer paso es identificar un riesgo de seguridad que hay que clasificar. Usted tendr que recopilar informacin sobre el agente de amenaza en cuestin, el ataque se est utilizando, la vulnerabilidad en cuestin y el impacto de un exploit con xito en su negocio.
G O
U R R M I D T A I D C
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
Oportunidad Qu recursos y las oportunidades se requieren para este grupo de agentes de amenaza para encontrar y explotar esta vulnerabilidad? Acceso completo o costosos recursos requeridos (0), el acceso y los recursos especiales necesarios (4), algunas de acceso o los recursos necesarios (7), sin acceso o los recursos necesarios (9) Tamao Qu tan grande es este grupo de agentes de amenaza? Desarrolladores (2), los administradores del sistema (2), los usuarios de la intranet (4), socios (5), los usuarios autenticados (6), los usuarios annimos de Internet (9)
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
Conciencia Qu tan bien conocido es la vulnerabilidad a este grupo de agentes de amenaza? Desconocido (1), oculto (4), obvio (6), el conocimiento pblico (9)
Deteccin de intrusiones Qu tan probable es una vulnerabilidad para ser detectado? Deteccin activa de aplicacin (1), registrado y revisado (3), conectado sin revisin (8), no conectado (9)
I S N E F
Paso 3: Decidir que se debe corregir Despus de haber clasificado los riesgos para su aplicacin, tendr una lista de prioridades de lo que debe arreglar. Como regla general, debe fijar los riesgos ms graves primero. Simplemente no ayuda a su perfil general de riesgo de fijar riesgos menos importantes, incluso si son fciles o baratos de arreglar.
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
G O
U R R M I D T A I D C
Esta actualizacin ampla una de las categoras de la versin 2010 para ser ms inclusivo, de importantes vulnerabilidades comunes, y reordena algunos de los dems basndose en el cambio de los datos de prevalencia. El OWASP Top 10 se basa en los datos de riesgo de 8 empresas que se especializan en seguridad de aplicaciones
OBJETIVO
I S N E F
G O
U R R M I D T A I D C
El objetivo principal de la OWASP Top 10 es educar a los desarrolladores, diseadores, arquitectos, gerentes y organizaciones sobre las consecuencias de los ms importantes puntos dbiles de seguridad de aplicaciones web.
A1 -INYECCIN
I S N E F
G O
U R R M I D T A I D C
Las fallas de inyeccin, tales como SQL, OS, y la inyeccin LDAP se producen cuando los datos no son de confianza se envan a un intrprete como parte de un comando o consulta. Datos hostiles del atacante puede engaar al intrprete para que ejecute comandos no deseados o acceder a datos no autorizados.
I S N E F
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE? La mejor manera de saber si una aplicacin es vulnerable a inyeccin es verificar que todo uso de los interpretes claramente separe datos no confiables del comando o consulta. Para llamados SQL, esto significa utilizar variables parametrizadas en todas las declaraciones preparadas y procedimientos almacenados, como as tambin evitar consultas dinmicas.
G O
U R R M I D T A I D C
I S N E F
CMO PUEDO EVITAR ESTO? Prevenir la inyeccin requiere mantener los datos no confiables separados de comandos y consultas. 1. La opcin preferida es utilizar una API segura. 2. Si una API no se encuentra disponible, usted debe cuidadosamente escapar los caracteres especiales, utilizando una sintaxis de escape especial para dicho intrprete.
G O
U R R M I D T A I D C
I S N E F
EJEMPLOS DE ESCENARIOS DE ATAQUE La aplicacin utiliza datos no confiables en la construccin de la siguiente consulta vulnerable SQL:
G O
U R R M I D T A I D C El atacante modifica el parmetro 'id' en su navegador para enviar:' or 1'=1. Esto cambia el significado de la consulta devolviendo todos los registros de la tabla ACCOUNTS en lugar de solo el cliente solicitado.
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE?
Los primeros activos a proteger son las credenciales y los identificadores de sesin. 1. Se pueden adivinar o sobrescribir las credenciales a travs de funciones dbiles de gestin de la cuenta ? 2. Se muestran los identificadores de sesin en la direccin URL? (por ejemplo, re-escritura de la direccin)? 3. Son los identificadores de sesin vulnerables a ataques de fijacin de la sesin? 4. Caducan las sesiones y pueden los usuarios cerrar sus sesiones?
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE?
Los primeros activos a proteger son las credenciales y los identificadores de sesin. 1. Se pueden adivinar o sobrescribir las credenciales a travs de funciones dbiles de gestin de la cuenta ? 2. Se muestran los identificadores de sesin en la direccin URL? (por ejemplo, re-escritura de la direccin)? 3. Son los identificadores de sesin vulnerables a ataques de fijacin de la sesin? 4. Caducan las sesiones y pueden los usuarios cerrar sus sesiones?
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
Un usuario autenticado en el sitio quiere mostrar la venta a sus amigos. Enva por correo electrnico el enlace anterior, sin ser consciente de que est proporcionando su identificador de sesin. Cuando sus amigos utilicen el anterior enlace utilizarn su sesin y su tarjeta de crdito.
I S N E F
G O
U R R M I D T A I D C
A3 SECUENCIA DE COMANDOS EN
I S N E F
G O
U R R M I D T A I D C
Las fallas de XSS ocurren cuando una aplicacin toma datos no confiables y la enva a un navegador web sin necesidad de una correcta validacin o escapar.
XSS permite a los atacantes ejecutar scripts en el navegador de la vctima, que pueden secuestrar sesiones de usuario, modificar sitios Web, o redirigir al usuario a sitios maliciosos.
I S N E F
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE?
Es necesario asegurarse que todos los datos de entrada suministrados por el usuario enviados al navegador sean seguros (a travs de validacin de entradas), y que las entradas de usuario sean apropiadamente escapadas antes de que sean incluidas en la pagina de salida. Una apropiada codificacin de salida asegura que los datos de entrada sean siempre tratados como texto en el navegador, en lugar de contenido activo que puede ser ejecutado.
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
2.
I S N E F
G O
U R R M I D T A I D C
Esto causa que el identificador de sesin de la victima sea enviado al sitio web del atacante, permitiendo al atacante secuestrar la sesin actual del usuario.
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE?
La mejor manera de poder comprobar si una aplicacin es vulnerable a referencias inseguras a objetos es verificar que todas las referencias a objetos tienen las protecciones apropiadas. Para conseguir esto, considerar: 1. para referencias directas a recursos restringidos, la aplicacin necesitara verificar si el usuario est autorizado a acceder al recurso en concreto que solicita. 2. si la referencia es una referencia indirecta, la correspondencia con la referencia directa debe ser limitada a valores autorizados para el usuario en concreto.
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
1. Utilizar referencias indirectas por usuario o sesin. Esto evitara que los atacantes accedieren directamente a recursos no autorizados. 2. Comprobar el acceso. Cada uso de una referencia directa a un objeto de una fuente que no es de confianza debe incluir una comprobacin de control de acceso para asegurar que el usuario est autorizado a acceder al objeto solicitado.
I S N E F
G O
U R R M I D T A I D C
El atacante simplemente modificara el parmetro acct en su navegador para enviar cualquier nmero de cuenta que quiera. Si esta accin no se verifica, el atacante podra acceder a cualquier cuenta de usuario, en vez de a su cuenta de cliente correspondiente.
http://example.com/app/accountInfo?acct=notmyacct
I S N E F
G O
U R R M I D T A I D C
Un ataque CSRF obliga al navegador de una victima autenticada a enviar una peticin HTTP falsificado, incluyendo la sesin del usuario y cualquier otra informacin de autenticacin incluida automticamente, a una aplicacin web vulnerable. Esto permite al atacante forzar al navegador de la victima para generar pedidos que la aplicacin vulnerable piensa son peticiones legtimas provenientes de la victima.
I S N E F
G O
U R R M I D T A I D C
Un ataque CSRF obliga al navegador de una victima autenticada a enviar una peticin HTTP falsificado, incluyendo la sesin del usuario y cualquier otra informacin de autenticacin incluida automticamente, a una aplicacin web vulnerable. Esto permite al atacante forzar al navegador de la victima para generar pedidos que la aplicacin vulnerable piensa son peticiones legtimas provenientes de la victima.
I S N E F
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE?
La forma ms sencilla de revisar la vulnerabilidad en una aplicacin, es verificando si cada enlace, y formulario, contiene un testigo (token) no predecible para cada usuario. Si no se tiene dicho testigo, los atacantes pueden falsificar peticiones. La herramienta de pruebas para CSRF, elaborada por OWASP, puede ayudar a generar casos de prueba que sean utilizados por los demonios diseados para detectar fallos relacionados con CSRF.
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE?
Ha fortalecido la seguridad en todos los niveles de la pila de la aplicacin? 1. Tiene implementados procesos que permitan mantener actualizado el software de su organizacin? 2. Todo lo innecesario ha sido deshabilitado, removido o desinstalado? 3. Ha cambiado, o deshabilitado, las contraseas de las cuentas predeterminadas? 4. Ha configurado el sistema de manejo de errores para prevenir que se acceda de forma no autorizada a los mensajes de error? 5. Se han comprendido y configurado de forma adecuada las caractersticas de seguridad de las bibliotecas y ambientes de desarrollo (p.e. Struts, Spring, SEAM, ASP.NET)?
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
3. 4.
I S N E F
G O
U R R M I D T A I D C
Escenario #2: El listado del contenido de los directorios no est deshabilitado en el servidor. Los atacantes descubren que pueden encontrar cualquier archivo simplemente consultando el listado de los directorios. Los atacantes encuentran y descargan las clases java compiladas. Dichas clases son desensambladas por ingeniera reversa para obtener su cdigo. A partir de un anlisis del cdigo se pueden detectar defectos en el control de acceso de la aplicacin.
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE?
Lo primero que debe identificar son los datos que son suficientemente sensibles y requieren cifrado. Por ejemplo, contraseas, tarjetas de crdito, datos mdicos e informacin personal. Para todos ellos, asegrese de que: 1. Est cifrado en todos aquellos lugares donde es almacenado durante periodos largos, especialmente en copias de seguridad de estos datos. 2. Slo usuarios autorizados tienen acceso a los datos descifrados 3. Utilice un algoritmo estndar seguro. 4. Genere una clave segura, protjala ante accesos no autorizados y elabore un plan para el cambio de claves.
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
Escenario #1: Una cinta de backup almacena datos mdicos cifrados pero la clave en cifrado se encuentra en el mismo backup. La cinta nunca llega al centro de copias de seguridad.
Escenario #2: La base de datos de contraseas usa hashes sin sal para almacenar las contraseas de todos los usuarios. Una vulnerabilidad en la subida de ficheros permite a un atacante obtener el fichero de contraseas. Todos los hashes sin sal se pueden romper en 4 semanas, mientras que los hashes con sal llevaras ms de 3000 aos.
I S N E F
G O
U R R M I D T A I D C
Muchas aplicaciones web verifican los privilegios de acceso a URLs antes de generar enlaces o botones protegidos. Sin embargo, las aplicaciones necesitan realizar controles similares cada vez que estas pginas son accedidas, o los atacantes podrn falsificar URLs para acceder a estas pginas igualmente.
I S N E F
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE?
La mejor manera de averiguar si una aplicacin falla en restringir adecuadamente el acceso a URLs es verificar cada pgina. Considere por cada pgina si sta debe ser pblica o privada. Si debe ser privada: Se requiere autenticacin para acceder a la pgina?Se supone que debe ser accesible para cualquier usuario autenticado? Si no, se hace una verificacin de autorizacin para asegurar que el usuario tiene permiso de acceder dicha pgina? Los mecanismos de seguridad externos con frecuencia proveen mecanismos de autenticacin y autorizacin para el acceso a pginas. Tests de intrusin pueden tambin establecer si esta proteccin est configurada
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
Las aplicaciones frecuentemente fallan al autenticar, cifrar, y proteger la confidencialidad e integridad de trfico de red sensible. Cuando esto ocurre, es debido a la utilizacin de algoritmos dbiles, certificados expirados, invlidos, o sencillamente no utilizados correctamente.
I S N E F
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE?
La mejor forma de averiguar si una aplicacin se encuentra insuficientemente protegida en la capa de transporte, es verificar que: 1. Se utiliza SSL para proteger todo el trfico relacionado con la autenticacin. 2. Se utiliza SSL para todos los recursos de pginas y servicios privados. Esto protege todos los datos de sesin que se intercambian. Se debe evitar el acceso SSL nicamente a determinados recursos de una pgina ya que esto provoca advertencias en el navegador y puede exponer el identificador de sesin de los usuarios.
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
Escenario #1: Una aplicacin no utiliza SSL para todas las pginas que requieren autenticacin. El atacante simplemente captura el trfico de red (por ejemplo, a travs de una red inalmbrica abierta o un sistema vecino de su red cableada), y observa la cookie de sesin de una vctima autenticada.
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
SOY VULNERABLE?
La mejor forma de averiguar si una aplicacin dispone de redirecciones y reenvos no validados, es verificar que: Se revisa el cdigo para detectar el uso de redirecciones o reenvos (llamados transferencias en .NET). Para cada uso, identificar si la URL objetivo se incluye en el valor de algn parmetro. Si es as, verificar que el parmetro se comprueba para que contenga nicamente un destino, o un recurso de un destino, vlido.
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
I S N E F
G O
U R R M I D T A I D C
Escenario #1: La aplicacin tiene una pgina llamada redirect.jsp que recibe un nico parmetro llamado url. El atacante compone una URL maliciosa que redirige a los usuarios a una aplicacin que realiza el phishing e instala cdigo malicioso.