Consideracions de Seguretat

Quan afegeixes suport per Persona al vostre lloc web, ella pren tantes mesures de seguretat com pot. No obstant això, algunes mesures de seguretat només poden ser manejades pel teu lloc web. Aquestes són llistades a continuació.

Pràctiques essencials

Verifica les assercions en el servidor

En utilitzar Persona, es passen les assercions d'identitat a la funció onlogin passat a navigator.id.watch(). Vostè sempre ha de passar a l'asserció del seu servidor per a la verificació, i només el servidor ha de resoldre la concessió dels permisos d'usuari addicionals basats en el resultat de la verificació:

// 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 tracta de verificar l'asserció utilitzant JavaScript executant-se al navegador de l'usuari, algun usuari maliciós podria suplantar la identitat d'un altre usuari legítim injectant codi i subvertint el teu codi JavaScript. Això és possible a causa que no es té control del navegador de l'usuari, on s'executa el codi.

Com esmentem línies a dalt, sempre ha de passar l'asserció al seu servidor per a la verificació. Fins i tot si esteu utilitzant l'API de verificació remota.

Especifiqueu explícitament el paràmetre audiència

Per verificar l'asserció, ha de realitzar una petició POST a https://verifier.login.persona.org/verify. La petició inclou el paràmetre anomenat audience:

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

El paràmetre audience és requerit. Sempre ha d'especificar explícitament audience en el seu codi, o a la configuració del seu codi. Específicament:

No confiï en la capçalera o header Host enviat pel navegador de l'usuari.
No confiï en paràmetres explícits enviats pel navegador de l'usuari, però generats usant JavaScript, p. e. document.location.

Si deixes que el navegador de l'usuari t'enviï el paràmetre audience, un lloc web maliciós pot reutilitzar les assercions del seu lloc web per autenticar-se al vostre lloc web.

Verifica els certificats SSL

Per a verificar una declaració, has de fer un petició POST a https://verifier.login.persona.org/verify. Comprova que la teva petició HTTPS verifiqui el certificat enviat des del servidor contra un certificat arrel fiable. Si no ho fas, un atacant podria presentar-se com verifer.login.persona.org i realitzar verificacions falses.

Revisa que la llibreria que fas servir per fer la comanda verifiqui els certificats correctament, i que has iniciat això amb un(s) certificat(s) arrel apropiat(s).

Per exemple, el mòdul urllib2 estàndard de Python 2.7 no valida certificats del servidor. En lloc d'això, recomanem utilitzar els mòduls "requests" o "urllib3" en Python 2.x, o la classe estàndard http.client.HTTPSConnection en Python 3.x. Per Perl, assegura't que fas servir almenys la versió 6.0 de libwww-perl. Depenent del llenguatge, llibreria, i sistema operatiu que estiguis usant, necessitaràs utilitzar algun CA (Certificate Authority) fiable o simplement el CA usat per verifier.login.persona.org.

Implementa proteccions CSRF

En un atac d'inici de sessió per CSRF (Cross-Site Request Forgery), l'atacant aconsegueix que l'usuari iniciï sessió dins del lloc web fent servir les credencials de l'atacant.

Per exemple: un usuari visita una web maliciosa que conté un element form. L'atribut action del form està configurat per fer una petició HTTP POST a https://www.google.com/login, donant-li el username i password de l'atacant. Quan l'usuari envia al form, la petició és enviada a Google, s'inicia sessió i el servidor de Google configura una galeta al navegador de l'usuari. Ara l'usuari sense saber-ho ha iniciat sessió amb el compte Google de l'atacant.

L'atac pot ser usat per reunir informació sensible de l'usuari. Per exemple, Web History de Google té la característica de registrar tots els termes de cerca de l'usuari. Si l'usuari inicia sessió dins del compte Google de l'atacant i l'atacant té la característica Web History activada, l'usuari li estarà enviant tota la seva informació a l'atacant.

Els atacs d'inici de sessió CSRF, i defenses potencials en contra d'aquests són documentats amb més detall a Robust Defenses for Cross-Site Request Forgery (PDF). Aquests atacs no són específics de Persona: la majoria de mecanismes de connexió són potencialment vulnerables a ells.

Hi ha una varietat de tècniques, les quals poden ser usades per protegir un lloc d'atacs de CSRF login, les quals són documentades amb més detall en l'estudi abans esmentat.

Una proposta és crear un identificador secret al servidor, compartit amb el navegador, i requerir al navegador que el proporcioni quan realitzi una comanda d'inici de sessió. Per exemple:

Tan aviat com l'usuari visiti el seu lloc, abans que aquest intenti iniciar sessió, creï una sessió per a ell al servidor. Emmagatzemeu l'ID de la sessió en una galeta del navegador.
Al servidor, generi un text aleatori d'almenys 10 caràcters alfanumèrics. Un UUID generat aleatòriament és una bona opció. Això és un token CSRF. Emmagatzemi això en la sessió.
Enviï el CSRF token el navegador a través de JavaScript incrustat o HTML com una variable oculta del formulari.
Assegureu-vos que l'enviament AJAX o la petició POST del formulari inclogui el token CSRF.
Al costat del servidor, abans d'acceptar la declaració, comproveu que el token CSRF enviat concorda amb el prèviament desat per la sessió.

Millores

Polítiques de seguretat de continguts (CSP)

Content Security Policy (CSP) és una capa extra de seguretat que ajuda a detectar i mitigar certs tipus d'atacs, incloent Cross Site Scripting (XSS) i atacs d'injecció de dades. Aquests atacs són usats per a tot, des robatori de dades a desconfiguració del lloc o distribució de malware.

Si utilitzes CSP al teu lloc, és possible que necessitis modificar les teves polítiques per permetre Persona. Depenent de la teva política, pots necessitar:

Eliminar javascript inline: URIs i reemplaçar amb codi carregat des d'un arxiu script addicional. L'arxiu pot buscar elements basant-se en el seu ID, i després agafar l'element configurant onclick o cridant a addEventListener().
Permetre https://login.persona.org com a script-src i frame-src perquè l'arxiu pugui carregar el fitxer remot include.js i aquest arxiu pugui comunicar-se amb la implementació de Persona.

Un exemple de la configuració d'Apache pot incloure:

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