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.

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.

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.

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.

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.

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.

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.

Esta vulnerabilidad, esta relacionada con la referencia a objetos, la cual, permite al atacante realizar referencia a objetos para los que no tiene autorización.

La primera vez que hablé sobre está vulnerabilidad con alguien me soltó una frase similar a la primera de este post, y por su cara la mía debía de ser un poema (y mira que jugar al poquer no se me da mal). En ese momento yo pensaba: o no tiene ni idea y se ha aprendido la definición del tirón o si que sabe y solo se ha quedado en silencio al ver mi cara. Afortunadamente, tras unos segundos paso la conmoción y resulto ser que, él si que tenía idea, y yo, aunque no sabía el nombre, si sabía a que tipo de fallos se refería. Realmente a lo largo de la vida, y más en esto de la tecnología, esto os va a pasar muchas veces. Habrá cosas que os nombrarán, y gente se sabrá solo las definiciones, pero nunca tengáis miedo a preguntar, porque o descubrirás que si lo sabes, o que ninguno de los dos tiene ni idea, o aprenderás algo nuevo ese día.

Ya me he ido bastante por las ramas, así que volvamos a lo que nos ocupa. ¿Realmente que es esta vulnerabilidad?

Empecemos por describir a que llamamos objetos (en este caso concreto) y que es una referencia directa a ellos. En este caso, consideraremos objetos a los elementos internos de la aplicación, es decir, ficheros, directorios y registros de bases de datos que utiliza nuestra aplicación para almacenar información, y que son referenciados a través de parámetros en url’s o en formularios. Por esto último se dice que se realiza un referencia directa de ellos, porque según la información que contengan estos parámetros, se accederá a uno u otro dato. Como mejor lo veremos será poniendo un ejemplo, así que vamos a ello.

Imaginad que tenemos una aplicación donde hay un enlace que carga la información de un número de cuenta, y el enlace tiene la siguiente forma:

Usuario para el ejemplo: 44444444A

Cuenta para el ejemplo: 21010005130002713345

Url: https://www.bancoejemplo/cuentas.php?cuenta=21010005130002713345

Con esto se cargarían los movimientos de dicha cuenta propiedad del usuario, pero ¿y si meto otro número de cuenta que no sea mía? En principio, si todo se hubiera hecho correctamente, debería mostrar un error al estar introduciendo una cuenta ajena, pero si somos vulnerable a la referencia directa de objetos de forma insegura (vaya nombrecito) nos mostrará los datos de esta cuenta sin ser nuestra.

Otro ejemplo de todo esto, podría ser la descarga de un fichero mal controlada.

Url ejemplo: http://www.ej.org/descarga.php?dir=nomina&file=44444444A.pdf

A partir de está url con una pequeña modificación, podríamos descargar la nómina de cualquiera. Es más, si no se lleva un buen control de servicios en el servidor, podríamos descargar cualquier fichero, un ejemplo sería:

Url ejemplo: http://www.ej.org/descarga.php?dir=../../../etc&file=passwd

Como podéis ver, no estamos haciendo ningún tipo de inyección propiamente dicho, simplemente, estamos modificando el parámetro a buscar, con lo cual filtrar parámetros, como ya vimos se hacía para evitar la inyección no serviría.

Para evitar este tipo de vulnerabilidades, tenemos que intentar realizar referencias a objetos de forma indirecta (sacando los datos de sesión) o acompañar las referencias directas con indirectas.

Poe ejemplo, para el caso del ejemplo uno, en select que utilizaríamos para recuperar los datos de la cuenta, dicho número de cuenta debería de ir también acompañado del dato del cliente que sacaríamos de sesión, de está forma, en caso de no ser el propietario, no nos devolvería sus datos.

Bueno, espero que os sirva para no solo saber la definición de memoria si algún día tenéis que hablar sobre esto. Nos vemos.

Hoy en día casi todas las aplicaciones web tiene un parte pública, accesible por todo el mundo sin necesidad de facilitar ningún tipo de credenciales, y una parte privada, a la cual tendremos acceso mediante la identificación con algún tipo de credenciales. Para la gestión de accesos a esta parte privada, mantenimientos de sesión y demás acciones relacionadas con la autenticación y autentificación, hacen falta diversas herramientas o mecanismos como son: contraseñas, tokens, llaveros, cifrados, …

La tercera vulnerabilidad se relaciona con todo esto. En ella se contemplan la incorrecta implementación de métodos de autenticación o gestión de sesiones que pueden comprometer los elementos utilizados para llevar a cabo las acciones anteriormente mencionadas.

La búsquedas de vulnerabilidades en estos métodos de autenticación o mantenimiento de sesión pueden ser llevadas a cabos por todo tipos de usuarios ya sean externos o internos y con mayores o menores conocimientos, o en disposición de herramientas adecuadas.

Generalmente estos fallos provienen de deficiencias o errores en la implementación de los sistemas, ya que conseguir que estos sean correctos es bastante complicado. La mayoría de desarrolladores y organizaciones intentan realizar sus propias implementaciones, pero en la mayoría de ocasiones, estas no son perfectas.

El fallo puede ir desde leve, hasta muy grave. Pongamos por ejemplo que alguien externo consigue identificarse como un usuario de una red con permisos muy restringidos, en este caso, el perjuicio no sería demasiado a parte de la consulta de algunos datos y poco más. Pero pongamos que el mismo usuarios, con además amplios conocimientos consigue acceder como superusuario a la red y las máquinas de dicha empresa, este podría hacer cualquier cosa que se le ocurriera, trasformando el fallo en muy grave.

Los fallos más normales que podemos encontrar en este ámbito, son:

– No haber almacenado de forma correcta los credenciales de los usuarios en la base de datos. Un ejemplo de esto, sería contraseñas en texto plano o con un cifrado muy débil.

– Otro fallo común es el no poseer una política de contraseñas fuerte, es decir, permitir contraseñas cortas, solo numéricas o solo alfabéticas sin exigir la aparición de mayúsculas, minúsculas o símbolos menos comunes.

– Mal control o gestión de los mecanismo de modificación o recuperación de las contraseñas.

– Visualización de los identificadores de sesión en URL’s o en la página web de forma que otros usuarios puedan visualizarlos fácilmente, por ejemplo, si les enviamos un enlace, y ellos puedan usar este identificador para realizar una suplantación.

– Mala gestión de la finalización de sesiones. Dificultades del usuario para cerrarla correctamente, tiempos prolongados de vida de la sesión tras el cierre de la aplicación. En un sitio público podríamos estar navegando con nuestra sesión, dejar el sitio al haber terminado y que alguien venga posteriormente y nuestra sesión aún existiese.

– Manejo de las contraseñas a través de la red sin cifrar, es decir, en texto plano, haciendo posible su interceptación mediante un sniffer u otro tipo de métodos.

En definitiva, hay que andarse con 100 ojos a la hora de implementar mecanismos de autenticación y de gestión de sesiones. Y tener en cuenta todas las consideraciones anteriormente mencionadas. En el proyecto OWASP, de que estamos hablando estos días, podemos encontrar el proyecto “Application Security Verification Standard“, el cual nos ofrece un conjunto de requisitos de gestión de sesiones y autenticación. En su sección V2, podemos encontrar la “Autenticación” y en la sección V3 “Gestión de sesiones“. Nos vemos.