Wat is gebroken authenticatie? Voorbeelden en hoe u dit voorkomt

Wat is gebroken authenticatie? Wat maakt een sterk wachtwoord? Hoe kan slecht sessiebeheer leiden tot gebroken authenticatie? Lees verder om erachter te komen.

In de afgelopen jaren is het aantal datalekken gestegen. Volgens het IBM 2022 rapport is de wereldwijde kosten van een datalek gestegen tot $4,35 miljoen, terwijl de VS de eerste plaats inneemt met gemiddelde datalek kosten van bijna $9,5 miljoen. Hackers blijven oude methoden gebruiken en nieuwe technieken uitvinden om gevoelige consumentengegevens te bemachtigen.

Eén manier om een gericht systeem binnen te dringen, is door verschillende authenticatiekwetsbaarheden te onderzoeken. Gebroken authenticatie is vaak afhankelijk van andere aanvallen, zoals social engineering, phishing, man-in-the-middle of cross-site scripting.

In dit artikel leggen we uit welk gebruikersgedrag en welke fouten van ontwikkelaars leiden tot gebroken authenticatie en delen we effectieve strategieën om dit te voorkomen.

Wat is gebroken authenticatie?

Voordat we ingaan op gebroken authenticatie, definiëren we eerst authenticatie. In essentie is authenticatie het verifiëren van de identiteit van de gebruiker door het opvragen van privé-informatie die alleen de gebruiker kent, zoals hun gebruikers-ID, e-mailadres en wachtwoord, of een vingerafdrukscan.

Gebroken authenticatie is een webkwetsbaarheid die hackers in staat stelt om authenticatiecontroles te omzeilen, iemands identiteit te stelen om in te loggen, of andere beveiligingsmechanismen te breken. Gebroken authenticatie kan worden veroorzaakt door nalatig wachtwoordbeheer en slecht sessiebeheer.

Voorbeelden van slecht wachtwoordbeheer

Het gebruik van de inloggegevens van iemand anders is een van de meest voorkomende manieren voor kwaadwillenden om toegang te krijgen tot een systeem. In 2022 waren gestolen inloggegevens de primaire aanvalsvector in 19% van de datalekken in de IBM-studie van 2022. En dat is niet verrassend.

Ten eerste gebruiken veel mensen zwakke wachtwoorden, en dan hebben we het niet over ‘123’, ‘admin’ huisdiernamen en geboortedata, hoewel miljoenen gebruikers deze nog steeds gebruiken. En we overdrijven niet – de onderstaande gegevens spreken voor zich.

Bovendien toont onderzoek aan dat 44% van de consumenten hun wachtwoord af en toe wijzigt. Dit betekent dat hackers brute-force en wachtwoord-spray aanvallen kunnen uitvoeren en met weinig moeite inloggegevens kunnen stelen.

Brute-force aanvallen zijn geautomatiseerd en gebaseerd op een simpel trial-and-error methode. Wachtwoord-spray is een type brute-force aanval. In plaats van tal van wachtwoorden op één account te proberen, gebruikt het echter hetzelfde wachtwoord voor meerdere gebruikers. Dit laatste stelt hackers in staat om accountvergrendelingen te omzeilen na een bepaald aantal mislukte inlogpogingen.

Een andere groep mensen gebruikt hetzelfde e-mailadres en wachtwoord voor al hun accounts. Volgens Statista creëerde slechts 12% van de gebruikers altijd nieuwe wachtwoorden bij het registreren van nieuwe accounts in 2021, terwijl 45% altijd of meestal oude wachtwoorden hergebruikte.

Dit leidde tot credential-stuffing aanvallen. Het dark web staat boordevol gelekte e-mails en wachtwoorden van verschillende organisaties. Omdat mensen dezelfde wachtwoorden voor meerdere apps gebruiken, kunnen aanvallers inloggegevens van het dark web gebruiken en deze proberen op gerichte websites. Credential stuffing is ook een geautomatiseerde aanval, wat betekent dat het een inspanningsarme onderneming is voor hackers.

Maar gebruikers zijn niet de enige schuldigen; er kunnen ook fouten aan de kant van de ontwikkelaars zijn. Wachtwoorden kunnen bijvoorbeeld in platte tekst worden opgeslagen of zwakke hashes gebruiken, waardoor het voor hackers gemakkelijk is om ze met rainbow tables te ontsleutelen.

Waarom is sessiebeheer belangrijk?

Sessiebeheer is een integraal onderdeel van moderne webapplicaties. Een websessie is een reeks netwerk-HTTP-verzoeken en -antwoorden die betrekking hebben op dezelfde gebruiker. Webapps gebruiken sessies om informatie over een bepaalde gebruiker te bewaren, zodat ze tijdens de sessie goed kunnen reageren op al hun acties en verzoeken.

Wanneer een nieuwe gebruiker bijvoorbeeld de site bezoekt, worden zijn taalvoorkeuren gedurende de hele sessie opgeslagen, wat de bruikbaarheid verbetert.

Sessies zijn ook even nuttig in situaties na authenticatie. Zodra de gebruiker is geauthenticeerd, kan de webapp deze gebruiker identificeren tijdens volgende interacties en de bijbehorende beveiligingscontroles toepassen.

Zodra een sessie is aangemaakt, krijgt de gebruiker een sessie-ID of een token toegewezen dat tijdelijk gelijkwaardig is aan de sterkste authenticatiemethode en dat tijdens de sessie door de gebruiker en de webapp wordt uitgewisseld.

Voorbeelden van gebroken authenticatie en sessiebeheer

Correcte sessie-implementatie speelt een enorme rol bij het voorkomen van authenticatiekwetsbaarheden. Hier zijn slechts enkele voorbeelden van hoe onjuist sessiebeheer leidt tot gebroken authenticatie.

Sessiekaping (Session Hijacking). Dit kan vele vormen aannemen. Het eenvoudigste voorbeeld van sessiekaping is wanneer een gebruiker zijn sessie op een openbare computer niet ongeldig maakt: hij sluit mogelijk alleen de browservensters zonder uit te loggen bij de apps. In dat geval kan de persoon die daarna dezelfde computer gebruikt, die gebruiker gemakkelijk imiteren, omdat de sessie nog steeds actief is en de apps ontgrendeld zijn.

Maar hackers gaan niet zomaar naar openbare plaatsen om hun geluk te beproeven. De meeste van hun aanvallen worden van tevoren gepland en op afstand uitgevoerd. Een andere manier om een sessie te kapen is door netwerkverkeer af te luisteren met packet sniffers zoals Wireshark. Als webapps alleen TLS-encryptie gebruiken op inlogpagina’s, kunnen hackers het verkeer op andere pagina’s monitoren en sessiecookies stelen.

Kwaadwillende actoren kunnen ook proberen de sessietoken te stelen met cross-site scripting (XSS). In principe maken ze een link met een speciale code die wordt uitgevoerd zodra erop wordt geklikt. Het script kan worden geschreven in JavaScript of elke andere client-side taal. Hier is een voorbeeld van een kwaadaardig script dat de cookiewaarde onthult in een pop-up:

<script>

    alert(document.cookie);

</script>

Sessie-fixatie (Session Fixation). Bij een sessie-fixatieaanval maakt de hacker verbinding met de webapp om een geldige sessie-ID te verkrijgen en misleidt vervolgens een legitieme gebruiker, hetzij via social engineering of een phishing-site, om zichzelf met die sessie-ID te authenticeren. Op deze manier kan de hacker de gebruiker imiteren en toegang krijgen tot hun account als de app de sessie-ID niet vernieuwt na authenticatie.

Hier is een voorbeeld van een kwaadaardige link die de waarde van de sessie-ID van het slachtoffer in hun cookie wijzigt als ze erop klikken:

http://website.сom/<script>document.cookie=”sessionid=abcd”;</script>

Sessie-ID URL-herschrijving (Session ID URL rewriting). Als een webapp de sessie-ID in de URL invoegt in plaats van deze in de cookie op te slaan, stelt deze deze bloot en stelt deze iedereen die de URL volgt in staat de sessie over te nemen. Dus als zo’n URL per ongeluk wordt gedeeld, kan een andere gebruiker de sessie overnemen zonder zich te hoeven authenticeren.

Bedrijven getroffen door gebroken authenticatie

Laten we kijken naar praktijkvoorbeelden van bedrijven die te maken kregen met datalekken als gevolg van misbeheer van inloggegevens of andere authenticatiekwetsbaarheden.

Revolut is a money app for sending funds, requesting payments, and splitting bills in over 200 countries. In September 2022, Revolut suffered a data breach, exposing names, emails, phone numbers, postal addresses, device details, transaction history, and the last known IP addresses of about 50K users.

Even though the debit and credit card data was masked and unusable, the stolen information can be used for identity theft and phishing attacks. The breach investigators believe the database was compromised by an employee who fell victim to a meticulously crafted social engineering attack and handed login credentials to the hackers.

Twilio is a customer engagement platform that provides communication APIs for SMS, voice, and video channels. Twilio was breached in August 2022; hackers accessed data from 125 Twilio customers. Among the secondary victims of the breach were big names like Signal and Okta. Again, the attack was performed by tricking employees into following a phishing URL from SMS, allegedly to update expired passwords or see scheduling changes.

Twitter, one of the world’s largest social media networks, was also hacked in 2022. What happened is that their code update in June 2021 caused the following vulnerability: when hackers submitted an email or phone number to Twitter’s system, the site would reveal the Twitter account associated with that phone number or email. As a result, the personal data of 200 mln users was disclosed, which can lead to phishing fraud or identity theft in the future.

Crypto.com is a cryptocurrency exchange that lost about $30 mln in Bitcoin and Ethereum. Its two-factor authentication system turned out to be weak enough for hackers to bypass it. Hackers managed to withdraw funds from 483 customer accounts. The company intends to replace the two-factor authentication with a multifactor one to curb such incidents henceforward.

LastPass is a password manager that allows you to store and share passwords and other valuable documents. It was breached twice. The first time hackers stole part of the source code and some proprietary technical information through a compromised developer’s account. The second time they stole customer password vaults. While the latter are encrypted, hackers can brute-force the master passwords that lock the vaults.

Hoe gebroken authenticatie te voorkomen

De beste manier om gebroken authenticatie te voorkomen, is door een beveiligingsaanpak met meerdere lagen te implementeren. Laten we de essentiële zaken doornemen die u hierbij zullen helpen.

Multi-factorauthenticatie toevoegen

Multi-factorauthenticatie (MFA) is een extra beveiligingslaag die vereist dat de gebruiker een ander bewijsstuk overlegt om in te loggen. Dit kan een pincode zijn, een code die naar uw telefoon of e-mail wordt verzonden, een vingerafdruk, een scan van het gezicht of de iris, of een eenmalig wachtwoord gebaseerd op tijd (TOTP) van een bijbehorende authenticatie-app.

Microsoft is van mening dat het toevoegen van MFA 99,9% van de geautomatiseerde wachtwoordgerelateerde aanvallen zou hebben gestopt. MFA heeft echter verschillende nadelen: het vermindert de bruikbaarheid, voegt externe afhankelijkheden toe aan het systeem en biedt geen gemakkelijke manier om het opnieuw in te stellen zonder het doel ervan te ondermijnen.

Als uitweg kan MFA alleen worden geïmplementeerd voor beheerders en gebruikers met hoge rechten of alleen voor transacties met grote impact. De manier waarop MFA moet worden geïmplementeerd, hangt af van factoren zoals het dreigingsmodel van de app, de technische vaardigheid van de gebruikers, de mate van administratieve controle over gebruikers en overheadkosten.

CAPTCHA toevoegen

CAPTCHA is de afkorting van Completely Automated Public Turing Test to Tell Computers and Humans Apart. In lekentaal is het een snelle controle om mensen van bots te onderscheiden.

Originele CAPTCHA’s vereisten dat de gebruiker vervormde en overlappende tekens en cijfers moest raden en deze in het invoerveld moest invoeren. Naarmate bots slimmer werden in patroonherkenning, ontstond de behoefte aan meer ingewikkelde op afbeeldingen gebaseerde tests.

CAPTCHA’s voegen zeker wrijving toe aan de gebruikerservaring, dus het is logisch om ze alleen te gebruiken na een paar mislukte inlogpogingen.

Hoewel CAPTCHA brute-force-aanvallen ongemakkelijk en duurder maakt, kan het geen 100% bescherming tegen deze aanvallen garanderen.

Wachtwoorden veilig opslaan

Iedereen heeft waarschijnlijk gehoord dat wachtwoorden nooit in platte tekst mogen worden opgeslagen, omdat databases voortdurend worden gecompromitteerd. Dus zelfs als een hacker de database te pakken krijgt, blijven de inhoud ervan gecodeerd.

Ontwikkelaars kunnen dit bereiken met moderne hashing-algoritmen. Hashing is, in tegenstelling tot encryptie, een eenrichtingsfunctie, dus u kunt het niet ontsleutelen, en daarom moeten wachtwoorden worden gehasht in plaats van versleuteld.

Tegelijkertijd zijn er nog steeds workarounds, zoals het berekenen van hashes voor veelgebruikte wachtwoorden en deze vervolgens vergelijken met de hashes uit de gelekte database. Om het werk van hackers moeilijker te maken, moeten wachtwoordhashes worden gezout, wat betekent dat een willekeurig gegenereerde tekenreeks die uniek is voor elke gebruiker, aan de hashes wordt toegevoegd.

Met gezouten wachtwoordhashes duurt het aanzienlijk langer om te kraken en is het onmogelijk om te zeggen of twee gebruikers hetzelfde wachtwoord hebben, omdat verschillende zouten verschillende hashes opleveren, ongeacht of de wachtwoorden van de gebruikers identiek zijn.

Handhaaf sterke wachtwoordbeleidsregels

Wat is een sterk wachtwoord? Volgens het National Institute of Standards and Technology moeten wachtwoorden minimaal 8 tekens lang zijn en geen herhalende of opeenvolgende tekens bevatten (zoals aaaa of abc123). Bovendien moeten gebruikers de keuze krijgen uit alle tekens, inclusief Unicode en spaties.

Maar dat is de laagste drempel, en u wilt niet op het absolute minimum zitten als het om beveiliging gaat. De OWASP Application Security Verification Standard vereist wachtwoorden van minimaal 12 tekens lang, terwijl ontwikkelaars van wachtwoordsterktemeters zoals Bitwarden 14 tot 16 tekens suggereren.

Over het algemeen geldt: hoe langer het wachtwoord, hoe beter, omdat dit het aantal combinaties dat een botnet moet kraken vergroot. Maar houd er rekening mee dat de tekens willekeurig moeten worden gegenereerd.

Sommige websites beperken het aantal tekens dat u kunt gebruiken, dus een andere manier om complexiteit aan uw wachtwoord toe te voegen, is door hoofdletters, speciale tekens en cijfers te gebruiken. Ook hier geldt dat willekeur een sleutelfactor is bij het toevoegen van deze elementen. Bijvoorbeeld, “Logmein!321” is een verschrikkelijk wachtwoordpatroon, terwijl “l_w4XgH9~Wiq” is wat we proberen te bereiken.

Het inlogformulier moet een ingebouwde wachtwoordsterktemeter hebben die wachtwoorden controleert tegen woorden uit een woordenboek, eerder gelekte wachtwoorden of contextspecifieke woorden, zoals de service- of gebruikersnaam en hun afgeleiden.

Wanneer u beleid voor wachtwoordverloop introduceert, bedenk dan dat medewerkers vaak slechts één teken wijzigen om het achter de rug te hebben en verder te gaan met hun dagelijkse taken. Daarom is het belangrijk om medewerkers te onderwijzen over wat een sterk wachtwoord is en de wachtwoordwijziging alleen te vragen als er sprake is van een vermoeden van of een daadwerkelijke compromis. Want hackers wachten niet op ontdekte inloggegevens, ze handelen onmiddellijk.

Het bedenken van sterke wachtwoorden voor talloze services en het veilig opslaan ervan is zeker een extra last voor medewerkers. Organisaties moeten dus een goedgekeurde methode bieden voor het genereren en opslaan van bedrijfs­wachtwoorden, of het nu gaat om fysieke opslag, wachtwoordbeheersoftware, of een combinatie van beide, en de acties van medewerkers in verschillende scenario’s duidelijk definiëren.

Anders blijven medewerkers zwakke, gemakkelijk te onthouden wachtwoorden gebruiken en improviseren met opslag, waarbij ze wachtwoorden opslaan op persoonlijke telefoons of in Gmail-concepten.

Om denial-of-service-aanvallen met lange wachtwoorden te voorkomen, moet de maximale wachtwoordlengte worden ingesteld, wat meestal 64 tekens is.

Verbeter de drempel voor accountvergrendeling

Een accountvergrendeling is een tweesnijdend zwaard. Enerzijds is het een van de meest voorkomende en effectieve beveiligingen tegen brute-force-aanvallen, omdat het account na een bepaald aantal mislukte pogingen simpelweg wordt vergrendeld.

Anderzijds kunnen accountvergrendelingen gemakkelijk een denial-of-service-situatie creëren. Hackers kunnen geautomatiseerde aanvallen lanceren tegen alle gebruikers in een organisatie, waardoor er massale accountvergrendelingen ontstaan en klantenserviceteams worden overspoeld met telefoontjes van gebruikers. De kosten van downtime en reputatierisico’s zouden enorm zijn.

Een ander scenario is wanneer een gebruiker haast had of opgewonden was en een paar keer zijn e-mailadres of wachtwoord verkeerd heeft getypt. Als de drempel voor accountvergrendeling te laag is, kan dit leiden tot een onbedoelde vergrendeling.

Helaas is er geen wondermiddel dat het dilemma van accountvergrendeling zou oplossen. Het is de verantwoordelijkheid van elk bedrijf om een goed evenwicht te vinden tussen beveiliging en operationele efficiëntie. Bij het definiëren van de drempel voor accountvergrendeling is het belangrijk om te berekenen hoeveel gissingen aanvallers per dag kunnen hebben en ze te vertragen door de drempel, duur en resetinstellingen voor accountvergrendeling dienovereenkomstig aan te passen.

Toon generieke fouten

Foutafhandeling is een andere opening voor kwaadwillende actoren om informatie te verzamelen en binnen te komen. Als foutmeldingen erg specifiek zijn, maken ze het werk van de hacker veel gemakkelijker, omdat ze precies weten wat er mis is gegaan, welke technologieën en frameworkversies worden gebruikt en hun aanval dienovereenkomstig kunnen plannen.

Als een boef bijvoorbeeld probeert in te loggen met de inloggegevens van iemand anders, en ze zien “Inloggen mislukt; account is uitgeschakeld”, verspillen ze geen tijd en gaan ze naar een ander account. Of erger nog, de gebruikersnaam kan in de melding zelf worden onthuld, zoals “Inloggen voor gebruiker Boo: ongeldig wachtwoord”.

Daarom is het beter om generieke foutmeldingen te tonen voor registratie, inloggen van een bestaande gebruiker en wachtwoordherstel.

Een ander aspect om rekening mee te houden is de verwerkingstijd. Deze moet hetzelfde zijn, ongeacht de uitkomst, zodat de hacker geen tijdgebaseerde aanval kan uitvoeren.

Bijvoorbeeld, bij het gebruik van de “snelle exit”-aanpak, zal de app snel een foutmelding geven als de gebruiker niet bestaat. Echter, als de gebruiker wel bestaat, maar het wachtwoord onjuist is, zal de app meer stappen doorlopen en langer duren om te reageren. Hierdoor kan de hacker onderscheid maken tussen een verkeerde gebruikersnaam en een verkeerd wachtwoord op basis van de reactietijd van de foutmelding.

Het is ook cruciaal om ervoor te zorgen dat er geen informatie via de URL wordt gelekt. De app kan een algemeen bericht teruggeven aan de gebruiker, maar een andere HTTP-foutcode, afhankelijk van een succesvolle (200 OK) of mislukte (403 Forbidden) login.

Hoewel algemene berichten het voor hackers moeilijker maken om informatie te verzamelen, kunnen ze consumenten in verwarring brengen en een negatieve invloed hebben op de acceptatie en retentie van gebruikers. Het vinden van een balans tussen bruikbaarheid en beveiliging is dus iets wat elk bedrijf zelf moet bepalen.

Stop met beveiligingsvragen

Beveiligingsvragen worden niet langer beschouwd als een acceptabel authenticatiemechanisme. Het is ook vermeldenswaard dat het gebruik van een wachtwoord in combinatie met een beveiligingsvraag niet gelijk staat aan MFA, omdat de factor in beide gevallen hetzelfde is – iets wat u weet.

Er zijn twee soorten beveiligingsvragen – door de gebruiker gedefinieerd en door het systeem gedefinieerd, en beide zijn gemakkelijk te compromitteren. Laten we eens kijken naar veelvoorkomende door de gebruiker gedefinieerde beveiligingsvragen en waarom ze slecht zijn:

Natuurlijk kunt u meer ingewikkelde vragen bedenken, zoals ‘Hoe heet een universiteit waar u zich voor heeft aangemeld, maar waar u niet naartoe bent gegaan?’ of ‘Wat is de achternaam van uw wiskundeleraar in de 7e klas?’ Maar bent u er zeker van dat alle gebruikers die zich nog goed herinneren? Een oplossing hiervoor is om een lijst met vragen te geven waaruit gekozen kan worden, maar toch is er geen garantie dat de antwoorden niet voorspeld kunnen worden.

In 2015 bevestigde onderzoek van Google dat beveiligingsvragen óf veilig zijn, óf gemakkelijk te onthouden, maar nooit beide. Terwijl 40% van de gebruikers de antwoorden op hun beveiligingsvraag niet kon herinneren, gaf 37% bewust valse antwoorden, in een poging ze moeilijker te maken om te raden, maar bereikte het tegenovergestelde.

Wat betreft door het systeem gedefinieerde vragen, deze zijn gebaseerd op informatie die al in het systeem is vastgelegd, zoals de naam, geboortedatum of adres van de gebruiker. De laatste kan echter ook worden ontdekt via sociale media of datalekken op het dark web.

Update uw frameworks

Het implementeren van een veilige sessiemanagementmodule is behoorlijk uitdagend, omdat het authenticatie, HTTP-verkeer van gebruikers en toegangscontroles die door de webapplicatie worden afgedwongen, combineert. Daarom wordt aanbevolen om ingebouwde sessiemanagementfuncties en implementatiehandleidingen van bekende frameworks te gebruiken in plaats van deze zelf te coderen.

Tegelijkertijd kunnen zelfs breed geadopteerde en goed geteste frameworks kwetsbaarheden bevatten. Zorg er dus voor dat u de nieuwste versies van frameworks gebruikt met fixes voor bekende kwetsbaarheden. Verander bovendien de standaardconfiguratie om de beveiliging van uw app te verbeteren.

Genereer veilige sessie-ID's

De standaard sessie-ID naam kan de technologieën en programmeertalen onthullen die door de webapplicatie worden gebruikt. Bijvoorbeeld, PHPSESSID duidt op PHP, JSESSIONID wordt gegenereerd door J2EE, terwijl CFID & CFTOKEN suggereert dat de app is gebouwd met ColdFusion. Daarom moet de standaardnaam worden gewijzigd in iets generieks en niet te beschrijvends.

De lengte van de sessie-ID is van belang. Net als wachtwoorden moet deze lang genoeg zijn om geautomatiseerde aanvallen te voorkomen; OWASP raadt minimaal 128 bits aan; dit aantal is echter niet rigide en andere implementatiedetails moeten worden meegenomen.

De sessie-ID moet ook een effectieve entropie hebben. Met andere woorden, deze moet willekeurig en onvoorspelbaar zijn om statistische analysetechnieken te weerstaan. Dit kan worden bereikt met een betrouwbare CSPRNG (Cryptographically Secure Pseudorandom Number Generator).

De sessieobjecten en -eigenschappen, zoals het IP-adres van de gebruiker, e-mail, toegangsrechten of laatste login, moeten op de server worden opgeslagen in een beschermde sessiemanagementdatabase of repository.

Als laatste, maar zeker niet onbelangrijkste, moet de sessie-ID uniek zijn, wat betekent dat een huidige sessie geen gedupliceerde ID’s mag bevatten.

Kies het juiste mechanisme voor het uitwisselen van sessie-ID's

De webapp en de gebruiker hebben een bepaald mechanisme nodig om de sessie-ID te delen en uit te wisselen. Er zijn verschillende manieren om dit te doen – met cookies, URL-parameters, URL-argumenten bij GET-verzoeken of body-argumenten bij POST-verzoeken.

Bij het kiezen van een geschikt mechanisme voor het uitwisselen van sessie-ID’s, controleer of het de definitie van geavanceerde token-eigenschappen toestaat, zoals de vervaldatum en -tijd van de token, en gedetailleerde gebruiksbeleidsregels. HTTP-cookies zijn enkele van de meest gebruikte mechanismen voor het uitwisselen van sessie-ID’s omdat ze dergelijke mogelijkheden en meer bieden.

URL-parameters daarentegen worden beschouwd als een verouderd mechanisme voor het uitwisselen van sessie-ID’s, omdat ze de sessie-ID in de URL kunnen onthullen en hackers sessiefixatieaanvallen of andere ID-manipulaties kunnen uitvoeren.

Een ander punt om te overwegen is dat, hoewel de app standaard cookies gebruikt, deze nog steeds andere uitwisselingsmechanismen kan accepteren of kan overschakelen van cookies naar URL-parameters onder bepaalde omstandigheden. Daarom is rigoureus testen vereist om te bepalen hoe de app sessie-ID’s in verschillende scenario’s verwerkt en beheert, en om ervoor te zorgen dat deze uitsluitend op cookies vertrouwt.

Implementeer controls tegen afluisteren

Sessie-ID’s kunnen worden onderschept of gestolen door afluisteren op het netwerkverkeer. Om dit te voorkomen, moeten webapps transportlaagbeveiliging implementeren.

Transport Layer Security (TLS) is een van de modernste protocollen voor het versleutelen van communicatie tussen een webapplicatie en een server.

Natuurlijk moeten webontwikkelaars de nieuwste TLS-versie gebruiken, omdat deze sneller en minder kwetsbaar is dan zijn voorgangers; op het moment van schrijven is dit TLS 1.3.

TLS moet worden toegepast op alle pagina’s, ongeacht hun gevoeligheid. Anders biedt u een achterdeur voor kwaadwillenden om sessietokens te onderscheppen of kwaadaardige JavaScript-code te injecteren om andere aanvallen uit te voeren. Om dezelfde reden mag er geen menging zijn van TLS- en niet-TLS-content. Pagina’s die via TLS beschikbaar zijn, mogen geen JavaScript- of CSS-bestanden bevatten die via onveilige HTTP worden geladen.

Hoewel TLS de gegevens tijdens het transport beschermt, beschermt het niet de gegevens die het systeem hebben bereikt, zoals gegevens die zijn opgeslagen in de cache van de browser van de gebruiker.

Vernieuw sessie-ID na privilegewijziging

Het is essentieel om ervoor te zorgen dat uw webapplicatie geen eerder toegewezen token gebruikt wanneer het privilegelevel van de gebruiker verandert. Wanneer de gebruiker bijvoorbeeld overschakelt van een reguliere gebruiker naar een beheerder of superuser, moet de app oude sessie-ID’s negeren en een actuele genereren.

OWASP raadt ook aan om een andere sessie-ID toe te wijzen wanneer de gebruiker overschakelt van een anonieme bezoeker naar een geauthenticeerde. Dit laatste helpt het risico van het koppelen van de gebruikerssessie tussen de twee staten te elimineren. Het regenereren van de sessie-ID is cruciaal om sessiefixatieaanvallen te voorkomen.

Stel timeouts voor sessieverloop in

Time-outs voor sessievervallen zijn nuttig omdat ze de tijd beperken die een kwaadwillende actor heeft om de sessie te kapen. Hoe korter de sessieduur, hoe beter. Daarom bieden zeer gevoelige apps slechts 2-5 minuten voordat de gebruiker opnieuw moet authenticeren.

Natuurlijk hangt het sessievervalsinterval af van de aard en de werkelijke gebruiksscenario’s van de app. Als we het over een kantoormedewerker hebben, heeft deze 8 uur actieve sessietijd nodig, mits al zijn taken verband houden met interactie met de app.

Er zijn verschillende soorten time-outs, zoals ‘idle’, ‘absolute’ en ‘renewal’. ‘Idle’ time-outs worden afgedwongen wanneer er na een bepaalde tijd geen nieuwe activiteit is. ‘Idle’ time-outs zijn bedoeld om de tijd te verkorten die een hacker nodig heeft om een geldige sessie-ID te raden. Aan de andere kant, als de sessie al gekaapt is, kan de aanvaller periodiek enige activiteit creëren om de sessie te verlengen.

‘Absolute’ time-outs stellen de maximale tijd in dat een sessie actief kan zijn en sluiten deze automatisch af bij het verlopen. Tijdens ‘renewal’ time-outs wordt er halverwege de huidige sessie een nieuwe sessie-ID gegenereerd, ongeacht de gebruikersactiviteit, en de vorige ID wordt ongeldig zodra de gebruiker een nieuw verzoek indient.

Zodra de sessielimiet is bereikt, moet de webtoepassing de sessie aan zowel de client- als de serverzijde ongeldig maken, zodat een aanvaller clientparameters voor tijdmeting, zoals het aantal minuten sinds de login, niet kan manipuleren.

Sessie-anomalieën detecteren en bewaken

Webtoepassingen moeten ingebouwde mogelijkheden voor anomaliedetectie hebben om gebruikers te waarschuwen voor ongebruikelijk gedrag of verdachte sessies te beëindigen. Hier zijn zaken die duiden op een mogelijke inbraak:

• verschillende sessie-ID’s worden sequentieel geprobeerd vanaf hetzelfde IP-adres
• een bestaande cookie wordt verwijderd of gewijzigd
• een nieuwe cookie wordt toegevoegd
• de sessie-ID van een andere gebruiker wordt hergebruikt
• de locatie van de gebruiker verandert halverwege een sessie

Webtoepassingen moeten sessie-informatie loggen gedurende de gehele levenscyclus, van creatie en vernieuwing tot vernietiging van de sessie-ID. Gebeurtenissen zoals login en logout, mislukte loginpogingen, gelijktijdige logins, privilege-wijzigingen en transacties met hoge impact moeten ook worden gelogd. De sessie-ID zelf moet worden gelogd als een ‘salted hash’.

Wat betreft de functionaliteit voor de gebruiker, moeten gebruikers details kunnen bekijken over actieve sessies, verbonden apparaten en IP-adressen. Ze moeten meldingen ontvangen over gelijktijdige logins en de mogelijkheid hebben om sessies op afstand op alle apparaten te beëindigen.

Ga voor wachtwoordloos

Als er zoveel problemen zijn met wachtwoorden, waarom ze dan toch gebruiken? Veel bedrijven hebben wachtwoordloze authenticatie al ingevoerd of zijn van plan dit te doen. Volgens Bitwarden’s enquête uit 2022, gelooft 41% van de 800 IT-beslissers dat wachtwoordloze authenticatie de beveiliging verbetert, terwijl de rest wijst op het effect ervan op het verhogen van de productiviteit op de werkplek, een betere gebruikerservaring en verminderde helpdeskondersteuning.

Bovendien, als uw web-app verbinding maakt met een externe applicatie, wilt u niet dat de laatste de inloggegevens van gebruikers opslaat, omdat dit de kans op een datalek vergroot en u geen controle heeft over de beveiliging van de externe app. Hier is het gebruik van wachtwoordloze authenticatieprotocollen de enige optie.

Hier zijn enkele van de bekendste authenticatieprotocollen die geen wachtwoord vereisen.

• OAuth 2.0 – een open-source autorisatieframework dat een externe app in staat stelt beperkte toegang te krijgen tot een HTTP-service. In plaats van te vertrouwen op de inloggegevens van de gebruiker, krijgt de externe app een speciaal toegangstoken toegekend. OAuth 2.0 wordt gebruikt door grote namen zoals Meta, Google, Twitter en Microsoft.

• OpenID – een open-source, gedecentraliseerde technologie die het mogelijk maakt om met één account toegang te krijgen tot meerdere websites. In feite deelt u uw inloggegevens met één vertrouwde identiteitsprovider en logt u vervolgens in met deze identiteitsprovider zonder uw werkelijke inloggegevens prijs te geven. Meer dan 50.000 websites accepteren OpenID voor logins.

• SAML – Security Assertion Markup Language. Net als OpenID maakt SAML toegang tot meerdere web-apps mogelijk met één set inloggegevens. Het verschil is dat het XML-gebaseerd is, meer flexibiliteit biedt en beter geschikt is voor bedrijfsomgevingen.

• FIDO – staat voor Fast Identity Online. De FIDO-protocollen zijn gebaseerd op technieken voor publieke sleutelcryptografie. Bij registratie op een website genereert het apparaat van de gebruiker een sleutelpaar, waarbij de privésleutel wordt bewaard en de publieke sleutel wordt geregistreerd bij de online service. Om te authenticeren, moet de gebruiker het bezit van de privésleutel bewijzen door deze lokaal op hun apparaat te ontgrendelen met een pincode, door in een microfoon te spreken, een tweede-factor apparaat in te voegen, een vinger te scannen, enz.

Investeer in Penetration Testing

Penetration testing is een type testen dat een hackeraanval simuleert in een gecontroleerde omgeving. Penetration testers gebruiken een combinatie van beveiligingstools zoals kwetsbaarheidsscanners en handmatige technieken die door echte aanvallers worden gebruikt. Dit maakt penetration testing fundamenteel voor het verbeteren van de beveiligingshouding van een bedrijf.

Penetration testing is een onmisbaar onderdeel van compliancevoorschriften zoals HIPAA, SOC 2 of PCI-DSS, wat de effectiviteit ervan bevestigt bij het ontdekken van beveiligingsgaten en deze tijdig dichten.

Wij bij QAwerk helpen startups en gevestigde bedrijven bij het grondig testen van hun authenticatiemodules, het blootleggen van potentiële bedreigingen en het vinden van effectieve manieren om die kwetsbaarheden te patchen. Onze checklist voor penetration testing omvat alle genoemde punten en meer, afhankelijk van de technische bijzonderheden van uw product.

Naast een dynamische analyse van uw app, kunnen we ook de broncode onderzoeken vóór een grote release of een nieuwe productlancering, zodat u met een gerust hart nieuwe functionaliteiten aan consumenten kunt leveren. Als u meer wilt weten over hoe we uw software toekomstbestendig kunnen maken tegen hackers en hoe ons penetration testing proces eruitziet, neem dan gerust contact met ons op per e-mail. Wij bieden gratis, vrijblijvende consultaties om te zien of we de juiste keuze voor u zijn.

Samenvattend

Gebroken authenticatie behoort tot de top tien van webkwetsbaarheden volgens OWASP. Hoewel identificatie- en authenticatiefouten de afgelopen jaren zijn afgenomen dankzij gestandaardiseerde frameworks, vormen ze nog steeds een aanzienlijk risico en worden ze dagelijks uitgebuit door kwaadwillenden.

Uw app afstemmen op de beste beveiligingspraktijken voor credential- en sessiebeheer, werknemers voorlichten over social engineering en online hygiëne, en regelmatige beveiligingsaudits laten uitvoeren door een gekwalificeerde partij, bespaart u datalekken en de bijbehorende gevolgen.

Verbeter nu de beveiliging van uw web-app: de ultieme cheat sheet voor gebroken authenticatie

Voer uw zakelijke e-mailadres in

PDF downloaden