L’autenticació i la gestió de sessions inclou tots els aspectes de la manipulació de l’autenticació d’usuari i la gestió de sessions actives. L’autenticació és un aspecte crític d’aquest procés, però fins i tot els mecanismes d’autenticació sòlids poden ser minats per funcions defectuoses de gestió de credencials, incloent el canvi de contrasenya, oblidar la meva contrasenya, recordar la meva contrasenya, actualització de compte, i altres funcions relacionades. Degut a que els atacs “passants” són probables per a moltes aplicacions web, totes les funcions de gestió de comptes haurien de requerir reautenticació fins i tot si l’usuari té un id de sessió vàlid.
L’autenticació d’usuari a la web implica típicament l’ús d’un id d’usuari i una contrasenya. Hi ha disponibles mètodes més forts d’autenticació, com ara tokens criptogràfics basats en software i hardware o biometria, però aquests mecanismes són prohibitius en termes de cost per a la majoria d’aplicacions web. Una àmplia gamma de fallades en la gestió de comptes i sessions pot resultar en el compromís de comptes d’usuari o d’administració del sistema. Els equips de desenvolupament sovint subestimen la complexitat de dissenyar un esquema d’autenticació i gestió de sessions que protegeixi adequadament les credencials en tots els aspectes del lloc. Les aplicacions web han d’establir sessions per seguir el rastre de les sol·licituds de cada usuari. HTTP no proporciona aquesta capacitat, així que les aplicacions web han de crear-la elles mateixes. Sovint, l’entorn de l’aplicació web proporciona una capacitat de sessió, però molts desenvolupadors prefereixen crear els seus propis tokens de sessió. En qualsevol cas, si els tokens de sessió no estan adequadament protegits, un atacant pot segrestar una sessió activa i assumir la identitat d’un usuari. Crear un esquema per crear tokens de sessió forts i protegir-los durant tot el seu cicle de vida ha resultat esquiu per a molts desenvolupadors. A no ser que totes les credencials d’autenticació i identificadors de sessió estiguin protegits amb SSL en tot moment i protegits contra la divulgació d’altres fallades, com ara el scripting en creu, un atacant pot segrestar la sessió d’un usuari i assumir la seva identitat.
Solució
L’ús acurat i adequat de mecanismes d’autenticació i gestió de sessions personalitzats o de prestatgeria hauria de reduir significativament la probabilitat d’un problema en aquesta àrea. Definir i documentar la política del vostre lloc respecte a la gestió segura de les credencials dels usuaris és un bon primer pas. Assegurar-se que la vostra implementació fa complir aquesta política de manera consistent és clau per tenir un mecanisme d’autenticació i gestió de sessions segur i robust. Algunes àrees crítiques inclouen:
- Força de la contrasenya: les contrasenyes haurien de tenir restriccions que requereixin una mida mínima i complexitat per a la contrasenya. La complexitat normalment requereix l’ús de combinacions mínimes de caràcters alfabètics, numèrics i/o no alfanumèrics en la contrasenya d’un usuari (per exemple, almenys un de cada). Els usuaris haurien de ser requerits per canviar la seva contrasenya periòdicament. S’hauria de prevenir als usuaris de reutilitzar contrasenyes anteriors.
- Ús de la contrasenya: els usuaris haurien de ser restringits a un nombre definit de intents de login per unitat de temps i els intents de login fallits repetits haurien de ser registrats. Les contrasenyes proporcionades durant els intents de login fallits no haurien de ser registrades, ja que això podria exposar la contrasenya d’un usuari a qui pugui obtenir accés a aquest registre. El sistema no hauria d’indicar si era el nom d’usuari o la contrasenya el que estava malament si un intent de login falla. Els usuaris haurien de ser informats de la data/hora del seu últim login exitós i el nombre d’intents d’accés fallits al seu compte des de llavors.
- Controls de canvi de contrasenya: hauria d’utilitzar-se un únic mecanisme de canvi de contrasenya allà on es permet als usuaris canviar una contrasenya, independentment de la situació. Sempre s’hauria de requerir als usuaris que proporcionin tant la seva contrasenya antiga com la nova quan canviïn la seva contrasenya (com tota la informació del compte). Si les contrasenyes oblidades s’envien per correu electrònic als usuaris, el sistema hauria de requerir que l’usuari es reautentiqui sempre que l’usuari estigui canviant la seva adreça de correu electrònic, d’altra manera un atacant que temporalment tingui accés a la seva sessió (per exemple, acostant-se al seu ordinador mentre estan connectats) simplement pot canviar la seva adreça de correu electrònic i sol·licitar que se li enviï una contrasenya ‘oblidada’.
- Emmagatzematge de contrasenyes: totes les contrasenyes han de ser emmagatzemades en forma encriptada o hash per protegir-les de l’exposició, independentment de on estiguin emmagatzemades. La forma hash és preferida ja que no és reversible. L’encriptació hauria de ser utilitzada quan es necessiti la contrasenya en text pla, com ara quan s’utilitza la contrasenya per iniciar sessió en un altre sistema. Les contrasenyes mai haurien de ser codificades en cap codi font. Les claus de desencriptació han de ser fortament protegides per assegurar que no poden ser agafades i utilitzades per desencriptar el fitxer de contrasenyes.
- Protecció de les credencials en trànsit: l’única tècnica efectiva és encriptar tota la transacció de login utilitzant alguna cosa com SSL. Les transformacions simples de la contrasenya com ara fer un hash a la clienta abans de la transmissió proporcionen poca protecció ja que la versió hash pot simplement ser interceptada i retransmesa encara que la contrasenya en text pla real potser no sigui coneguda.
- Protecció de l’ID de sessió: idealment, tota la sessió d’un usuari hauria de ser protegida via SSL. Si això es fa, llavors l’ID de sessió (per exemple, cookie de sessió) no pot ser agafat de la xarxa, que és el major risc d’exposició per a un ID de sessió. Si SSL no és viable per motius de rendiment o altres, llavors els IDs de sessió han de ser protegits d’altres maneres. Primer, mai haurien d’estar inclosos en l’URL ja que poden ser emmagatzemats en la memòria cau pel navegador, enviats en la capçalera de referència, o accidentalment reenviats a un ‘amic’. Els IDs de sessió haurien de ser llargs, complicats, números aleatoris que no es poden endevinar fàcilment. Els IDs de sessió també poden ser canviats freqüentment durant una sessió per reduir el temps que un ID de sessió és vàlid. Els IDs de sessió han de ser canviats quan es passa a SSL, s’autentiquen, o altres transicions majors. Mai s’haurien d’acceptar IDs de sessió escollits per un usuari.
- Llistes de comptes: els sistemes haurien de ser dissenyats per evitar que els usuaris puguin accedir a una llista dels noms de compte al lloc. Si s’han de presentar llistes d’usuaris, es recomana que es presenti alguna forma de pseudònim (nom de pantalla) que es mapatja al compte real en lloc d’això. D’aquesta manera, el pseudònim no pot ser utilitzat durant un intent de login o algun altre hack que vagi després del compte d’un usuari.
- Emmagatzematge en memòria cau del navegador: les dades d’autenticació i sessió mai haurien de ser enviades com a part d’un GET, sempre s’hauria d’utilitzar POST en lloc d’això. Les pàgines d’autenticació haurien de ser marcades amb totes les varietats de l’etiqueta de no emmagatzematge en memòria cau per prevenir que algú utilitzi el botó de retrocés en el navegador d’un usuari per retrocedir a la pàgina de login i reenviar les credencials prèviament introduïdes. Molts navegadors ara suporten la bandera AUTOCOMPLETE=OFF per prevenir l’emmagatzematge de credencials en memòries cau d’autocompletat.
- Relacions de confiança: l’arquitectura del vostre lloc hauria d’evitar la confiança implícita entre components sempre que sigui possible. Cada component hauria d’autenticar-se a qualsevol altre component amb el qual estigui interactuant a no ser que hi hagi una raó forta per no fer-ho (com ara rendiment o falta d’un mecanisme utilitzable). Si es requereixen relacions de confiança, haurien d’estar en lloc mecanismes procedimentals i arquitectònics forts per assegurar que aquesta confiança no pot ser abusada a mesura que l’arquitectura del lloc evoluciona amb el temps.
Per a un escaneig complet de vulnerabilitats i protecció, considereu associar-vos amb una solució de confiança com INFRA (www.infrascan.net). INFRA ofereix escaneig de seguretat avançat amb check.website i serveis de monitoratge per identificar totes les vulnerabilitats, assegurant la robustesa de les vostres aplicacions web.