Consideraciones de Seguridad

This is an archived page. It's not actively maintained.

Cuando agregas soporte para Persona en tu sitio web, ella toma tantas medidas de seguridad como puede. Sin embargo, algunas medidas de seguridad solo pueden ser manejadas por tu sitio web. Estas son listadas a continuaci贸n.

Pr谩cticas Esenciales

Verificar la confirmaci贸n en tu servidor

Cuando utilizas Persona, las declaraciones de identidad son pasadas dentro de la funci贸n onlogin a trav茅s de

navigator.id.watch()

Siempre debes pasar la aserci贸n a tu servidor para verificarla, y solo tu servidor debe decidir si autoriza al usuario permisos adicionales en base al resultado de la verificaci贸n:

// Inside navigator.id.watch({ ...
onlogin: function(assertion) {
  // A user wants to log in! Here you need to:
  // 1. Send the assertion to your backend for verification and to create a session.
  // 2. Update your UI.
},

Si trata de verificar la aserci贸n usando JavaScript ejecut谩ndose en el navegador del usuario, alg煤n usuario malicioso podr铆a suplantar por otro usuario leg铆timo de su sitio inyectando c贸digo bloqueando tu c贸digo JavaScript. Esto es posible debido a que no se tiene control del navegador del usuario, donde se ejecuta el c贸digo.

Como mencionamos lineas arriba, siempre debe pasar la aserci贸n a su servidor para la verificaci贸n. Incluso si est谩 usando la API de verificaci贸n remota.

Especifique expl铆citamente el par谩metro audience

Para verificar la aserci贸n, debe realizar un pedido POST a https://verifier.login.persona.org/verify. El pedido incluye el par谩metro llamado audience:

assertion=<ASSERTION>&audience=https://mysite.com:443"

El par谩metro audience es requerido. Siempre debe especificar expl铆citamente audience en el c贸digo, o en la configuraci贸n del c贸digo. Espec铆ficamente:

  • No confie en la cabecera o header Host enviado por el navegador del usuario.
  • No conf铆e en el par谩metro explicito enviado por el navegador del usuario, pero generado usando JavaScript, e.g. document.location.

Si dejas que el navegador del usuario te env铆e el par谩metro audience, esto deja la posibilidad de que un sitio web malicioso pueda reusar las declaraciones de su sitio web para autenticarse en tu sitio web.

Verifica los certificados SSL

Para verificar una aserci贸n, debes realizar un petici贸n POST a https://verifier.login.persona.org/verify. Debes asegurarte que tu petici贸n HTTPS verifique el certificado enviado desde el servidor contra un certificado ra铆z confiable. Si no lo haces, un atacante podr铆a presentarse como verifer.login.persona.org y realizar verificaciones falsas.

Revisa que la libreria que usas para hacer el pedido verifique los certificados correctamente, y que has iniciado esto con un certificado de administrador apropiado.

Por ejemplo, el modulo urllib2 est谩ndar de Python 2.7 no valida certificados del servidor. En lugar de ello, recomendamos utilizar los m贸dulos "requests" o "urllib3" en Python 2.x, o la clase est谩ndar http.client.HTTPSConnection en Python 3.x. Para Perl, aseg煤rate que usas al menos la versi贸n 6.0 de libwww-perl. Dependiendo del lenguaje, librer铆a, y sistema operativo que est茅s usando, vas a necesitar utilizar alg煤n CA (Certificate Authority) confiable o el CA simple usado por verifier.login.persona.org.

Implementar protecci贸n CSRF

En un ataque de inicio de sesi贸n por CSRF (Cross-Site Request Forgery), el atacante utiliza CSRF para iniciar la sesi贸n del usuario dentro del sitio web usando las credenciales del atacante.

Por ejemplo: un usuario visita una web maliciosa que contiene un elemento form. El atributo action del form est谩 configurado para hacer una petici贸n HTTP POST a http://www.google.com/login, d谩ndole el username y password del atacante. Cuando el usuario env铆a el form, el pedido es enviado a Google, se inicia sesi贸n y el servidor de Google configura una cookie en el navegador del usuario. Ahora el usuario sin saberlo ha iniciado sesi贸n con la cuenta Google del atacante.

El ataque puede ser usado para reunir informaci贸n sensible del usuario. Por ejemplo, Web History de Google tiene la caracter铆stica de registrar todos los t茅rminos de b煤squeda del usuario. Si el usuario inicia sesi贸n dentro de la cuenta Google del atacante y el atacante tiene la caracter铆stica Web History activada, el usuario le estar谩 enviando toda su informaci贸n al atacante.

Los ataques de inicio de sesi贸n CSRF, y defensas potenciales contra 茅stos son documentados con mayor detalle en Robust Defenses for Cross-Site Request Forgery (PDF). Estos ataques no son espec铆ficos de Persona: la mayor铆a de mecanismos de inicio de sesi贸n son potencialmente vulnerables a ellos.

Existen una variedad de t茅cnicas, las cuales pueden ser usadas para proteger un sitio de ataques de inicio de sesi贸n CSRF, las cuales son documentadas con mayor detalle en el estudio antes mencionado.

Una propuesta es crear un identificador secreto en el servidor, compartido con el navegador, y requerir al navegador que lo proporcione cuando realice un pedido de inicio de sesi贸n. Por ejemplo:

  1. Tan pronto como el usuario visite su sitio, antes de intentar iniciar sesi贸n cree una sesi贸n para 茅l en el servidor. Almacene el ID de la sesi贸n en una cookie del navegador.
  2. En el servidor, genere un texto aleatorio de al menos 10 caracteres alfanum茅ricos. un UUID generado aleatoriamente es una buena opci贸n. Esto es un token CSRF. Almacene esto en la sesi贸n.
  3. Envie el CSRF token al navegador a trav茅s de JavaScript embebido o HTML como una variable oculta del formulario.
  4. Asegurese que el envio AJAX o la petici贸n POST del formulario incluya el token CSRF.
  5. En el lado del servidor, antes de aceptar la aserci贸n, revise que el token CSRF enviado concuerde con el almacenado en la sesi贸n.

Mejoras

Politicas de seguridad del contenido (Content Security Policy o CSP)

Content Security Policy (CSP) es una capa extra de seguridad que ayuda a detectar y mitigar ciertos tipos de ataques, incluyendo Cross Site Scripting (XSS) y ataques de inyecci贸n de datos. Estos ataques son usados para todo desde robo de datos a desconfiguraci贸n del sitio o distribuci贸n de malware.

SI utilizas CSP en tu siitio, es posible que necesites modificar tu politica para permitir Persona. Dependiendo de tu pol铆tica, puedes necesitar:

  • Eliminar inline javascript: URIs y reemplazarlos con c贸digo cargado desde un archivo script adicional. El archivo puede ver elementos bas谩ndose en su ID, y luego atacar al elemento configurando onclick o llamando a addEventListener().
  • Permitir https://login.persona.org como script-src y frame-src para que el archivo pueda cargar el archivo remoto  include.js  y ese archivo pueda comunicarse con la llamada a la implementaci贸n de Persona.

Un ejemplo de la configuraci贸n de Apache puede incluir:

Header set X-Content-Security-Policy: "default-src 'self'; frame-src 'self' https://login.persona.org ; script-src 'self' https://login.persona.org"