Anda di halaman 1dari 4

Flujos de datos Lmites de confianza La mejor manera de hacer esto es obtener la documentacin de arquitectura y diseo de la aplicacin.

Busque diagramas de componentes UML. Los diagramas de componentes de alto nivel son generalmente todo lo que se requiere para entender como y porque la informacin fluye a distintos lugares. Informacin que cruza un lmite de confianza (como desde el Internet al cdigo OWASP Guide 2.0 43 de la interfaz o desde la lgica de negocio al servidor de base de datos), necesita ser analizado cuidadosamente, mientras que los flujos dentro del mismo nivel de confianza no necesitan tanto escrutinio. Descomponer la aplicacin Una vez que la arquitectura de la aplicacin es entendida, la aplicacin necesita ser descompuesta, esto significa que las caractersticas y mdulos que tienen un impacto de seguridad necesitan ser descompuestas. Por ejemplo, cuando se investiga el mdulo de autenticacin, es necesario entender como los datos entran al mdulo de autenticacin, como el mdulo valida y procesa la informacin, a donde fluyen los datos, si la informacin es guardada, y que decisiones son hechas por el mdulo. Documentar las amenazas conocidas Es imposible escribir amenazas desconocidas, y es poco probable para muchos sistemas

personalizados que un nuevo malware sea creado para hacer frente a nuevas vulnerabilidades. En cambio, concntrese en los riesgos que son conocidos, que pueden ser fcilmente demostrados utilizando herramientas o el seguimiento de errores. Cuando documente una amenaza, Microsoft sugiere dos enfoques diferentes. Uno es un grfico de amenaza y el otro es simplemente una lista estructurada. Tpicamente, un grfico de amenaza imparte mucha ms informacin en un periodo de tiempo ms corto para el lector pero lleva mayor tiempo para construirse, y la lista estructurada es mucho ms fcil de escribir pero lleva ms tiempo para el impacto de las amenazas hacerse obvias. Un atacante podra leer los mensajes de otros usuarios El usuario tal vez no haya terminado sesin en una computadora compartida Validacin de datos pueden fallar, permitiendo Inyeccin SQL Autorizacin puede fallar, permitiendo acceso no autorizado

Cach del navegador puede contener parte del mensaje Implementar Validacin de datos Implementar revisiones de autorizacin Implementar cabeceras HTTP anti-cach Si el riesgo es alto, usar SSL Figura 1: Grfico del rbol de Amenaza Error! No se le ha dado un nombre al marcador. 44 1. Un atacante podra leer los mensajes de otros usuarios El usuario tal vez no haya terminado sesin en una computadora compartida 2. Validacin de datos puede permitir inyeccin SQL 3. Implementar validacin de datos 4. Autorizacin puede fallar, permitiendo acceso no autorizado 5. Implementar revisiones de autorizacin 6. Cach del navegador puede contener parte del mensaje 7. Implementar cabeceras HTTP anti-cach 8. Si el riesgo es alto, usar SSL

Las amenazas son atacantes motivados, ellos generalmente quieren algo de su aplicacin o burlar controles. Para entender que amenazas son aplicables, utilice los objetivos de seguridad para entender quien podra atacar la aplicacin: Descubrimiento accidental: Usuarios autorizados pueden toparse con un error en la lgica de su aplicacin utilizando simplemente un navegador Malware automatizado (buscando vulnerabilidades conocidas pero con un poco de malicia e inteligencia) Atacante Curioso (como investigadores de seguridad o usuarios que notaron algo mal en su aplicacin y prueban ms all) Script kiddie: criminales computacionales atacando o desfigurando aplicaciones por respeto o motivos polticos utilizando tcnicas descritas aqu o en la Gua de Pruebas de OWASP para comprometer su aplicacin Atacantes motivados (como personal disgustado o un atacante pagado) Crimen organizado (generalmente para aplicaciones de alto riesgo, como comercio electrnico o bancario Es vital entender el nivel del atacante contra el que se esta defendiendo. Un atacante informado que entiende sus procesos es mucho ms peligroso que un script kiddie, por ejemplo.