RSS

Archivo de la categoría: OWASP

OWASP Top Ten – 2013 RC1

El post de hoy va a ser cortito ya que el motivo es, simplemente, comentaros que estos días se ha publicado la RC1 del proyecto Top Ten de OWASP. Imagino que sabréis de que proyecto os estoy hablando, ya que aquí en el blog lo hemos tratado en profundidad.

El enlace para acceder al pdf es el siguiente: OWASP Top Ten

Disfrutad su lectura y si tenéis algo que sugerirles, siempre podéis escribirles. Nos vemos.

 
Deja un comentario

Publicado por en 18 febrero, 2013 en OWASP

 

OWASP Top Ten: A10 – Redirecciones y reenvíos no validados

Por fin hemos llegado a la última de las vulnerabilidades del Top Ten de OWASP. La vulnerabilidad que nos ocupa hoy es muy simple. Se trata de la redirección del usuario de nuestra aplicación a una página no segura donde por ejemplo, se puede haber implementado un ataque de phishing o algo similar.

¿Por qué se producen estas redirecciones? Bien, no es difícil encontrar una aplicación que en determinadas ocasiones, por necesidad de la propia aplicación se realice una redirección legítima a través de un valor obtenido por un parámetro.

Un ejemplo sería algo como:

http://www.example.org/redirigir.php?url=example2.org

Esta página recogería el parámetro y haría una redirección a URL recibida. Pero, ¿qué pasa si un atacante ha conseguido modificar ese parámetro? Pues que nuestra aplicación estaría redirigiendo a una URL ilegítima con las posibles consecuencias de ello. Por ejemplo:

http://www.example.org/redirigir.php?url=phishing.org

Si nuestro usuario hiciera click en el enlace con la redirección alterada, acabaría sufriendo un ataque de phishing.

Aún así este tipo de ataques son fáciles de evitar, basta con realizar las validaciones oportunas a la hora de hacer redirecciones. Toda redirección realizada  a partir de un parámetro tendría que ser validada previamente comprobando que dicha redirección se va a realizar a un destino válido y confiable. Evidentemente, lo más fácil es hacer esto en tiempo de desarrollo, pero en caso de tener que solventarlo una vez desplegado el proyecto o aplicación, bastaría con hacer una revisión de código para encontrar y comprobar la validación de todas las redirecciones que permitan introducir URLs completas.

Hasta aquí esta serie de artículos sobre OWASP. Espero que os hayan servido si no entendíais alguna de las vulnerabilidades de su Top Ten, o al menos, espero que os haya servido para que os intereséis por el proyecto, ya que es bastante interesante y abarca muchos y diferentes aspectos y perspectivas de la seguridad. Nos vemos.

 
Deja un comentario

Publicado por en 15 septiembre, 2011 en OWASP

 

OWASP Top Ten: A9 – Protección insuficiente de la capa de trasporte

Para hablar de la vulnerabilidad que nos concierne hoy, primero, me temo que voy a tener que hablar del modelo OSI. Supongo que todo aquel que tenga algún tipo de estudio relacionado con informática, redes, telecomunicaciones, etc… sabrá que es, pero por si acaso, como la memoria es muy mala, al menos la mía, vamos a darle un repasito muy pequeño y rápido, y a dejar aunque sea el típico enlace a la Wikipedia.

El modelo OSI, es un modelo de interconexión de sistemas abiertos, o lo que es lo mismo en un lenguaje menos técnico, es la descripción de una propuesta de sistema de conexión entre dispositivos para que estos puedan interactuar entre si a través de una red.

Por resumir un poco, el modelo OSI describe varias capas para realizar la comunicación, el cometido de cada una de estas diferentes capas y como podemos trabajar con ellas para finalmente obtener una comunicación correcta y entendible por parte de otros dispositivos.

Las capas que describe el modelo son siete:

–       Capa física.

–       Capa de enlace de datos.

–       Capa de red.

–       Capa de transporte.

–       Capa de sesión.

–       Capa de presentación.

–       Capa de aplicación.

Cada una de estas capas tiene una tarea especifica encomendad y es la suma de todas ellas lo que posibilita el éxito de la comunicación. Está claro que a raíz de este modelo han surgido otros con más o menos capas y con funciones ligeramente diferentes, pero este, por decirlo de alguna manera, es el básico. La tarea específica de cada una de estas capas no es tema de este post, así que si queréis leer sobre ello porque no lo conocéis o necesitáis refrescar la memoria (como es mi caso) os envío a la Wikipedia, que aunque tiene un artículo cortito, está bastante bien explicado.

Pues bien, ¿y para qué esta introducción? La vulnerabilidad que nos atañe hoy, es una vulnerabilidad de nuestras aplicaciones sobre la capa número cuatro, la de trasporte. Que nadie piense ni por un momento que el modelo está mal definido o especificado. La vulnerabilidad más bien consiste en la falta de protección de los datos que circulan por esta capa que son susceptibles de ser interceptados.

Par la capa de trasporte, si me habéis hecho caso y habéis consultado la Wikipedia o teníais conocimientos sobre el modelo OSI ya, sabréis que discurren los datos que se intercambian entre unos sistemas y otros. Estos datos pueden ir en texto plano o cifrados, por ejemplo con SSL. En caso de ir cifrados no habría ningún problema, ya que, en caso de que alguien los intercepte, no podría leerlos, pero el problema viene cuando estos datos viajan en texto plano. En este momento, un atacante que esté capturando nuestro tráfico podrá tener acceso a múltiple datos sensibles, datos bancarios, tokens de sesión, rutas del sistemas, datos de usuarios, etc…

Lamentablemente,  no todas nuestras aplicaciones llevan su tráfico cifrado y este tipo de ataques, sobre todo en redes internas, no es difícil de llevar a cabo, ya que en estos entornos, por considerarlos de confianza o más seguros se dejan de lado este tipo de precauciones.

Algunas nociones básicas para evitar este tipo de vulnerabilidades serían:

–       Que toda página sensible requiera acceso SSL, en caso de intentar una petición sin SSL, forzarla.

–       Activar el atributo “secure” de las cookies para que el navegador no las mande en texto plano.

–       Por supuesto, si estamos usando SSL, preocuparnos de que el cifrado aplicado sea lo suficientemente fuerte.

–       Verificar la corrección de los certificados utilizados. Fechas, no revocación y dominios que abarca.

–       Por supuesto, conexiones cifradas entre fron-end y back.-end, aunque no sea SSL.

Como despistes habituales, nombraremos por ejemplo:

–       Cifrar con SSL solo la autenticación, dejando los datos de la aplicación y los cookies de sesiones que se trasmitirán durante la navegación sin cifrar.

–       Aplicar SSL con un algoritmo muy flojo o “fácil” de crackear.

–       Abrir un elemento no seguro en una página externa de forma segura. Pongamos el ejemplo de un PDF que abrimos a modo de pop-up en una nueva ventana. Al abrirlo en la nueva esta mostrará una advertencia al usuario desde el navegador, y en ocasiones esto puede hacer que se muestre el identificador de sesión.

–       Por supuesto, la estrella muchas veces, que la cookie navegue como texto plano para que cualquiera la pueda leer.

Bueno, hasta aquí el artículo de hoy. Nos vemos.

[BONUS]

En el artículo se ha hablado de interceptar el tráfico de la aplicación, esto se realiza mediante una herramienta conocida como sniffer. Dicha herramienta permite capturar el tráfico que circula por la red para su posterior análisis. Con ellas se pueden descubrir por ejemplo contraseñas en texto plano navegando por la red. Si queréis más info, aquí tenéis un enlace.

 
Deja un comentario

Publicado por en 5 septiembre, 2011 en OWASP

 

OWASP Top Ten: A8 – Falla de restricción de acceso a URL

Sobre esta vulnerabilidad hay poco que decir, es bastante fácil de intentar explotar, y los conocimientos que hacen falta para ello, son casi nulos. ¿Quién no ha probado alguna vez poner en el navegador una URL de una página a la que no tiene acceso por permisos a ver si podía acceder directamente? Por ejemplo, imaginémonos que estamos navegando por el sitio www.example.es/user_private.php, pero sabemos que para el administrador es www.example.es/admin_private.php, seguro que alguno ha probado poner la dirección del administrador a ver si se puede acceder.

Pues más o menos, la vulnerabilidad que nos abarca hoy consiste en eso, en acceder a URL’s que en teoría nos deberían estar vetadas.

Realmente este fallo, más que de programación, aunque en ocasiones también lo es,  es un fallo de administración de la autorización y la autenticación. Me explico, todos sabemos que para una página o portal web existen dos ámbitos principalmente, el público y el privado, pero en muchas ocasiones, dentro del ámbito privado, existen diferentes niveles de acceso según el usuario que esta navegando en ese momento. Existen zonas a las que solo tendría que tener acceso un administrador del portal, zonas a las que solo tendría que tener acceso determinado grupo de trabajadores pero no otro, etc… Lamentablemente, en muchas ocasiones, estos controles de acceso están mal gestionados, y aunque un usuario básico no tenga ningún enlace a una zona restringida o lo tenga deshabilitado, si escribe directamente la dirección en la barra del navegador podrá acceder sin problemas.

El peligro de este tipo de ataque es que datos que deberían solo mostrarse a determinados usuarios quedan expuestos a personas que no deberían tener acceso a ellos, de aquí que la importancia del efecto del ataque vaya de desde baja, en caso de no tener ningún dato confidencial o de suma importancia, hasta muy alta, en caso de tener datos de carácter personal, privado o de suma importancia para un negocio.

Como ya se ha comentado antes, este fallo deriva de una incorrecta gestión de la autorización y la autenticación. Esto es, el acceso a todas las páginas, debería estar restringido por defecto y habilitarlo solo para aquellos usuarios que de verdad lo requieran. Esta tarea se hace mucho más fácil si, por ejemplo, creamos roles con los distintos usuarios: gestores, administradores, usuarios, contabilidad, …

También he comentado, que este no era de programación, y aunque es cierto, es también cierto que algunas veces si lo es. Para que todo el proceso de gestión de usuarios y roles funcione, todas las páginas de un portal o aplicación web deben llevar el control adecuado para realizar esta gestión, y en ocasiones, debido al gran número de páginas manejadas, a las prisas, o a un simple despiste, estos controles no se insertan en la página, haciendo que, a pesar de una buena gestión, nuestro sitio sea vulnerable.

Así que de todo los dicho, yo me quedaría con tres cosas básicas a modo de resumen:

La primera, es que es necesaria una buena gestión del acceso, si está basada en roles, mejor que mejor.

La segunda, es que nadie debe tener acceso más que a lo estrictamente necesario para realizar sus funciones. Así que, cerrarlo todo y solo abrid lo necesario, aunque trabajosa, puede ser una buena política.

Y la tercera, es que a pesar de las prisas y del exceso de trabajo, más vale hacer y revisar bien las cosas, porque por un pequeño despiste, se puede ir al traste cualquier excelente trabajo. Esta última, es aplicable a casi cualquier cosa que os enfrentéis.

Por último, me alegro de volver con vosotros y de escribir en el blog después de estos meses, y como siempre, espero comentarios y dudas. Nos vemos.

 
Deja un comentario

Publicado por en 9 julio, 2011 en OWASP

 

OWASP Top Ten: A7 – Almacenamiento criptográfico inseguro

Uno de los riesgos descritos por OWASP es el de almacenamiento de datos sensibles. Obviamente, supongo que todos conocemos de que tipo de riesgo estamos hablando, seguro que lo hemos oído más de una vez. Lo que yo no imaginaba, es que hoy en día pudiera estar entre los diez primeros, eso, si que me ha sorprendido. Quizás hace unos años cuando había menos conciencia sobre seguridad y la importancia de preservar de forma adecuada los datos, esto fuera más común. Pero hoy en día , yo casi lo veía como un error aislado. De todas formas, ya me estoy yendo por las ramas. Así que vamos a explicar, en primer lugar, que es este riesgo, y luego divagaremos sobre él.

Todos sabemos que los sistemas computacionales, guardan hoy en día infinidad de datos. Algunos de ellos irrelevantes, pero otros de vital importancia o de gran sensibilidad. Entre estos últimos podrían estar credenciales de acceso, números de tarjetas de crédito, datos médicos, etc… Toda esta información sensible, aunque inicialmente no esté al alcance de cualquier persona, por unas u otras circunstancias, pueden caer en manos no adecuadas. Por ejemplo, tener una intrusión en nuestros sistemas, que uno de nuestros empleados pierda un portátil, que se extravíe un disco duro con una copia de seguridad de nuestro sistema o cualquier otro tipo de acontecimiento o acción que provoque que está información sensible caiga en manos no autorizadas. Y, ¿qué pasa en esta situación? Todos nuestros datos sensibles estarían al alcance de cualquiera. Esto no deberíamos permitirlo.

¿Como podemos evitarlo? La respuesta es cifrando esta información sensible para que, cuando caiga en manos no autorizadas, se totalmente inútil y no se pueda sacar partido de ella. Para esto se inventaron los métodos de cifrado, a través de los cuales podemos evitar que la información sensible sea leída aunque caiga en malas manos. Sobre criptografía ya hemos hablado un poco en este blog en post anteriores (y espero que ampliemos en un futuro) y no es el tema de este post, así que simplemente diremos que es una forma de hacer ilegibles unos datos para todo aquel que no este en posesión de una clave, es decir, que esté autorizado.

A la pregunta de que deberíamos cifrar, la respuesta más fácil de recordar y de poner en práctica, es: Toda aquella información que no le darías nunca a un desconocido.

Por ejemplo, contraseñas y claves de cualquier tipo. Estas deberían estar almacenadas de forma cifrada en una BBDD.

Copias de seguridad, y más generalmente, cualquier información que vaya a ser almacenada durante largos periodos de tiempo, debería ser cifrada también.

Transmitir las claves de cifrado solo a los mínimos e imprescindibles usuarios. Solo deberían tener acceso a las claves aquellos usuarios que de verdad las necesiten. En este punto, y sobre todo en ambientes corporativos, probablemente debamos llegar a acuerdos entre usabilidad y seguridad.

A día de hoy existen una gran cantidad de algoritmos excelentes de cifrado, no intentemos reinventar la rueda creando el nuestro propio. Hay algoritmo que poseen un gran reconocimiento y se ha demostrado matemáticamente su fiabilidad y seguridad. Con una clave suficientemente fuerte y un buen algoritmo de cifrado, podremos dormir un poco más tranquilos.

Y por último, nunca guardéis en el mismo sitio los datos cifrados y las contraseñas de descifrado, a ver si después de tanto trabajo, vamos a meter la pata en una tontería así. O, ¿No os suena el típico post-it con la contraseña pegado en el monitor? Pues imaginaos un servidor de copias de seguridad con una hoja al lado con las contraseñas de cifrado. – Era por comodidad – dijo alguien cuando todos los datos fueron comprometidos.

Bueno, espero vuestros comentarios, y sobre todo anécdotas acerca de todo esto. Nos vemos.

 

 
Deja un comentario

Publicado por en 4 marzo, 2011 en OWASP

 

OWASP Top Ten: A6 – Defectuosa configuración de seguridad

Desde mi punto de vista, nunca había incluido esto como fallo. Para mi más bien pertenece al grupos de cosas a tener en cuenta siempre que se desarrollo y se despliega cualquier aplicación. Pero, pensándolo un poco más fríamente, aunque no es un ataque en particular, es algo que posibilita que se produzca un ataque.

En este apartado se incluiría todo aquello que ser relaciona con el despliegue de una aplicación y su entorno. Es decir, permisos, configuraciones por defecto, actualizaciones librerías, sistema operativo, servidores de aplicaciones, puertos, servicios, cuentas de usuarios, manejo de errores, y un largo etcétera de cosas relacionadas con la configuración a la hora de poner a disponibilidad del público, sea este cual sea, una aplicación.

En este punto cobran especial importancia los administradores, los planes de despliegue de aplicaciones, los procesos de instalación y configuración, la planificación y ejecución de actualizaciones, la arquitectura escogida, y una revisión periódica de auditorias y comprobaciones del sistema.

Este es uno de los fallos de la lista que más cosas englobaría, pero a su vez, es uno de los que menos claros tengo como tratar a la hora de plasmarlo en este post, ya que podría estar listando posibles errores horas y horas y aún así no abarcarlos todos. Así que, dado que el tipo de error no necesita de mucha explicación, simplemente voy a nombrar unos cuantos pasos en los siempre deberemos hacer hincapié. Evidentemente, ni son todos, ni son los más importantes, y por supuesto, cada aplicación tiene sus particularidades, pero quizás si que sea un buen punto por el que empezar.

Lo primero a tener en cuenta, será la arquitectura que vayamos a utilizar. Está claro que hay muchas arquitecturas, pero siempre, a la hora de elegir y diseñar la nuestra deberemos de intentarla hacer lo más robusta posible, estableciendo una buena separación entre los distintos componentes y su seguridad.

Otra cosa a tener en cuenta sería, los permisos tanto de la aplicación como del servidor de aplicaciones donde esta se despliega. Estos deberían ser lo menos holgados posibles. Deberemos controlar, permisos de accedo, de lectura y escritura en sistemas de fichero, de acceso y modificación a la BBDD y, por supuesto, permisos de utilización de la aplicación y sus partes. Quizás en este apartado también debamos incluir los puertos de acceso al servidor y los servicios que este tiene levantados y esperando solicitudes. En este caso, solo debería estar disponible aquello que sea imprescindible.

Otra de las cosas que tendremos que tendremos que planificar, será la metodología que vamos a emplear para el tratamiento de actualizaciones, ya sea para nuestra propia aplicación, como para los sistemas y plataformas donde está desplegada.

Otro punto a tener en cuenta siempre, es el tratamiento de errores que hará nuestra aplicación. Deberemos manejar todos lo errores que puedan salir y no volcar nunca información de los sistemas en estos errores y permitir que dicha información llegue al usuarios, ya que podría utilizar esta información para preparar un ataque. Es decir, por supuesto que hay que informar al usuarios cuando se produce un error, pero esta información habrá sido tratada y procesada por nosotros previamente, y al usuario final se le mostrará correcta y convenientemente formateada.

Por último, yo recomendaría la auditoría periódica de las aplicaciones desplegadas y los entornos donde se han desplegado, para confirmar que al menos, no lo estamos haciendo del todos mal.

Pero quizás, el mejor consejo, sería tener dos dedos de frente, pensar las cosas bien pensadas y no hacerlas a la ligera, y sobre todo, a la hora de diseñas e implementar un sistema, no solo ponerse en el pellejo del “desarrollador”, si no también en el del “usuario” y en el del “atacante”.

Si creéis que existe algún paso más que deberíamos añadir, animaros a ponerlo, y podemos debatirlo. Nos vemos.

 
Deja un comentario

Publicado por en 7 febrero, 2011 en OWASP

 

OWASP Top Ten: A5 – CSRF

Las siglas de este ataque se corresponden con “Cross Site Request Forgery“, lo que más o menos en español vendría a significar algo así como “Falsificación de Peticiones en Sitios Cruzados”. Otra cosa más que añadir a la lista de las cuales no sabía el nombre, pero si lo que era, como últimamente viene siendo habitual.

Está vulnerabilidad permite realizar peticiones legítimas una aplicación vulnerable desde otra no legítima, utilizando los auténticos credenciales del usuario. No os preocupéis si no habéis entendido nada con la definición, porque con un ejemplo estoy seguro de que lo veremos claramente.

Pongamos como situación un cliente que está logado en la página de su banco (sitio A) en una de las pestañas de su navegador, y en otra de ellas accede al sitio que contiene el código malicioso (sitio B).

En la página A, la del banco, la solicitud de una transferencia por parte de un cliente se realiza de la siguiente manera:

http://www.bank.org/transfer.php?amount=2000&dest=0002714345

La página B envía su contenido, más una imagen con el siguiente código:

<img src=” http://www.bank.org/transfer.php?amount=2000&dest=0123456789&#8243; />

Cuando en navegador de la victima intentase cargar este enlace, realizaría una petición al banco transfiriendo 2000€ a la cuenta destino. al estar el cliente logado en el banco, esta petición se realizaría con los credenciales correctos y se llevaría a cabo sin ningún problema. Como supongo que habréis deducido ya, para que este ataque funcione, es necesario que la víctima esté autenticada en el sitio A.

Para evitar este tipo de ataques, se emplean testigos aleatorios que son enviados a los servidores junto con las peticiones realizadas de forma que estos validen que el valor enviado coincide con el valor asignado a ese formulario. Mediante este mecanismo, aunque se acceda al sitio malicioso, y se realice la petición con el código malicioso, la ejecución de la petición fallaría.

Como siempre espero que os sea de utilidad. Si tenéis alguna duda o comentario, animaros a dejarlo. Nos vemos.

 

 
Deja un comentario

Publicado por en 29 enero, 2011 en OWASP