Redactie: Gerben de la Rambelje
Auteur: Hannie van Kooten
Security heeft alles te maken met de beschikbaarheid, integriteit en vertrouwelijkheid van de gegevens en het systeem. Hoe reageert de applicatie op invoer en welke informatie geeft het prijs? Hoe veilig en vriendelijk is het voor de gebruiker? Kan een gebruiker bij gegevens van een ander komen? Krijg je foutmeldingen die ook stukken van de code bevatten? Kun je een systeem traag maken of platleggen door veel data of e-mails te genereren, zoals bij een DoS (Denial of Service) aanval? Hackers maken gebruik van foutmeldingen om het systeem steeds verder te leren kennen. Met dit in je achterhoofd kun je gaan testen op security.
Probeer nooit zaken uit als je geen toestemming hebt om dat te doen. En dus zeker niet op internet, want dat kan strafbaar zijn.
Hieronder staat een lijst om je op ideeën te brengen. Maak een security test en breidt deze uit. Noteer naast problemen ook wat er goed gaat. In de voorbeelden ga ik uit van een webapplicatie, maar met andere applicaties kunnen ook security testen worden gedaan. Onderzoek en experimenteer!
De login authenticiteitscheck
Veel applicaties maken gebruik van een login procedure voor authenticatie van de gebruiker.
Mogelijke scenario’s:
- Inloggen met juiste/foute username en password combinatie. Meldingen op het scherm?
- Raakt de user account geblokkeerd na x keer fout inloggen? En voor hoe lang?
- De sterkte van je password. Simpele passwords zijn heel eenvoudig te hacken, te ingewikkelde passwords niet te onthouden.
- Password gebruiken met (alleen maar) spaties of met diakritische tekens, de maximale lengte van het veld of juist zo kort en simpel mogelijk.
- Is er ‘remember me’ functionaliteit? Uitloggen en back toets in de browser?
- Denk ook aan settings in de browser, zoals het onthouden van een gebruikersnaam en/of password, het incognito venster. Het leegmaken van de cache van de browser of juist niet.
- Gebruik maken van een tweede tabblad in dezelfde browser, log uit op het ene en probeer verder te werken op het andere tabblad. Twee keer inloggen vanuit verschillende browsers.
- Hoe vaak moet je je password veranderen voordat je deze weer mag gebruiken?
- Kun je de vergeten password functionaliteit gebruiken om je oorspronkelijke password weer te gebruiken? Of om je account te deblokkeren?
- Kan je eenvoudig x keer op de ‘vergeten password’ button drukken en krijg je dan een nieuwe e-mail? Dan kan een hacker dat misschien gebruiken om je systeem plat te krijgen. Heeft het nieuwe password een verlooptermijn? Wat staat er in de e-mail? Hoe werkt het?
- Verloopt een password na een termijn? Hoe staat dat in verhouding tot het gebruik van de applicatie?
- Is er time-out functionaliteit? Een begin- en einddatum aan een gebruikersaccount?
- Is de gebruikersnaam gelijk aan het e-mailadres? Kan deze dan gewijzigd worden en werken koppelingen naar andere systemen dan nog?
- Gebruik de back button in je browser, na een time out, na uitloggen et cetera.
De Invoerveldentest
Een gebruiker kan alle mogelijke data in allerlei soorten invoervelden en zoekvelden kwijt. Naast allerlei diakritische tekens, ook andere data die een probleem kan veroorzaken in de applicatie en als deze opgeslagen wordt in de database dan is deze persistent geworden.
Mogelijke scenario’s:
- Simpele html code <h1>tekst</h1> – wordt de opmaak nu getoond in de pagina? Een eenvoudige manier om aan dit soort code te komen is view source te doen van een pagina in de applicatie (rechtermuis menu). Plak (een stuk van) de pagina in een invoerveld. En kijk of de opmaak aangepast wordt. Ververs vervolgens de pagina.
- Dit kan ook met scripting code. Kopieer van tag <script> tot en met </script> in een invoerveld. Of zoek op internet hoe je met javascript/html/… een button kan maken. Plak die code in je invoerveld. Dit heet XSS of cross site scripting. Zo kan bijvoorbeeld een button gemaakt worden met een gevaarlijke actie erachter, die opgaat in de structuur van de pagina.
- Zijn er pagina’s in de applicatie die wat anders zijn, bijvoorbeeld om je wachtwoord te resetten, dan zijn dat goede kandidaten om te testen. Het kunnen ook pagina’s zijn die met andere tooling gemaakt zijn.
Eenvoudige URL manipulatie
De tekst van de troonrede is ooit eerder uitgelekt omdat iemand in de URL het jaartal aangepast had en de nieuwe troonrede te zien kreeg, voordat deze vrijgegeven was.
Mogelijke scenario’s:
Iets soortgelijks kun je in de applicatie doen. Pas jaartallen en andere nummers of namen aan in de URL. Krijg je data te zien, meer of andere informatie? Een foutmelding?
- Gebruikers uit verschillende gebruikersgroepen, die elkaars data niet mogen zien. Verzamel URL’s van gebruiker A en log daarna in als gebruiker B en gebruik de URL’s van A. Probeer dit met gebruikers met meer en minder rechten, andere rollen, andere bedrijven etc.
- Als je de directory structuur van de applicatie weet, kun je zelf URL’s maken en controleren wat deze opleveren.
- Een URL met een vraagteken erin kun je gebruiken om andere data in te voeren. Bijvoorbeeld /Search?q= …. Probeer zaken uit als <script> etc. Wat zie je? Welke tekens zijn toegestaan? Wordt de zoekterm herhaald op de pagina en hoe? (Voorbeeld van op XSS kwetsbaarheden testen.)
Logging
Vaak komt het voor dat een applicatie log informatie beschikbaar heeft via de browser op een log pagina. Bijvoorbeeld via een ELMAH pagina. Deze pagina is bedoeld voor ontwikkelaars. Het gebeurt dat deze pagina aan de aandacht ontsnapt is om deze te beveiligen.
Mogelijke scenario’s:
- Zoek de URL van de log pagina op. Log uit en kopieer de URL in de browser.
- Vraag ontwikkelaars of er alternatieve URL’s zijn voor logging. Zijn er nog meer tools die ontwikkelaars gebruiken en via de browser informatie geven? Verzamel ze. Test ze uit.
Gebruik je fantasie, experimenteer en have fun!