I S N E F

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

METODOLOGA DE EVALUACIN DE RIESGOS OWASP

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

Paso 2: Factores de Amenaza Agente

I S N E F Nivel Cmo tcnicamente es calificada este grupo de agentes de amenaza? Habilidades de seguridad de penetracin (1), redes y conocimientos de programacin (3), usuario avanzado de computadores (4), algunas habilidades tcnicas (6), sin necesidad de conocimientos tcnicos (9) Motivo Qu tan motivado est este grupo de agentes de amenaza para encontrar y explotar esta vulnerabilidad? Baja o ninguna recompensa (1), posible recompensa (4), alta recompensa (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

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)

Paso 2: Factores de Vulnerabilidad

I S N E F Facilidad de descubrimiento Es fcil para este grupo de agentes de amenaza para descubrir esta vulnerabilidad? Prcticamente imposible (1), difcil (3), fcil (7), herramientas automatizadas disponibles (9) Facilidad de explotar Es fcil para este grupo de agentes de amenaza de explotar realmente esta vulnerabilidad? Terico (1), difcil (3), fcil (5), las herramientas automatizadas disponibles (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

Paso 4: Personalizacin de la Clasificacin de Riesgo segn modelo

Tener un marco de clasificacin de riesgos que es adaptable para un negocio es fundamental para la adopcin. Un modelo a medida es mucho ms probable que produzca resultados que coinciden con las percepciones de la gente sobre lo que es un grave riesgo. Podemos adaptarnos a estos modelos:
ADICCION DE FACTORES PERSONALIZACION DE FACTORES

G O
U R R M I D T A I D C

OWASP TOP 10-2013

I S N E F

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

A2 PRDIDA DE AUTENTICACIN Y GESTIN DE SESIONES

Funciones de aplicacin relacionados con la autenticacin y gestin de sesiones a menudo no se aplican correctamente, lo que permite a los atacantes comprometer contraseas, llaves, los tokens de sesin, o la explotacin de otros defectos de implementacin para asumir la identidad de otros 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

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

CMO PUEDO EVITAR ESTO?

La recomendacin principal para una organizacin es facilitar a los desarrolladores: 1. 2. Un nico conjunto de controles de autenticacin fuerte y gestin de sesiones. Se debe hacer especial hincapi en evitar vulnerabilidades de XSS que podran ser utilizadas para robar identificadores de sesin.

G O
U R R M I D T A I D C

I S N E F

EJEMPLOS DE ESCENARIOS DE ATAQUE

Escenario #1: Aplicacin de reserva de vuelos que soporta reescritura de direcciones URL poniendo los identificadores de sesin en la propia direccin:

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

EJEMPLOS DE ESCENARIOS DE ATAQUE

Escenario #2: No se establecen correctamente los tiempos de desconexin en la aplicacin. Un usuario utiliza un ordenador pblico para acceder al sitio. En lugar de utilizar la funcin de Cerrar sesin, cierra la pestaa del navegador y se marcha. Un atacante utiliza el mismo navegador al cabo de una hora, y ese navegador todava se encuentra autenticado.

G O
U R R M I D T A I D C

A3 SECUENCIA DE COMANDOS EN
I S N E F

SITIOS CRUZADOS (xss)

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

CMO PUEDO EVITAR ESTO?

Prevenir XSS requiere mantener los datos no confiables separados del contenido activo del navegador. 1. La opcin preferida es escapar todos los datos no confiables basados en el contexto HTML (cuerpo, atributo, JavaScript, CSS, o URL) donde los mismos sern ubicados. Una validacin de entradas positiva o whitelist con apropiada canonicalizacin y decodificacin es tambin recomendable ya que ayuda a proteger contra XSS

G O
U R R M I D T A I D C

2.

I S N E F

EJEMPLOS DE ESCENARIOS DE ATAQUE

La aplicacin utiliza datos no confiables en la construccin del siguiente cdigo HTML sin validar o escapar los datos.

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.

El atacante modifica el parmetro CC en el navegador:

I S N E F

A4 REFERENCIA DIRECTA INSEGURA A OBJETOS

Una referencia directa a objetos ocurre cuando un desarrollador expone una referencia a un objeto de implementacin interno, tal como un fichero, directorio, o base de datos. Sin un chequeo de control de acceso u otra proteccin, los atacantes pueden manipular estas referencias para acceder datos no autorizados.

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

CMO PUEDO EVITAR ESTO?

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

EJEMPLOS DE ESCENARIOS DE ATAQUE

La aplicacin utiliza datos no verificados en una llamada SQL que accede a informacin sobre la cuenta:
Stringquery= "SELECT * FROM acctsWHERE account= ?"; PreparedStatementpstmt=connection.prepareStatement(query, ); pstmt.setString( 1, request.getparameter("acct")); ResultSetresults= pstmt.executeQuery( );

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

A5 FALSIFICACIN DE PETICIONES EN SITIOS CRUZADOS (CSRF)

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

A5 FALSIFICACIN DE PETICIONES EN SITIOS CRUZADOS (CSRF)

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

CMO PUEDO EVITAR ESTO?

Para prevenir la CSFR se necesita incluir un testigo no predecible en el cuerpo, o URL, de cada peticin HTTP. Dicho testigo debe ser, como mnimo, nico por cada sesin de usuario. El Guardin CSRF de la OWASP, puede ser utilizado para incluir automticamente los testigos en aplicaciones Java EE, .NET o PHP. La API ES de la OWASP, incluye generadores y validadores de testigos que los realizadores de software pueden usar para proteger sus transacciones.

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 permite que los usuarios enven peticiones de cambio de estado, que no incluyen nada secreto. Por ejemplo http://example.com/app/transferFunds?amount=1500&destinationAcco unt=4673243243 El atacante puede construir una peticin que transfiera dinero desde la cuenta de la vctima a su propia cuenta. Podr insertar su ataque dentro de una etiqueta de imagen en un sitio web, o iframe, que est bajo su control y al que la vctima se podr dirigir. <imgsrc="http://example.com/app/transferFunds?amount=1500&destin ationAccount=attackersAcct#width="0" height="0" /> Cuando la vctima visite el sitio, en lugar de cargarse la imagen, se realizar la peticin HTTP falsificada. Si la vctima previamente haba adquirido privilegios entonces el ataque ser exitoso.

G O
U R R M I D T A I D C

I S N E F

A6 DEFECTUOSA CONFIGURACIN DE SEGURIDAD

Una buena seguridad requiere tener definida e implementada una configuracin segura para la aplicacin, marcos de trabajo, servidor de aplicacin, servidor web, base de datos, y plataforma. Todas estas configuraciones deben ser definidas, implementadas, y mantenidas ya que por lo general no son seguras por defecto. Esto incluye mantener todo el software actualizado, incluidas las libreras de cdigo utilizadas por la aplicacin.

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

CMO PUEDO EVITAR ESTO?

Las principales recomendaciones se enfocan en establecer lo siguiente: 1. 2. Un proceso repetible que permita configurar, rpida y fcilmente, entornos asegurados. Un proceso para mantener y desplegar todas actualizaciones y parches de software de manera oportuna. Este proceso debe seguirse en cada uno de los ambientes de trabajo. Una arquitectura robusta de la aplicacin que provea una buena separacin y seguridad entre los componentes. Considerar la realizacin peridica de exploraciones (scan) y auditorias para ayudar a detectar fallos en la configuracin o parches faltantes.

G O
U R R M I D T A I D C

3. 4.

I S N E F

EJEMPLOS DE ESCENARIOS DE ATAQUE

Escenario #1: La consola de administracin del servidor de aplicaciones est instalada y no ha sido removida. Las cuentas predeterminadas no han sido cambiadas. Los atacantes descubren que las pginas de administracin estn activas, se registran con las claves predeterminadas y toman posesin de los servicios.

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

A7 ALMACENAMIENTO CRIPTOGRFICO INSEGURO

Muchas aplicaciones web no protegen adecuadamente los datos sensibles, tales como tarjetas de crdito, NSSs, y credenciales de autenticacin con mecanismos de cifrado o hashing. Atacantes pueden modificar o robar tales datos protegidos inadecuadamente para conducir robos de identidad, fraudes de tarjeta de crdito u otros crmenes.

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

CMO PUEDO EVITAR ESTO?

1. Considere las amenazas que afecten a sus datos y de las cuales se quiera proteger (por ejemplo, ataques internos, usuarios externos) y asegrese de que todos los datos estn cifrados de manera que se defienda de las amenazas. 2. Asegrese de que las copias de seguridad almacenadas externamente estn cifradas, pero las claves son gestionadas y almacenadas de forma separada. 3. Asegrese de que todas las claves y contraseas son protegidas contra acceso no autorizado.

G O
U R R M I D T A I D C

I S N E F

EJEMPLOS DE ESCENARIOS DE ATAQUE

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

A8 FALLA DE RESTRICCIN DE ACCESO A URL

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

CMO PUEDO EVITAR ESTO?

1. La autenticacin y autorizacin estn basadas en roles, para minimizar el esfuerzo necesario para mantener estas polticas. 2. Las polticas deberan ser configurables, para minimizar cualquier aspecto embebido en la poltica. 3. La implementacin del mecanismo debera negar todo acceso por defecto, requiriendo el establecimiento explcito de permisos a usuarios y roles especficos por cada pgina. 4. Si la pagina forma parte de un proceso de varios pasos, verifique que las condiciones de la misma se encuentren en el estado apropiado para permitir el acceso.

G O
U R R M I D T A I D C

I S N E F

EJEMPLOS DE ESCENARIOS DE ATAQUE

El atacante simplemente navega forzosamente a la URL objetivo. Considere las siguientes URLsl as cuales se supone que requieren autenticacin. Para acceder a la pgina admin_getappInfo se necesitan permisos de administrador. http://ejemplo.com/app/getappInfo http://ejemplo.com/app/admin_getappInfo Si un atacante no autenticado puede acceder a cualquiera de estas pginas entonces se ha permitido acceso no autorizado. Si un usuario autorizado, no administrador, puede acceder a la pgina admin_getappInfo, esto es un fallo, y puede llevar al atacante a otras pginas de administracin que no estn debidamente protegidas.

G O
U R R M I D T A I D C

I S N E F

A9 PROTECCIN INSUFICIENTE EN LA CAPA DE TRANSPORTE

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

CMO PUEDO EVITAR ESTO?

Como mnimo, se debera aplicar lo siguiente: 1. Requerir SSL para todas las pginas sensibles. Las peticiones sin SSL a estas pginas deben ser redirigidas a las pginas con SSL. 2. Establecer el atributo secure en todas las cookies sensibles. 3. Configurar el servidor SSL para que acepte nicamente algoritmos considerados fuertes. 4. Verificar que el certificado sea vlido, no se encuentre expirado o revocado y que se ajuste a todos los dominios utilizados por la aplicacin

G O
U R R M I D T A I D C

I S N E F

EJEMPLOS DE ESCENARIOS DE ATAQUE

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

A10 REDIRECCIONES Y REENVOS NO VALIDOS

Las aplicaciones web frecuentemente redirigen y reenvan a los usuarios hacia otras pginas o sitios web, y utilizan datos no confiables para determinar la pgina de destino. Sin una validacin apropiada, los atacantes pueden redirigir a las vctimas hacia sitios de phishing o malware, o utilizar reenvos para acceder pginas no autorizadas.

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

CMO PUEDO EVITAR ESTO?

Puede realizarse un uso seguro de redirecciones y re-envos de varias maneras: 1. Simplemente, evitando el uso de redirecciones y reenvos. 2. Si se utiliza, no involucrar parmetros manipulables por el usuario para definir el destino. Generalmente, esto puede realizarse.

G O
U R R M I D T A I D C

I S N E F

EJEMPLOS DE ESCENARIOS DE ATAQUE

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.