Nuevamente OWASP toma la delantera en lo referente a Seguridad de aplicaciones web. A continuación les referiré al primer episodio de la nueva serie de tutoriales de Seguridad de Aplicaciones Web, puesto en línea recientemente por Jerry Hoff, lider del proyecto.
La idea de estos tutoriales es ir presentando uno a la vez los más importantes proyectos de OWASP de forma amena e interesante. El próximo capítulo tratará del proyecto del que mucho hemos hablado en este blog OWASP Top 10 List. Estén pendientes.
A medida que vayan saliendo los capítulos se los iré presentando por este medio, pero pueden obtenerlos directamente desde la página del proyecto.
Hasta la próxima!
30 de enero de 2011
23 de enero de 2011
Nuevo tipo de DoS: HTTP POST Denial of Service.
Un nuevo tiepo de ataque de DoS fue presentado en la Black Hat DC Security Conference por dos desarrolladores de Truswave y SpiderLabs. Se trata de lo que podría denominarse Ataque de DoS en la séptima capa del modelo OSI.
Mientras la mayoría de los ataques de DoS actuan en la cuarta capa del modelo OSI, específicamente sobre protocolos de identificación y comunicación, otros recursos de ataque se basan en atacar al protocolo de la aplicación (Octava capa OSI), ya hemos mencionado muchas razones por las cuales una falla o un uso inocente de los recursos pueden generar que un ataque de DoS de este tipo pueda causar efectos impredecibles y aunque la mayoría de los ataques pueden solventarse manejando la forma en que la aplicación accede a los recursos y liberándolos eficientemente, en el caso que vamos a estudiar mitigar el ataque es mucho más difícil.
Sin embargo el ataque del que queremos hablar se coloca una capa más arriba. Se trata específicamente del HTTP POST DoS. La idea principal del ataque es la de solicitar conexiones con el servidor web (HTTP) y una vez realizado el "handshake" enviar datos de solicitud a una velocidad muy baja, de forma que el servidor se vea obligado a mantener la comunicación abierta esperando que se complete la solicitud (request). Si al mismo tiempo se abren cantidades de conexiones simultáneas con el mismo propósito, se llegará a obstruir las comunicaciones con el servidor ya que este en algún momento podría quedar sin recursos de comunicación disponibles.
Tom Brennan director de Trustware, involucrado también con OWASP (Open Web Application Security Project) desarrolló una herramienta de Pen-Testing para ayudar a los programadores a conocer si sus servidores están en capacidad de soportar este tipo de ataque y por supuesto resolver las fallas que pudieran dar cabida al mismo. La herramienta forma parte de uno de los proyectos de OWASP llamado HTTP POST Tool y pueden encontrarla en este enlace.
A diferencia de los ataques generados por métodos que atacan la cuarta capa del modelo OSI, o ataques directos a la aplicación, este tipo de ataques de la séptima capa OSI son más difíciles de limitar ya que no dependen directamente del protocolo de red. Por otro lado son muy fáciles de crear. El siguiente ejemplo de un simple archivo bash es concluyente:
Mientras la mayoría de los ataques de DoS actuan en la cuarta capa del modelo OSI, específicamente sobre protocolos de identificación y comunicación, otros recursos de ataque se basan en atacar al protocolo de la aplicación (Octava capa OSI), ya hemos mencionado muchas razones por las cuales una falla o un uso inocente de los recursos pueden generar que un ataque de DoS de este tipo pueda causar efectos impredecibles y aunque la mayoría de los ataques pueden solventarse manejando la forma en que la aplicación accede a los recursos y liberándolos eficientemente, en el caso que vamos a estudiar mitigar el ataque es mucho más difícil.
Sin embargo el ataque del que queremos hablar se coloca una capa más arriba. Se trata específicamente del HTTP POST DoS. La idea principal del ataque es la de solicitar conexiones con el servidor web (HTTP) y una vez realizado el "handshake" enviar datos de solicitud a una velocidad muy baja, de forma que el servidor se vea obligado a mantener la comunicación abierta esperando que se complete la solicitud (request). Si al mismo tiempo se abren cantidades de conexiones simultáneas con el mismo propósito, se llegará a obstruir las comunicaciones con el servidor ya que este en algún momento podría quedar sin recursos de comunicación disponibles.
Tom Brennan director de Trustware, involucrado también con OWASP (Open Web Application Security Project) desarrolló una herramienta de Pen-Testing para ayudar a los programadores a conocer si sus servidores están en capacidad de soportar este tipo de ataque y por supuesto resolver las fallas que pudieran dar cabida al mismo. La herramienta forma parte de uno de los proyectos de OWASP llamado HTTP POST Tool y pueden encontrarla en este enlace.
A diferencia de los ataques generados por métodos que atacan la cuarta capa del modelo OSI, o ataques directos a la aplicación, este tipo de ataques de la séptima capa OSI son más difíciles de limitar ya que no dependen directamente del protocolo de red. Por otro lado son muy fáciles de crear. El siguiente ejemplo de un simple archivo bash es concluyente:
Mitigar este tipo de ataques es mucho más complejo, ya que no dependen ni del protocolo de comunicación ni de la aplicación. Para cada servidor (IIS, Apache, Nginx...) y versión existen soluciones diferentes que iremos analizando en futuros artículos.
Hasta la próxima...
Limitaciones de los Escaners de Vulnerabilidades para Aplicaciones Web.
Un típico error de las empresas con sus propios equipos de desarrollo o las empresas de desarrollo específicamente, es la tendencia a creer que las aplicaciones web pueden ser convertidas en fortalezas impenetrables con un simple Pen-testing realizado mediante el uso de un programa de escaneo de vulnerabilidades especializado para la web.
Programas como Acunetix, W3af, Netsparker, N-Stalker, Burp y otros, si bien han conseguido convertirse en excelentes herramientas, dependen en mayor o menor grado para desempeñar su trabajo de forma exitosa de los conocimientos de un experto en seguridad web.
Existen muchos de estos programas en formatos diferentes y la intención de estos (al menos la mayoría) es ayudar al experto en seguridad a realizar una serie de pruebas que permitirán conseguir vulnerabilidades para pasar de inmediato a corregirlas. Sin embargo estos programas, tienen muchas limitaciones:
- Debido a la gran cantidad de vulnerabilidades posibles, y a sus cientos de variantes toman horas en realizar un análisis exhaustivo de la aplicación web, consumen una gran cantidad de recursos y someten a la misma a un "stress" indebido para entornos de producción. Aunque la práctica recomienda tener un entornos independientes de desarrollo y control de calidad, en muchos casos estos no existen.
- Cualquiera que los haya utilizado sabe que producen una gran cantidad de "falsos negativos" y "falsos positivos".
- Necesitan de constante actualización, cada día se descubren nuevas formas de penetrar aplicaciones y por tanto nuevas vulnerabilidades afloran.
- Producen un falso sentido de seguridad web.
- Normalmente no explican la razón por la cual se considera una vulnerabilidad como tal, y menos aún dan al programador y su equipo tips para corregirla, por lo que las vulnerabilidades tienden a quedar sin arreglo.
Programas como Acunetix, W3af, Netsparker, N-Stalker, Burp y otros, si bien han conseguido convertirse en excelentes herramientas, dependen en mayor o menor grado para desempeñar su trabajo de forma exitosa de los conocimientos de un experto en seguridad web.
En un estudio realizado por David Shelly, Randy Marchany, Joseph Tront - Closing the Gap: Analyzing the Limitations of Web Application Vulnerability Scanners - que fue presentado en el evento OWASP AppSec DC 2010, utilizando una aplicación en la que se implementaron una serie de vulnerabilidades premeditamente, demostraron que 6 diferentes escaners de vulnerabilidades detectaron entre todos de la serie de vulnerabilidades implantadas los siguientes porcentajes:
Para obtener los falsos negativos simplemente hay que restar el porcentaje al 100%. Lo anterior significa que usted tendría que escanear su aplicación con 6 diferentes herramientas y seguiría teniendo un nivel muy alto de vulnerabilidades latentes, inclusive en algunos casos todas ellas seguirían sin detectarse.
Por otro lado el estudio demostró, que las diferentes herramientas utilizadas arrojaron las siguientes cantidades de falsos positivos:
Entonces: ¿Son acaso como los malos periodistas? ¡Solo dicen una parte de lo que hay e inventan otra parte de lo que dicen!
- 59.7% de las vulnerabilidades de SQL Injection por formulario.
- 6.3% de las vulnerabilidades de SQL Injection por Cookies
- 43.3% de las vulnerabilidades por Reflected XSS
- 11.1% de las vulnerabilidades por Stored XSS
- 0% de las vulnerabilidades por DOM based XSS
- 20% de las vulnerabilidades de Predictable SID en manejo de Sesión.
- 4.4% de variables de Sesión Inseguras por Cookies.
Para obtener los falsos negativos simplemente hay que restar el porcentaje al 100%. Lo anterior significa que usted tendría que escanear su aplicación con 6 diferentes herramientas y seguiría teniendo un nivel muy alto de vulnerabilidades latentes, inclusive en algunos casos todas ellas seguirían sin detectarse.
Por otro lado el estudio demostró, que las diferentes herramientas utilizadas arrojaron las siguientes cantidades de falsos positivos:
- 12% en SQL Injection.
- 13.9% en XSS
Entonces: ¿Son acaso como los malos periodistas? ¡Solo dicen una parte de lo que hay e inventan otra parte de lo que dicen!
Esto no significa que los escaners de vulnerabilidades para aplicaciones web no sean útiles, claro que lo son y mucho, pero lo son solamente en manos de personal especializado que tenga la capacidad de dicernir entre la realidad y lo que reportan. Si el personal que los va a utilizar no tiene bases sólidas de Seguridad de Aplicaciones Web no podrá obtener de ellos una gran parte lo que pueden ofrecer. En definitiva, son las herramientas de pen-testing que nos dan indicios sobre "como abrir la lata" pero hacerlo y obtener su contenido son asuntos más complejos.
20 de enero de 2011
Emulación de librerías Javascript externas mediante pharming u otras técnicas de ataque.
Actualmente los frameworks de Javascript como jQuery, Mootools, YUI, Google Web Toolkit y otros, se han convertido más que en un accesorio en una necesidad. Son impresionantes los plugins pre-elaborados y las mejoras que podemos aplicar en las interfaces de usuarios con estas librerías, y un desarrollo web que no las contemple puede cargar a cuestas un serio "handicap" en relación con sus competidores.
No me opongo para nada al uso de las mismas, si bien como todo desarrollo pueden tener problemas de seguridad, estos son evaluados por profesionales expertos y en caso de descubrirse una vulnerabilidad sabemos que automáticamente estarían corrigiéndola. Sin embargo a lo que me opongo es a la moda muy peligrosa de incluir estas librerías directamente desde la fuente, o lo que es lo mismo sin utilizar una copia local, llamando a la librería correspondiente desde la fuente directa. Esto se suele hacer para poder tener a mano siempre la versión más actualizada, lo cual en principio no es una mala idea.
El problema con esta idea es puede ser más grave el daño que el beneficio que aporta, ya que bastaría con infectar el archivo "hosts" del equipo de la víctima mediante "pharming local" con una dirección que sustituya la dirección en la que se puede obtener el código de la librería de javascript usada en nuestra aplicación y así la victima estaría descargando una copia con código adicional infectado.
Se podría obtener mucha información con solo colocar al final del código de una de estas librerías funciones adicionales que capturen la información delicada y la hagan llegar al atacante mediante AJAX usando inclusive funciones de la librería que se está emulando. Todo esto sin que el usuario detecte absolutamente nada extraño. Para mostrar mi punto solo pregúntense si el usuaruio sabe o no si una página determinada está siendo evaluada por Google Analytics. Este es un caso legal, pero solo necesitan extrapolar la idea.
Lo peligroso de este ataque es que no existe forma práctica por parte de la víctima de detectarlo, el estaría accediendo a las páginas de sus aplicaciones preferidas sin que se emulara ningún componente (excepto las librerías que para el son transparentes).
Si bien existe una política de seguridad en los navegadores para el control de llamada a funciones y componentes del DOM desde sitios cruzados, es importante recordar que en este caso puede no ser muy útil, ya que lo que esta política evita es el llamar a una función o componentes del DOM desde otro página de otro dominio o sub-dominio, la librería de conexión está en capacidad de enviar cualquier cosa si es llamada desde la misma página.
Si esto último no fuera cierto siempre se podría hacer una llamada con parámetros desde un "tag" de imagen, una llamada javascript o un simple enlace. En HTML5 inclusive se pueden utilizar "websockets" para enviar los datos. Y aunque lográramos por políticas de seguridad que simplemente fuera imposible enviar datos, siempre podríamos generar una redirección no deseada a otra página.
Por tanto la recomendación a seguir para evitar este problema es muy sencilla:
No cargar librerías Javascript, plugins u otro tipo de scripts, desde sitios externos independientes en páginas donde se trate con información delicada. En estos casos es siempre preferible tener copia de dicha librería o plugin en nuestro servidor y cargarlos desde allí.
Hasta la próxima!
No me opongo para nada al uso de las mismas, si bien como todo desarrollo pueden tener problemas de seguridad, estos son evaluados por profesionales expertos y en caso de descubrirse una vulnerabilidad sabemos que automáticamente estarían corrigiéndola. Sin embargo a lo que me opongo es a la moda muy peligrosa de incluir estas librerías directamente desde la fuente, o lo que es lo mismo sin utilizar una copia local, llamando a la librería correspondiente desde la fuente directa. Esto se suele hacer para poder tener a mano siempre la versión más actualizada, lo cual en principio no es una mala idea.
El problema con esta idea es puede ser más grave el daño que el beneficio que aporta, ya que bastaría con infectar el archivo "hosts" del equipo de la víctima mediante "pharming local" con una dirección que sustituya la dirección en la que se puede obtener el código de la librería de javascript usada en nuestra aplicación y así la victima estaría descargando una copia con código adicional infectado.
Se podría obtener mucha información con solo colocar al final del código de una de estas librerías funciones adicionales que capturen la información delicada y la hagan llegar al atacante mediante AJAX usando inclusive funciones de la librería que se está emulando. Todo esto sin que el usuario detecte absolutamente nada extraño. Para mostrar mi punto solo pregúntense si el usuaruio sabe o no si una página determinada está siendo evaluada por Google Analytics. Este es un caso legal, pero solo necesitan extrapolar la idea.
Lo peligroso de este ataque es que no existe forma práctica por parte de la víctima de detectarlo, el estaría accediendo a las páginas de sus aplicaciones preferidas sin que se emulara ningún componente (excepto las librerías que para el son transparentes).Si bien existe una política de seguridad en los navegadores para el control de llamada a funciones y componentes del DOM desde sitios cruzados, es importante recordar que en este caso puede no ser muy útil, ya que lo que esta política evita es el llamar a una función o componentes del DOM desde otro página de otro dominio o sub-dominio, la librería de conexión está en capacidad de enviar cualquier cosa si es llamada desde la misma página.
Si esto último no fuera cierto siempre se podría hacer una llamada con parámetros desde un "tag" de imagen, una llamada javascript o un simple enlace. En HTML5 inclusive se pueden utilizar "websockets" para enviar los datos. Y aunque lográramos por políticas de seguridad que simplemente fuera imposible enviar datos, siempre podríamos generar una redirección no deseada a otra página.
Por tanto la recomendación a seguir para evitar este problema es muy sencilla:
No cargar librerías Javascript, plugins u otro tipo de scripts, desde sitios externos independientes en páginas donde se trate con información delicada. En estos casos es siempre preferible tener copia de dicha librería o plugin en nuestro servidor y cargarlos desde allí.
Hasta la próxima!
18 de enero de 2011
Skipfish: Escanner de Seguridad Web de Google
Si bien realmente Skipfish promete ser una herramienta interesante como Nikto o Nessus, uno de los principales problemas que podemos tener es que para empezar tenemos que compilarla. En el sitio no se ofrecen versiones en binario para los diferentes sistemas operativos. La ventaja de compilarla es que este proceso puede ser desarrollado para Linux, MacOS, FreeBSD y Windows (Cygwin).
Luego de varios intentos logré compilarla bajo Ubuntu 10.04 Lucid Lynx, luego de navegar un buen rato por la web ya que necesitaba tener instaladas algunas librerías de las que no se menciona absolutamente nada en el "readme" que provee el paquete de instalación.
Skipfish al igual que Nikto, no tiene una interfaz gráfica amigable y todo el proceso de escaneo debe ser desarrollado desde la ventana de terminal. Sin embargo, una de las virtudes que manifiestamente hacen a esta utilidad de seguridad de Google un muy interesante prospecto es su velocidad, que le permite ejecutar hasta 2000 solicitudes por segundo sobre servidores con capacidad de respuesta, lo que se redujo a unas 500 solicitudes sobre el tipo de conexión que yo tengo ( aprox.1.5 Mbits/sec).
Quizás lo impresionante son los diccionarios que utiliza para escanear todo tipo de posible directorio o archivo ubicado en el servidor, ya que al parecer estos han sido creados utilizando los conocimientos de escaneo de Googlebot (la araña de rastreo de Google) por lo que al combinar los nombres con cada uno de los tipos de archivos, hay una amplia posibilidad de ubicar archivos no indexados en los servidores a escanear.
El desarrollo según sus creadores ofrece las siguientes características:
- Alta velocidad: Al ser desarrollada completamente en C deja una huella menor de uso de CPU, lo cual luego de haberla probado en condiciones convencionales nos parece cierto, si bien los escaneos fueron más largos de los de otras aplicaciones debido a lo extenso de los diccionarios.
- Fácil de usar: La verdad nos gustaría saber exactamente que entienden algunos programadores al usar el término "fácil". Su interfaz como ya dijimos es completamente en consola y hay que compilar la aplicación para poder usarla. Si bien una vez que se han instalado las librerías necesarias solo hay que llamar al comando "make", sería interesante que se explicara en alguna parte acerca de la necesidad de las mismas. Además la interfaz de comando tiene tal cantidad de diferentes opciones con las que bien se podría redactar un libro de cierta extensión.
- Usa una lógica de seguridad de primera: No tenemos mucho que objetar a este punto, ya que el simple hecho de que los diccionarios provengan de Googlebot es ya un avance radical. Sin embargo obtuvimos una cantidad de falsos positivos superior a lo esperado, pero entendemos que la aplicación está aún en proceso de desarrollo y como todo lo que hace Google terminará corrigiendo sus hasta ahora pocas debilidades.
Hasta la próxima!
17 de enero de 2011
URLs amigables a los buscadores - SEO friendly URLs - Convertir títulos a URL
Es un pequeño dolor de cabeza convertir en tiempo real los URLs de una aplicación al formato que actualmente se utiliza para lograr una mayor visibilidad en Google.
Este proceso tiene sus ventajas y desventajas: La ventaja principal en lo referente a seguridad es que esconden los parámetros y los nombres de las variables utilizadas en la aplicación, sin embargo en cuanto a desventajas, al hacer los URLs más largos, el usuario se ve forzado a utilizar recortadores de URL como goo.gl y otros para usar las direcciones en sus aplicaciones sociales, y de esta forma tendremos muchos menos presencia de enlaces directos que fortalezcan nuestro Page Rank en Google. Una va por otra.
Sin embargo son muy útiles también para que el usuario reconozca el contenido de una página desde su enlace, y además repiten el título en el URL lo que aumenta la posibilidad de que nuestras páginas aparezcan indexadas mejor.
Pero cuando uno va a tratar de aplicar este truco de SEO, se encuentra con que los scripts para hacerlo están todos adaptados para páginas con títulos en inglés, por lo cual no toman en cuenta los acentos y los caracteres como la "ñ" y la "ü" (u con dieresis).
Por tanto decidí realizar mi propia función en C# que convierte una cadena de texto de un título en otra cadena de texto utilizable por un URL y amigable con los métodos SEO.
A continuación una función adaptada al español que se basa en convertir caracteres acentuados, con tilde o con diéresis, en sus correspondientes sin agregado (es decir á se convierte en a y ñ en n). También convierte todos los caracteres en blanco en guiones luego de eliminar cualquiera de estos delante o detrás de la cadena. Cualquier otro caracter que no se encuentre en la lista o no sea letra, número o guión, es eliminado.
Espero les sea útil:
Hasta la próxima.
Este proceso tiene sus ventajas y desventajas: La ventaja principal en lo referente a seguridad es que esconden los parámetros y los nombres de las variables utilizadas en la aplicación, sin embargo en cuanto a desventajas, al hacer los URLs más largos, el usuario se ve forzado a utilizar recortadores de URL como goo.gl y otros para usar las direcciones en sus aplicaciones sociales, y de esta forma tendremos muchos menos presencia de enlaces directos que fortalezcan nuestro Page Rank en Google. Una va por otra.
Sin embargo son muy útiles también para que el usuario reconozca el contenido de una página desde su enlace, y además repiten el título en el URL lo que aumenta la posibilidad de que nuestras páginas aparezcan indexadas mejor.
Pero cuando uno va a tratar de aplicar este truco de SEO, se encuentra con que los scripts para hacerlo están todos adaptados para páginas con títulos en inglés, por lo cual no toman en cuenta los acentos y los caracteres como la "ñ" y la "ü" (u con dieresis).
Por tanto decidí realizar mi propia función en C# que convierte una cadena de texto de un título en otra cadena de texto utilizable por un URL y amigable con los métodos SEO.
A continuación una función adaptada al español que se basa en convertir caracteres acentuados, con tilde o con diéresis, en sus correspondientes sin agregado (es decir á se convierte en a y ñ en n). También convierte todos los caracteres en blanco en guiones luego de eliminar cualquiera de estos delante o detrás de la cadena. Cualquier otro caracter que no se encuentre en la lista o no sea letra, número o guión, es eliminado.
Espero les sea útil:
/// <summary> /// Convierte cadenas convencionales de títulos /// en cadenas SEO URL amigables. /// </summary> /// <param name="strTitle">La cadena a convertir.</param> /// <returns> El string en formato SEO amigable</returns> public static string titleToSeoURL(string strTitle) { char[] allChars; //cadena de caracteres a ser reemplazados string sCharsToReplace = "áéíóúüñç_"; //cadena de caracteres para reemplazar, en el mismo orden string sCharsForReplace = "aeiouunz-"; string seoURL = string.Empty; int charPos = 0; // decodifica cualquier entidad HTML antes de empezar. strTitle = Server.HtmlDecode(strTitle); strTitle = strTitle.ToLower(); strTitle = strTitle.Trim(); // reemplaza todos los caracteres transparentes. strTitle = Regex.Replace(strTitle, @"\s+", "-"); // El siguiente bucle reemplaza todos los caracteres // encontrados en sCharsToReplace por los de sCharsForReplace allChars = strTitle.ToCharArray(); for (int i = 0; i < allChars.Length; i++) { charPos = sCharsToReplace.IndexOf(allChars[i]); if (charPos != -1) { allChars[i] = sCharsForReplace[charPos]; } seoURL += allChars[i]; } // Remueve cualquier caracter no reemplazado que no // esté entre a y z, que no sea número o que no sea un guión (-)
seoURL = new Regex("[^a-z0-9-]").Replace(seoURL, ""); // remueve cualquier guión solitario al final o principio // de la cadena resultante seoURL = seoURL.Trim('-'); // Limita el resultado a 80 caracteres.
if(seoURL.Lenght > 80) seoURL = seoURL.Substring(0, 80); return seoURL; }
Hasta la próxima.
15 de enero de 2011
¡El phishing se renueva! Phishing móvil
Sin embargo la principal preocupación de los expertos en seguridad en los próximos meses es que este conocido flagelo pase de forma imperceptible al ámbito de la web móvil, específicamente a atacar a aquellos usuarios que usan smart phones y otro tipo de componentes como iPod, iPad, Playbooks y muchos otros dispositivos para los cuales sus usuarios asumen que la navegación en Internet es ya un servicio obligatorio y no una utilidad adicional.
Hay muchos puntos a tomar en cuenta:
- Los vectores de ataque son mucho más variados que el simple SPAM utilizado convencionalmente por los ataque de phishing dirigidos a PCs y computadores de escritorio o laptops.Ahora el atacante no solo dispone del SPAM sino de la mensajeria SMS, MMS, VoIP y hasta Twitter.
- En segundo lugar, el usuario de estos dispositivos está acostumbrándose de muy mal modo a los "short URLs" o direcciones recortadas por servicios de recorte de URL, los cuales han crecido de forma incontrolada, y no existirá control visual de las direcciones a ser visitadas antes de solicitarlas.
- Una gran parte de la plataforma de usuario de Internet a través de los dispositivos móviles, no tiene acceso permanente a otra forma de navegar en la Red, por lo cual si bien puede haber escuchado del phishing, nunca se han topado cara a cara con un ataque de este tipo.
- Los problemas ya conocidos de las redes sociales en lo referente a seguridad personal solo agravarán la situación ante un enemigo que se perfecciona cada vez más con el tiempo.
- La intercepción de los ataques por parte delos navegadores de los dispositivos móviles no será tan eficiente como lo es la intercepción de los navegadores tradicionales, ya que se ha comprobado que en algunos casos no es tan buena y en otros aún no existe. Tampoco son eficientes o no existen los formatos para reportar sitios sospechosos.
- Los sitios desarrollados para plataforma móvil en su mayoría aún no contienen sistemas de prevención y/o control, en muy escasos sitios se aprecia una política al respecto.
Hasta la próxima...
11 de enero de 2011
Desactiva la función de autocompletar en los campos sensibles de los formularios.
Si bien la función de auto-completar los campos de formularios es una gran idea y está presente en todos los navegadores modernos, debemos tener mucho cuidado con recordar desactivarla en nuestras aplicaciones cuando los campos son sensibles, debido a que pudieran representar un riesgo de seguridad para el usuario que utiliza equipos compartidos o que permite que otras personas accedan a su equipo.
No hay que tener cuidado con los campos tipo <input type="password"> ya que lógicamente estos no utilizan esta función, pero si dejamos al descubierto el nombre o el login del usuario le dejamos el trabajo medio hecho al posible atacante. También hay que tener cuidado con los campos en que solicitamos repuestas específicas que solo el usuario debe saber y sobre todo en los campos en que el usuario debe introducir números de tarjetas.
Desactivar la función de autocompletar puede hacerse de forma genérica o detallada por campo. Solo necesitamos incluir el atributo - autocomplete="off" - en el tag <form> si queremos que se desactive la función en todo el formulario, o incluirlo en cada uno de los campos en los cuales queremos evitar que se muestren datos sensibles.
Es un paso muy sencillo que puede evitarle al usuario dolores de cabeza, y sin embargo aún me sorprendo al ver cantidad de formularios de acceso que no desactivan esa función.
Hasta la próxima...
8 de enero de 2011
OWASP ESAPI - Enterprise Security API
Uno de los proyectos más interesantes de OWASP en referencia a la generación de código web seguro, es precisamente el que se denomina ESAPI o Enterprise Security API. Se trata de una librería de código que meneja objetos y métodos que permiten validaciones y controles eficientes para evitar XSS, CSRF y muchos otros tipos de ataques web.
OWASP ESAPI tiene puertos para la mayoría de entornos y lenguajes de programación web como por ejemplo ASP.NET, Java, PHP, ColdFusion, Javascript, Ruby y Python entre otros.
Entre algunas de las empresas y organizaciones que han empezado a adoptar ESAPI como plataforma de seguridad para aplicaciones web están American Express, Banco Mundial, US Navy y muchas más.
La librería incluye extensiones y utilidades que permiten homogeneizar el tratamiento de los procesos de seguridad para aplicaciones web, y documentación variada en formato "chm". Sin embargo una serie de artículos muy interesantes de John Melton, denominados "The OWASP Top Ten and ESAPI", nos podrán guiar de forma eficiente acerca de los diez tipos de vulnerabilidades más frecuentes según OWASP y cómo defenderse de estas usando ESAPI. Los ejemplos están en Java pero las clases, métodos y propiedades son básicamente los mismos para todos los lenguajes.
Espero que les sea de ayuda para homologar los procedimientos de seguridad y desarrollar alicaciones web mucho más seguras.
Hasta la próxima...
OWASP ESAPI tiene puertos para la mayoría de entornos y lenguajes de programación web como por ejemplo ASP.NET, Java, PHP, ColdFusion, Javascript, Ruby y Python entre otros.
Entre algunas de las empresas y organizaciones que han empezado a adoptar ESAPI como plataforma de seguridad para aplicaciones web están American Express, Banco Mundial, US Navy y muchas más.
La librería incluye extensiones y utilidades que permiten homogeneizar el tratamiento de los procesos de seguridad para aplicaciones web, y documentación variada en formato "chm". Sin embargo una serie de artículos muy interesantes de John Melton, denominados "The OWASP Top Ten and ESAPI", nos podrán guiar de forma eficiente acerca de los diez tipos de vulnerabilidades más frecuentes según OWASP y cómo defenderse de estas usando ESAPI. Los ejemplos están en Java pero las clases, métodos y propiedades son básicamente los mismos para todos los lenguajes.
Espero que les sea de ayuda para homologar los procedimientos de seguridad y desarrollar alicaciones web mucho más seguras.
Hasta la próxima...
5 de enero de 2011
¿Qué hacer en caso de un ataque de phishing a nuestros usuarios?
Mi experiencia de años en este tema me ha demostrado que la mayoría de las empresas y entidades que reciben ataques de phishing, no reaccionan con la celeridad suficiente cuando sufren estos ataques. Además la mayoría solo toma medidas reactivas, pocas medidas preventivas y prácticamente ninguna medida de detección temprana.
Sí, ya sé que algunos estarán pensando que un ataque de phishing no se puede anticipar, pero eso en el 85% de los casos es falso, aunque dejaré para otra oportunidad ese tema. Lo que voy a explicar en este artículo son las medidas reactivas a tomar ante un ataque de phishing en curso por parte de la administración de la aplicación afectada. La prevención y la detección temprana aunque son la mejor práctica no forman parte de este artículo.
Es impresionante ver en las empresas y entidades la poca preparación ante estos temas. En ocasiones me he visto rodeado de personal de seguridad, vicepresidentes, programadores y hasta policía al rededor de sendas mesas de reunión (más de 12 personas en una ocasión), solo para enterarme que mis servicios fueron solicitados pasadas más de 72 horas desde que se detectó el ataque, sin que ni siquiera se hubiera denunciado aún el sitio ofensivo mediante un procedimiento extremadamente básico que cualquier usuario pude hacer en menos de tres pasos desde su navegador.
Como primer punto, hay que entender que el atacante no necesariamente es un programador experimentado. Fíjense que ni siquiera le llamo con el término "hacker" ya que desarrollar un phishing es más un trabajo de "script-kiddies" o "lammers" (términos despectivos con los que los hackers llaman a los que atacan aplicaciones copiando código o exploits sin tener gran noción del proceso).
Otro detalle importante a tomar en cuenta, es que un ataque de phishing se realiza en casi la totalidad de los casos desde la plataforma de un servidor que ha sido vulnerado, para colocar las páginas falsas allí. El atacante tratará de que sus scripts y páginas falsas no sean detectadas, por lo cual dejará la menor huella posible (footprint), razón por la que sus páginas falsas llaman directamente las imágenes desde el servidor de la aplicación real, así como posiblemente a otros recursos.
Un tercer punto a tomar en cuenta es que las primeras horas de un ataque de phishing son las más peligrosas y en las que el ataque es más efectivo. En las primeras 24 horas el 60% del daño ya ha sido hecho. Por tanto las medidas a que expondré no deben aplicarse de forma secuencial sino dentro de lo posible de forma simultánea por varias personas ya que algunas necesitan seguimiento.
Pasos a seguir ante un ataque de phishing:
Antes de tomar cualquier paso obtenga las direcciones de los servidores en los que se encuentran alojadas las pseudo-fachadas o páginas falsas. Aclaro este punto porque el ataque pudiera bien ser distribuido entre varios servidores tratando de aumentar el tiempo de vida y dándole más trabajo para denunciar más sitios, esperandoasí que se pasen algunos por alto. ¿Cómo hacerlo? Simple, usted debe tener al menos una dirección reportada, si no aún no sabría del ataque. Pues bien, fíjese qué imágenes de la páginas falsas son llamadas directamente desde su sitio y diríjase a archivo de registros de su servidor web para consultar por dichas imágenes. Una vez allí obtenga las direcciones de las que son solicitadas o "referers". Recuerde hacer seguimiento permanente de este punto ya que pudieran aparecer nuevos sitios falsos a medida que usted bloquea otros. El ataque podría ser distribuido o por etapas, para darle atacante la capacidad de ir "quemando" los sitios a medida que usted los descubre y denuncia.
Simultáneamente usted deberá renombrar todas las imágenes utilizadas por los sitios falsos, para que estos ya no logren mostrarlas y el usuario vea como resultado al hacer clic en los enlaces forjados un sitio falso sin imágenes o al menos sin algunas de ellas (el logotipo y las imágenes que identifican la página son las más importantes).
Denuncie las direcciones falsas usandon las funciones de los navegadores Internet Explorer, Google Chrome y Opera . Si usa Firefox será igual que usar Chrome ya que acceden ambos a la misma base de datos de sitios ofensivos. Cada sitio debe ser denunciado en los tres navegadores ya que cada uno de ellos usa bases de datos diferentes. Si no tiene instalado Opera, puede hacer la denuncia directamente en https://www.phishtank.com/. Si tiene suficiente personal no olvide denunciar también las páginas en el APWG (Anti-Phishing Working Group) http://www.antiphishing.org/ .
Obtenga la información necesaria de los proveedores de hosting en los cuales se encuentran los sitios falsos mediante Reverse DNS Lookup de las direcciones asociadas al ataque, y ubique la cuenta de correo destinada a denuncias de abuso. Casi siempre tiene el formato "abuse@proveeedor.com". Denuncie el abuso con pruebas y direcciones a cada una de estas cuentas. Si logra ubicar números de teléfono con los cuales contactar a los proveedores no dude en usarlos. Este tipo de detalles se podrá obtener también mediante consultas WHOIS o nsLookup. Recuerde que este tipo de ataque es penado seriamente por la ley en muchos paises y el hecho de que un proveedor de hosting o ISP se niegue a ayudarlo puede ser causa de una denuncia por complicidad. También pueden ofrecerle direcciones en las que se hayan formularios para denuncias. Llénelos a la brevedad posible.
Llene el receptáculo de datos del atacante con información falsa. Hágalo llenando los datos solicitados como si fuera un usuario incauto, manualmente desde varios equipos mientras prepara un script para hacerlo de forma automatizada. Trate que la información que introduce en los formularios sea creíble. Esta técnica podrá ocultar a los usuarios incautos entre montones de datos falsos por un tiempo prudencial. Además con ella usted está comprando tiempo para que sus usuarios puedan cambiar de password si sospechan que han sido engañados. Por otro lado si ejecuta el script gran cantidad de veces pudiera lograr que alguno de los servicios del sitio falso dejen de funcionar. Algo parecido a una negación de servicio defensiva.
Todas estas técnicas deben ser implantadas por un tiempo prudencial de 24 horas sin parar, hasta que las denuncias en las listas de phishing se hagan efectivas y ya los navegadores protejan al usuario con la típica pantalla roja de seguridad.
Sin embargo si el ataque es distribuido, con un número muy alto de sitios falsos usted necesitará aplicar técnicas de defensa mucho más potentes y quizás no tan éticas. Generar un DoS mediante Loic o Hping puede ser una solución rápida, pero deberá estar muy seguro de a quien ataca y preferiblemente hacerlo desde una red externa a la entidad esperando un contraataque.
Recuerde que la idea es proteger a sus usuarios antes que nada, el resto son asuntos que puede dejar para otros departamentos cuando sus usuarios estén seguros.
Lógicamente, habrá podido apreciar que usted deberá en más de un caso tomar decisiones y saltar protocolos como control de calidad y otros. Su empresa debe tener un protocolo de seguridad para estos casos para que usted no se encuentre con las manos atadas por los procedimientos convencionales a seguir. Si todas las medidas anteriores suman más de 48 horas no habrán servido de mucho.
Por último, recuerde que antes de pasar por todo esto, usted puede evitar de forma casi definitiva los ataques de phishing mediante técnicas de prevención anti-phishing, sistemas de acceso seguros comprobados, factores de autenticación externos y sistemas de alerta temprana que pueden detectar a un atacante mientras aún se está instalando el phishing en el servidor vulnerado. En fin, toda una serie de técnicas de prevención y alerta que le ahorrarán muchas molestias a usted y a sus usuarios y mucho dinero a su entidad.
Hasta la próxima...
Sí, ya sé que algunos estarán pensando que un ataque de phishing no se puede anticipar, pero eso en el 85% de los casos es falso, aunque dejaré para otra oportunidad ese tema. Lo que voy a explicar en este artículo son las medidas reactivas a tomar ante un ataque de phishing en curso por parte de la administración de la aplicación afectada. La prevención y la detección temprana aunque son la mejor práctica no forman parte de este artículo.
Es impresionante ver en las empresas y entidades la poca preparación ante estos temas. En ocasiones me he visto rodeado de personal de seguridad, vicepresidentes, programadores y hasta policía al rededor de sendas mesas de reunión (más de 12 personas en una ocasión), solo para enterarme que mis servicios fueron solicitados pasadas más de 72 horas desde que se detectó el ataque, sin que ni siquiera se hubiera denunciado aún el sitio ofensivo mediante un procedimiento extremadamente básico que cualquier usuario pude hacer en menos de tres pasos desde su navegador.
Como primer punto, hay que entender que el atacante no necesariamente es un programador experimentado. Fíjense que ni siquiera le llamo con el término "hacker" ya que desarrollar un phishing es más un trabajo de "script-kiddies" o "lammers" (términos despectivos con los que los hackers llaman a los que atacan aplicaciones copiando código o exploits sin tener gran noción del proceso).
Otro detalle importante a tomar en cuenta, es que un ataque de phishing se realiza en casi la totalidad de los casos desde la plataforma de un servidor que ha sido vulnerado, para colocar las páginas falsas allí. El atacante tratará de que sus scripts y páginas falsas no sean detectadas, por lo cual dejará la menor huella posible (footprint), razón por la que sus páginas falsas llaman directamente las imágenes desde el servidor de la aplicación real, así como posiblemente a otros recursos.
Un tercer punto a tomar en cuenta es que las primeras horas de un ataque de phishing son las más peligrosas y en las que el ataque es más efectivo. En las primeras 24 horas el 60% del daño ya ha sido hecho. Por tanto las medidas a que expondré no deben aplicarse de forma secuencial sino dentro de lo posible de forma simultánea por varias personas ya que algunas necesitan seguimiento.
Pasos a seguir ante un ataque de phishing:
Antes de tomar cualquier paso obtenga las direcciones de los servidores en los que se encuentran alojadas las pseudo-fachadas o páginas falsas. Aclaro este punto porque el ataque pudiera bien ser distribuido entre varios servidores tratando de aumentar el tiempo de vida y dándole más trabajo para denunciar más sitios, esperandoasí que se pasen algunos por alto. ¿Cómo hacerlo? Simple, usted debe tener al menos una dirección reportada, si no aún no sabría del ataque. Pues bien, fíjese qué imágenes de la páginas falsas son llamadas directamente desde su sitio y diríjase a archivo de registros de su servidor web para consultar por dichas imágenes. Una vez allí obtenga las direcciones de las que son solicitadas o "referers". Recuerde hacer seguimiento permanente de este punto ya que pudieran aparecer nuevos sitios falsos a medida que usted bloquea otros. El ataque podría ser distribuido o por etapas, para darle atacante la capacidad de ir "quemando" los sitios a medida que usted los descubre y denuncia.
Simultáneamente usted deberá renombrar todas las imágenes utilizadas por los sitios falsos, para que estos ya no logren mostrarlas y el usuario vea como resultado al hacer clic en los enlaces forjados un sitio falso sin imágenes o al menos sin algunas de ellas (el logotipo y las imágenes que identifican la página son las más importantes).
Denuncie las direcciones falsas usandon las funciones de los navegadores Internet Explorer, Google Chrome y Opera . Si usa Firefox será igual que usar Chrome ya que acceden ambos a la misma base de datos de sitios ofensivos. Cada sitio debe ser denunciado en los tres navegadores ya que cada uno de ellos usa bases de datos diferentes. Si no tiene instalado Opera, puede hacer la denuncia directamente en https://www.phishtank.com/. Si tiene suficiente personal no olvide denunciar también las páginas en el APWG (Anti-Phishing Working Group) http://www.antiphishing.org/ .
Obtenga la información necesaria de los proveedores de hosting en los cuales se encuentran los sitios falsos mediante Reverse DNS Lookup de las direcciones asociadas al ataque, y ubique la cuenta de correo destinada a denuncias de abuso. Casi siempre tiene el formato "abuse@proveeedor.com". Denuncie el abuso con pruebas y direcciones a cada una de estas cuentas. Si logra ubicar números de teléfono con los cuales contactar a los proveedores no dude en usarlos. Este tipo de detalles se podrá obtener también mediante consultas WHOIS o nsLookup. Recuerde que este tipo de ataque es penado seriamente por la ley en muchos paises y el hecho de que un proveedor de hosting o ISP se niegue a ayudarlo puede ser causa de una denuncia por complicidad. También pueden ofrecerle direcciones en las que se hayan formularios para denuncias. Llénelos a la brevedad posible.
Llene el receptáculo de datos del atacante con información falsa. Hágalo llenando los datos solicitados como si fuera un usuario incauto, manualmente desde varios equipos mientras prepara un script para hacerlo de forma automatizada. Trate que la información que introduce en los formularios sea creíble. Esta técnica podrá ocultar a los usuarios incautos entre montones de datos falsos por un tiempo prudencial. Además con ella usted está comprando tiempo para que sus usuarios puedan cambiar de password si sospechan que han sido engañados. Por otro lado si ejecuta el script gran cantidad de veces pudiera lograr que alguno de los servicios del sitio falso dejen de funcionar. Algo parecido a una negación de servicio defensiva.
Todas estas técnicas deben ser implantadas por un tiempo prudencial de 24 horas sin parar, hasta que las denuncias en las listas de phishing se hagan efectivas y ya los navegadores protejan al usuario con la típica pantalla roja de seguridad.
Sin embargo si el ataque es distribuido, con un número muy alto de sitios falsos usted necesitará aplicar técnicas de defensa mucho más potentes y quizás no tan éticas. Generar un DoS mediante Loic o Hping puede ser una solución rápida, pero deberá estar muy seguro de a quien ataca y preferiblemente hacerlo desde una red externa a la entidad esperando un contraataque.
Recuerde que la idea es proteger a sus usuarios antes que nada, el resto son asuntos que puede dejar para otros departamentos cuando sus usuarios estén seguros.
Lógicamente, habrá podido apreciar que usted deberá en más de un caso tomar decisiones y saltar protocolos como control de calidad y otros. Su empresa debe tener un protocolo de seguridad para estos casos para que usted no se encuentre con las manos atadas por los procedimientos convencionales a seguir. Si todas las medidas anteriores suman más de 48 horas no habrán servido de mucho.
Por último, recuerde que antes de pasar por todo esto, usted puede evitar de forma casi definitiva los ataques de phishing mediante técnicas de prevención anti-phishing, sistemas de acceso seguros comprobados, factores de autenticación externos y sistemas de alerta temprana que pueden detectar a un atacante mientras aún se está instalando el phishing en el servidor vulnerado. En fin, toda una serie de técnicas de prevención y alerta que le ahorrarán muchas molestias a usted y a sus usuarios y mucho dinero a su entidad.
Hasta la próxima...
3 de enero de 2011
¿Que es un Honeypot? Tipos y usos.
Los tipos de honeypots son variados así como lo son las formas en que un intruso accede a la información de un sistema atacado. Un simple honeypot puede ser una dirección de e-mail utilizada únicamente con el fin de captar las listas de spam. En este caso se conoce como "honeytoken" y el término representa cualquier unidad de datos con la cual se permite acceso o uso de un sistema, pero que al ser utilizada levanta una alerta. Otro ejemplo puede ser un par identificador/clave de acceso de un usuario que no existe pero que en caso de aparecer logueado en el sistema su presencia levante las alarmas de rastreo.
Existen lógicamente muchos tipos de servidores honeypots, que simplemente aparentan ser servidores descuidados y vulnerables, en los que se estudia el comportamiento de los atacantes o de una vez son utilizados para contraataque. Específicamente por ejemplo, los atacantes gustan mucho de los servidores proxy para efectos de esconder sus identidades en los ataques, por lo cual existen una serie de de servidores proxy que en vez de esconder la identidad de los que los utilizan, la divulgan a las autoridades encargadas de la protección de sistemas ¿Interesante no?
Existen muchos tipos de honeypots, también están los honeypots clients o "honeyclients", que son sistemas encargados de navegar la web cual arañas de buscadores pero con la intención de detectar código malicioso en las páginas que visitan y de esta forma erradicar el mal antes de que afecte a los usuarios.
Cuando dos o más honeypot se encuentran en una red suelen conformar una honeynet. Los honeypots y honeynets son usados básicamente en las redes para efectos de detección de intrusos. Típicamente las honeynets son usadas cuando un honeypot solo no es suficiente debido a lo amplio de la red.
Aunque son una herramienta muy eficiente pueden ser evitados por los atacantes mediante herramientas de detección y técnicas de evasión, pero ese es otro tema que trataremos a futuro.
Hasta la próxima!
¿Cómo se calcula un riesgo en base al modelo DREAD?
Es importante cuando se habla de amenazas en aplicaciones web y otras, establecer un sistema de cálculo estándar que permita a los interesados (programadores, técnicos de seguridad y otros) medir el riesgo que dicha amenaza representa, de manera de priorizar las posibles respuestas ante cada tipo de ataque así como el ajuste del código o la plataforma una vez descubierta la amenaza.
DREAD es un esquema de clasificación para cuantificar, comparar y dar prioridad a la cantidad de riesgo que presenta una amenaza específica. El acrónimo DREAD se forma a partir de la primera letra del nombre en inglés de cada una de las categorías evaluadas.
El algoritmo de cálculo de riesgo DREAD que se muestra a continuación, se fija en base a un promedio de las cinco categorías contempladas en el modelo de cálculo:
Riesgo_DREAD = (Daño Potencial + Reproductibilidad + Explotabilidad + Usuarios Afectados + Detectabilidad) / 5
El cálculo de cada una de las categorías de riesgo siempre produce un número entre 0 y 10; cuanto mayor sea el número, más grave es el riesgo.
Éstos son algunos ejemplos de cómo cuantificar las categorías de riesgo:
Daño potencial:
Si una amenaza fuese explotada, ¿Cuánto daño causaría?
0 = Nada
5 = Datos de los usuarios individuales comprometidos o afectados.
10 = Destrucción de datos del sistema comleto
Reproductibilidad:
¿Es fácil de reproducir la amenaza a explotar?
0 = Muy difícil o imposible, incluso para los administradores de la aplicación.
5 = Uno o dos pasos necesarios, puede ser necesario un usuario autorizado.
10 = Sólo un navegador web y la barra de direcciones es suficiente, sin necesidad de autenticación.
Explotabilidad:
Lo que se necesita para aprovechar esta amenaza.
0 = Conocimientos avanzados de programación y de redes, con herramientas de ataque personalizadas o avanzadas.
5 = Malware existente en el Internet, o un exploit fácil de realizar con las herramientas disponibles en la web.
10 = Sólo un navegador web.
Usuarios a los que afecta:
¿Cuántos usuarios se verán afectados?
0 = Ninguno
5 = Algunos usuarios, pero no todos.
10 = Todos los usuarios.
En esta categoría se aplica matemáticamente un punto por cada 10% de posibles usuarios afectados.
Detectabilidad:
¿Es fácil descubrir esta amenaza?
0 = Muy difícil o imposible, requiere el código fuente o acceso administrativo.
5 = ¿Se puede averiguar de adivinar o mediante el control de trazas de red?
9 = Detalles de fallas de este tipo son ya de dominio público y puede ser fácilmente descubierto usando un motor de búsqueda.
Información más detallada sobre DREAD:
Hasta la próxima...
DREAD es un esquema de clasificación para cuantificar, comparar y dar prioridad a la cantidad de riesgo que presenta una amenaza específica. El acrónimo DREAD se forma a partir de la primera letra del nombre en inglés de cada una de las categorías evaluadas.
El algoritmo de cálculo de riesgo DREAD que se muestra a continuación, se fija en base a un promedio de las cinco categorías contempladas en el modelo de cálculo:
Riesgo_DREAD = (Daño Potencial + Reproductibilidad + Explotabilidad + Usuarios Afectados + Detectabilidad) / 5
El cálculo de cada una de las categorías de riesgo siempre produce un número entre 0 y 10; cuanto mayor sea el número, más grave es el riesgo.
Éstos son algunos ejemplos de cómo cuantificar las categorías de riesgo:
Daño potencial:
Si una amenaza fuese explotada, ¿Cuánto daño causaría?
0 = Nada
5 = Datos de los usuarios individuales comprometidos o afectados.
10 = Destrucción de datos del sistema comleto
Reproductibilidad:
¿Es fácil de reproducir la amenaza a explotar?
0 = Muy difícil o imposible, incluso para los administradores de la aplicación.
5 = Uno o dos pasos necesarios, puede ser necesario un usuario autorizado.
10 = Sólo un navegador web y la barra de direcciones es suficiente, sin necesidad de autenticación.
Explotabilidad:
Lo que se necesita para aprovechar esta amenaza.
0 = Conocimientos avanzados de programación y de redes, con herramientas de ataque personalizadas o avanzadas.
5 = Malware existente en el Internet, o un exploit fácil de realizar con las herramientas disponibles en la web.
10 = Sólo un navegador web.
Usuarios a los que afecta:
¿Cuántos usuarios se verán afectados?
0 = Ninguno
5 = Algunos usuarios, pero no todos.
10 = Todos los usuarios.
En esta categoría se aplica matemáticamente un punto por cada 10% de posibles usuarios afectados.
Detectabilidad:
¿Es fácil descubrir esta amenaza?
0 = Muy difícil o imposible, requiere el código fuente o acceso administrativo.
5 = ¿Se puede averiguar de adivinar o mediante el control de trazas de red?
9 = Detalles de fallas de este tipo son ya de dominio público y puede ser fácilmente descubierto usando un motor de búsqueda.
Información más detallada sobre DREAD:
- http://msdn.microsoft.com/en-us/library/aa302419.aspx#c03618429_011
- http://blogs.msdn.com/b/david_leblanc/archive/2007/08/13/dreadful.aspx
- http://www.owasp.org/index.php/Threat_Risk_Modeling
Hasta la próxima...
Suscribirse a:
Entradas (Atom)
Suscribirse a
Entradas
Todos los comentarios