Inicio de sesión con Facebook

Seguridad del inicio de sesión

Las funciones del inicio de sesión con Facebook, como los identificadores de acceso y los permisos, hacen que tanto personas como aplicaciones puedan usarlo de forma segura, aunque las aplicaciones deben implementar algunos pasos de seguridad.

Vídeo

Jonathan Gross y Brent Dorman hablan en la F8 de 2015 sobre cómo aumentar la seguridad de la integración del inicio de sesión con Facebook.

Lista de comprobación de seguridad

En la siguiente lista se mencionan los requisitos mínimos que todas las aplicaciones que utilizan el inicio de sesión con Facebook deben implementar. Probablemente, algunas funciones serán exclusivas de tu aplicación, por lo que deberás tener siempre en cuenta las formas de conseguir que sea lo más segura posible. Las aplicaciones que no son seguras pierden la confianza de la audiencia y dejan de usarse.

Nunca incluyas la clave secreta de la aplicación en un código de cliente o descompilable.

Firma todas las llamadas de servidor a servidor a la API Graph con la clave secreta de la aplicación.

En los clientes, utiliza identificadores de corta duración exclusivos.

No presupongas que la propia aplicación ha generado los identificadores de acceso que utiliza.

Utiliza el parámetro de estado al usar el cuadro de diálogo de inicio de sesión.

Utiliza nuestros SDK oficiales siempre que sea posible.

Reduce las zonas expuestas de tu aplicación mediante el bloqueo de la configuración de las aplicaciones de Facebook.

Utiliza HTTPS.

Clave secreta de la aplicación

La clave secreta de la aplicación se utiliza en algunos procesos de inicio de sesión para generar identificadores de acceso. Su objetivo es garantizar que solo personas de confianza utilicen la aplicación. La clave secreta permite crear fácilmente un identificador de acceso a la aplicación que realice las solicitudes a la API en nombre de cualquier usuario, por lo que resulta extremadamente importante que nunca se vea comprometida.

Por lo tanto, la clave secreta de la aplicación o un identificador de acceso a la aplicación nunca se deben incluir en ningún código.

Para ofrecer la mejor seguridad posible, recomendamos utilizar los identificadores de acceso a la aplicación únicamente desde los servidores de tu aplicación. En el caso de las aplicaciones nativas, recomendamos que la aplicación se comunique con tu propio servidor y que sea este el que realice las solicitudes de la API a Facebook, mediante el identificador de acceso a la aplicación. Por este motivo, si el tipo de aplicación establecido en las opciones de configuración avanzadas del panel de aplicaciones es Native/Desktop, suponemos que la aplicación nativa contiene en el código binario la clave secreta o un identificador de acceso a la aplicación, y no permitimos realizar llamadas firmadas con dichos identificadores. La API se comportará como si no se hubiera proporcionado ningún identificador de acceso.

Llamadas seguras desde el servidor con appsecret_proof

Puedes reducir la exposición al malware y al spam si exiges que las llamadas de servidor a servidor a la API de Facebook estén firmadas con el parámetro appsecret_proof. La prueba de la clave secreta de la aplicación es un hash SHA256 de tu identificador de acceso que, a su vez, utiliza dicha clave secreta como clave. Puedes encontrar la clave secreta de la aplicación en el panel de aplicaciones, en Configuración > Información básica.

Generar la prueba

En el siguiente ejemplo de código se muestra el aspecto de la llamada en PHP:

$appsecret_proof= hash_hmac('sha256', $access_token.'|'.time(), $app_secret);

Algunos sistemas operativos y lenguajes de programación devolverán una marca de tiempo flotante. Asegúrate de convertirla a un valor entero antes de calcular la prueba de la clave secreta de la aplicación. Algunos lenguajes de programación crean el hash como un objeto digest. Asegúrate de expresar el hash como un objeto hexadecimal.

Añadir la prueba

A cada llamada que realices, debes añadir el resultado como un parámetro appsecret_proof con el valor de appsecret_time establecido en la marca de tiempo utilizada al aplicar el algoritmo hash a la clave secreta de la aplicación:

curl \
  -F 'access_token=ACCESS-TOKEN' \
  -F 'appsecret_proof=APP-SECRET-PROOF' \
  -F 'appsecret_time=APP-SECRET-TIME' \
  -F 'batch=[{"method":"GET", "relative_url":"me"},{"method":"GET", "relative_url":"me/accounts"}]' \
  https://graph.facebook.com

Las pruebas de la clave secreta de la aplicación con marca de tiempo se considerarán caducadas una vez transcurridos cinco minutos, por lo que te recomendamos que generes una nueva prueba insertada al realizar cada llamada a la API Graph.

Requerir la prueba

En la sección Configuración > Opciones avanzadas del panel de aplicaciones, en Seguridad, activa Clave secreta de la aplicación obligatoria. Cuando esta opción esté activada, solo permitiremos las llamadas a la API que incluyan el parámetro appsecret_proof.

Llamadas seguras desde el cliente con identificadores de corta duración y proceso de código

En algunas configuraciones, las aplicaciones reutilizan un identificador de larga duración en distintos clientes. No lo hagas. Es preferible utilizar identificadores de corta duración generados con el proceso de código, como se describe en la documentación sobre identificadores de acceso.

Secuestro de identificadores

Para comprender cómo sucede, imagina lo siguiente: quieres realizar llamadas a la API con una aplicación de iOS nativa, pero, en lugar de hacerlo directamente, la aplicación se comunica con un servidor de su propiedad y le pasa un identificador generado mediante el SDK de iOS. El servidor utilizará dicho identificador para realizar llamadas a la API.

El extremo que el servidor utiliza para recibir el identificador podría verse comprometido, y otros podrían pasarle identificadores de acceso para aplicaciones completamente distintas. Evidentemente, este proceso es poco seguro, pero existe un modo para evitarlo: nunca hay que suponer que los identificadores de acceso son de la aplicación que los utiliza. Es preciso comprobarlo mediante extremos de depuración.

Comprobación periódica de la validez del identificador de acceso

Si no utilizas los SDK de Facebook, comprueba periódicamente si el identificador de acceso es válido. Aunque los identificadores de acceso tienen una caducidad programada, se pueden usar para adelantar la caducidad por motivos de seguridad. Si no utilizas los SDK de Facebook en la aplicación, es extremadamente importante que implementes manualmente comprobaciones frecuentes de la validez del identificador (al menos a diario) para garantizar que la aplicación no depende de ningún identificador que ha caducado antes por motivos de seguridad.

Parámetro de estado

Si usas el cuadro de diálogo de inicio de sesión con Facebook en tu sitio web, el parámetro state consiste en una cadena única que protege la aplicación frente a ataques de falsificación de solicitud entre sitios.

Activación del modo estricto

Con el modo estricto, se protegen las aplicaciones, ya que evita que agentes malintencionados secuestren tu redireccionamiento. Es necesario activar el modo estricto para todas las aplicaciones.

Antes de activar el modo estricto en el panel de aplicaciones, realiza las siguientes acciones en la configuración del inicio de sesión con Facebook para comprobar que tu tráfico de redireccionamiento actual todavía funciona:

  • Para las aplicaciones con URI de redireccionamiento dinámico, utiliza el parámetro “state” a fin de devolver la información dinámica a un número limitado de URI de redireccionamiento. A continuación, añade cada URI de redireccionamiento limitado a la lista de URI de redireccionamiento de OAuth válidos.

  • Para las aplicaciones con un número limitado de URI de redireccionamiento, añade cada uno de ellos en la lista de URI de redireccionamiento de OAuth válidos.

  • Para las aplicaciones que solo utilizan el SDK de Facebook para JavaScript, el tráfico de redireccionamiento ya está protegido y no es necesario realizar ninguna otra acción.

Tras realizar estas acciones, asegúrate de activar el modo estricto.

Funcionamiento del modo estricto

Con el modo estricto, se solicita una coincidencia exacta con uno de los URI de la lista de URI de redireccionamiento de OAuth válidos para evitar su secuestro. Por ejemplo, si tu lista incluye www.ejemplo.com, el modo estricto no admitirá www.ejemplo.com/identificador como un redireccionamiento válido. Tampoco permitirá parámetros de consulta adicionales que no estén presentes en la lista de URI de redireccionamiento de OAuth válidos.

Uso de HTTPS

Utiliza HTTPS en lugar de HTTP como protocolo de internet, ya que en el primero se emplea cifrado de datos. HTTPS conserva la privacidad de los datos transmitidos y los protege frente a ataques de escucha. Además, evita que se manipulen los datos durante su transmisión mediante, por ejemplo, la introducción de anuncios o código malicioso.

A partir del 6 de octubre de 2018, será obligatorio que todas las aplicaciones utilicen HTTPS.

Activar el SDK de JavaScript para el inicio de sesión con Facebook

Al indicar que utilizas el SDK de JavaScript para el inicio de sesión mediante la configuración del botón Inicio de sesión con el SDK para JavaScript en “sí”, el dominio de la página que aloja el SDK debe coincidir con una de las entradas de la lista de dominios permitidos para el SDK para JavaScript. Esto garantiza que los identificadores de acceso solo se incluirán en las devoluciones de llamada de los dominios autorizados. Solo se admiten páginas HTTPS para las acciones de autenticación con el SDK para JavaScript de Facebook.

En las integraciones del SDK para JavaScript existentes creadas antes del 10 de agosto de 2021, esta lista se rellena con valores basados en el uso real. No es necesario llevar a cabo ninguna otra acción.

En las nuevas integraciones creadas después del 10 de agosto de 2021, debes añadir valores a esta lista.

Si observas que el campo de dominio del SDK para JavaScript de tu aplicación contiene URL que comienzan con *., haz los cambios pertinentes para utilizar URL de dominio absolutas con el fin de mejorar la seguridad.

Funcionamiento de la comprobación del URI de redireccionamiento

Los ataques de redireccionamiento abierto suceden cuando un agente malintencionado proporciona un parámetro redirect_uri no autorizado en la solicitud de inicio de sesión, lo que podría provocar la filtración de información confidencial, como un identificador de acceso, a través de la cadena o el fragmento de la consulta en el URI de redireccionamiento.

En las integraciones web personalizadas, debes proporcionar URI de redireccionamiento autorizados en la configuración de tu aplicación para evitar estos ataques. Cuando se realice una solicitud de inicio de sesión, el parámetro redirect_uri se comparará con las entradas de esta lista. El URI completo debe coincidir exactamente, incluidos todos los parámetros, con la excepción del parámetro de estado opcional, cuyo valor se ignora.

Navegadores en la aplicación y SDK para JavaScript

Normalmente, el SDK para JavaScript utiliza mensajes emergentes y devoluciones de llamadas para completar el inicio de sesión. Por este motivo, si el navegador en la aplicación no permite los mensajes emergentes, puede producirse un error. Cuando esto sucede, el SDK intenta efectuar automáticamente el redireccionamiento con un identificador de acceso a la página que lo ha invocado. Solo podrá efectuar este redireccionamiento de forma segura si el URI completo de la página se encuentra en la lista de URI de redireccionamiento de OAuth válidos.

Si las situaciones relacionadas con un navegador en la aplicación son importantes para tu aplicación web, debes añadir el dominio de tu página de inicio de sesión a la lista de dominios permitidos y el URI completo (ruta y parámetros de consulta incluidos) a los URI de redireccionamiento de OAuth válidos. Si tienes muchos URI diferentes en los que tu aplicación puede realizar el inicio de sesión, puedes especificar manualmente una opción fallback_redirect_uri en la llamada FB.login() para que solo tengas que añadir esa entrada a la lista de URI de redireccionamiento de OAuth válidos.

Bloqueo de la configuración de tu aplicación de Facebook

Puedes activar o desactivar cualquier proceso de autenticación que la aplicación no utilice para minimizar las posibilidades de ataque.

  • En los clientes, utiliza identificadores de acceso de corta duración generados mediante código en lugar de los identificadores que genera el cliente o los identificadores de larga duración que proporciona el servidor. El proceso de identificadores de acceso de corta duración generados mediante código requiere que el servidor de la aplicación intercambie el código por un identificador, lo que es más seguro que obtener un identificador en el navegador. Las aplicaciones deben emplear este proceso siempre que sea posible para aumentar la seguridad. Con solo activarlo, el malware ejecutado en el ordenador de un usuario no puede obtener ningún identificador de acceso para sus actividades. Puedes obtener más información en la documentación sobre identificadores de acceso.

  • Desactiva la opción “Inicio de sesión del cliente de OAuth” si la aplicación no lo utiliza. El inicio de sesión del cliente de OAuth es el interruptor global para utilizar los procesos de identificadores de este cliente. Si tu aplicación no utiliza ningún proceso de cliente de OAuth, incluidos los SDK de inicio de sesión con Facebook, deberías desactivarlos. Sin embargo, ten en cuenta que no puedes solicitar permisos para un identificador de acceso si has desactivado el inicio de sesión del cliente de OAuth. Esta opción se encuentra en la sección Productos > Inicio de sesión con Facebook > Configuración del panel de aplicaciones.

  • Desactiva el proceso de OAuth web o especifica una lista de redireccionamientos autorizados. La opción “Inicio de sesión de OAuth web” permite a cualquier proceso de identificador de cliente de OAuth que utilice el cuadro de diálogo de inicio de sesión web con Facebook devolver identificadores a tu propio sitio web. Esta opción se encuentra en la sección Productos > Inicio de sesión con Facebook > Configuración del panel de aplicaciones. Desactívala si no vas a crear un proceso personalizado de inicio de sesión web ni a utilizar el SDK de inicio de sesión con Facebook en la web.

  • Aplica HTTPS. Esta opción requiere HTTPS para los redireccionamientos de OAuth y que las llamadas al SDK de Facebook para JavaScript que devuelvan o requieran un identificador de acceso procedan únicamente de páginas HTTPS. Todas las aplicaciones que se hayan creado a partir de marzo de 2018 tienen este ajuste activado de forma predeterminada. Para las que no, deberías planificar su migración al uso exclusivo de URL HTTPS antes del 6 de octubre de 2018. La mayoría de los principales hosts de aplicaciones en la nube te permiten configurar automáticamente y de forma gratuita certificados TLS para tus aplicaciones. Si hospedas la aplicación en tu propio servidor, o si tu servicio de alojamiento no ofrece la opción de HTTPS de forma predeterminada, puedes obtener un certificado gratuito para tus dominios mediante Let’s Encrypt.

  • Desactiva el proceso de OAuth de navegador integrado si la aplicación no lo utiliza. Algunas aplicaciones para ordenadores y para móviles nativas autentican a los usuarios mediante un proceso de cliente de OAuth dentro de una vista web insertada. Si tu aplicación no lo hace, desactiva la opción en la sección Productos > Inicio de sesión con Facebook > Configuración del panel de aplicaciones.

  • Desactiva los procesos de inicio de sesión único para móviles si la aplicación no los utiliza. Si tu aplicación no utiliza el inicio de sesión para iOS o Android, desactiva la opción “Inicio de sesión único” en las secciones Configuración > Información básica correspondientes a ambos sistemas operativos.

El panel de aplicaciones contiene varias opciones adicionales que permiten a los desarrolladores cerrar vías de ataque que podrían convertirse en problemas de seguridad:

  • Información básica > Clave secreta de la aplicación: si la clave secreta de tu aplicación se ve comprometida alguna vez, puedes restablecerla aquí.
  • Información básica > Dominios de aplicaciones: utiliza esta opción para bloquear los dominios y subdominios que pueden usarse para realizar el inicio de sesión con Facebook en nombre de tu aplicación.
  • Opciones avanzadas > Tipo de aplicación: cuando crees una aplicación nativa para móviles o para ordenadores e incluyas en ella la clave secreta, establece esta opción en Native/Desktop para impedir la descompilación de la aplicación y el robo de la clave secreta.
  • Opciones avanzadas > Lista de IP del servidor autorizadas: especifica una lista de direcciones IP desde las que pueden realizarse llamadas a la API Graph con la clave secreta de la aplicación. Las llamadas a la API Graph realizadas con la clave secreta de la aplicación desde cualquier otra dirección devolverán un error. Las llamadas realizadas con identificadores de acceso de usuario no se ven afectadas por esta opción.
  • Opciones avanzadas > IP permitidas para la actualización de la configuración: bloquea las direcciones IP desde las que alguien puede modificar esta configuración de las aplicaciones para establecer un intervalo específico. Ten cuidado al establecer una lista de IP permitidas en una banda ancha residencial. Si tu dirección IP cambia, perderás la posibilidad de editar la configuración de la aplicación.
  • Opciones avanzadas > Correo electrónico para notificaciones de actualizaciones: envía una notificación por correo electrónico cuando se cambia la configuración en el panel de aplicaciones.
  • Opciones avanzadas > Seguridad de URL en conjuntos de publicaciones: impide a la aplicación publicar URL que no dirijan a un dominio de su propiedad. Esta opción no siempre es útil, especialmente si sabes que tu aplicación publicará enlaces a otros sitios.