1 Introductie
De security van webapplicaties is de laatste jaren alsmaar belangrijker geworden
doordat er steeds meer aanvallen worden uitgevoerd. Een groot deel van deze
aanvallen kan worden voorkomen door gebruik te maken van veilige ontwikkelmethodes.
Ondanks meerdere pogingen om ontwikkelaars bewust te maken van
deze risicos door deze te promoten[9] worden veel exploits constant misbruikt.
2 Meest voorkomende aanvallen
Ondanks dat er heel veel verschillende aanvallen worden uitgevoerd, vallen de
meeste aanvallen in een van de volgende categorien [11]:
1. Injection
2. Niet werkende Authentication en Session Management
3. Cross-Site Scripting (XSS)
4. Onbeveiligde directe Object verwijzingen
5. Security Misconguratie
6. Gevoelige Data Blootstelling
7. Ontbrekende Function Level Toegangscontrole
8. Cross-Site Request Forgery (CSRF)
9. Gebruik maken van kwetsbare Componenten
10. Ongevalideerde Redirects en Forwards
3 Wat houden deze aanvallen in?
Al deze verschillende aanvallen worden op verschillende manieren uitgevoerd.
Het is belangrijk om te begrijpen hoe deze aanvallen worden uitgevoerd om
deze aanvallen te kunnen afweren.
Daarnaast is er geen simpele manier om alle verschillende aanvallen in een
klap te voorkomen. Voor elke verschillende aanval is er vaak een andere soort
verdediging nodig. Wel zijn er een aantal ontwikkelmethodes die ervoor zorgen
dat een web applicatie een stuk veiliger wordt en de kans op aanvallen verkleint
[3].
3.1 InjectionInjection, zoals SQL injection of OS injection1, vind plaats wanneer onbetrouwbare
data naar een interpreter wordt gestuurd als deel van een command of
query. Hiermee kan een aanvallen de interpreter onbedoelde commandos laten
uitvoeren of toegang geven tot onbevoegde data.
De bron van het probleem bij injection is onvoldoende input validatie. De
meeste krachtige oplossing is dan ook simpelweg betere input validatie uitvoeren.
Dit houdt niet alleen het valideren van input in tekstboxen in, maar aan alle
input die niet vanuit de applicatie zelf komt. Hierbij kan worden gedacht aan
geuploade bestanden, GET en POST requests, en alle andere vormen van input
waarmee een aanvaller kwaad zou kunnen [4].
3.1.1 Identificeren
Om zwakke plekken, waar SQL injection kan worden uitgevoerd, in een web
applicatie te identiceren zijn er meerdere mogelijkheden [6]:
- SAFELI Static Analyses framework om SQL Injection kwetsbaarheden te detecteren
- Geautomatiseerde prepared statement generatie Een algoritme gebruiken
om prepared statements te genereren
- Automatische test generatie Genereren van automatische testen die omgaat
met SQL queries om zo kwetsbaarheden op te sporen
- Mix Eerst de kwetsbare punten van input opsporen, en op basis daarvan automatische
tests laten genereren die deze punten gebruikt
- Speciek ingestelde toegang De toegang tot de database gebeurt onder toezicht
door een ingebouwde toegangscontrole
3.2 Niet werkende Authenticatie en Sessie Management
Functies in applicaties gerelateerd aan authenticatie en sessie management worden
vaak niet correct geimplementeerd, waardoor aanvallers wachtwoorden, sleutels,
sessie tokens, of op andere manieren gebruikers hun identiteit overnemen.
Bij een niet werkende Authenticatie en Sessie Management moet vooral worden
gelet op of applicaties niet per ongeluk gebruikers informatie vrijgeven. Dit
kan bijvoorbeeld gebeuren doordat een session ID in de URL staat of dat een
sessie geen correct ingestelde time-out heeft. Dit kan voorkomen worden door
gebruik te maken van de richtlijnen beschreven in OWASP's Application Security
Verication Standard [8].
3.2.1 Identificeren
Om te controleren of er geen zwakke plekken bestaan met dit probleem kan op
de volgende punten gecontroleerd worden:
1. Staan Session IDs in de URL?
2. Verloopt een sessie na een bepaalde periode?
3.3 Cross-Site Scripting(XSS)
XSS fouten komen voor als een applicatie onbetrouwbare data naar een web
browser stuurt zonder fatsoenlijke validatie en escaping uit te voeren. XSS laat
aanvallers scripts in het slachtoer zijn browser uitvoeren waarmee user sessions
kunnen worden gehijacked, websites kunnen worden defaced, of de gebruiker
naar een kwaadaardige website kan worden geredirect.
De kern van dit probleem zit net als bij injection in onvoldoende input validatie.
Meestal word Cross-Site Scripting uitgevoerd door een stukje JavaScript
te plaatsen op een website die de invoer letterlijk overneemt en op de webpagina
plaats. Hierdoor kan een aanvaller in principe zelf bepalen wat er op een website
komt te staan [10]. Door alle input te valideren en eventueel te escapen kunnen
de meeste aanvallen eenvoudig worden afgewend.
Als een aanvaller toch een sessie heeft weten te hijacken door middel van XSS,
kan door gebruik te maken van een goeie Authenticatie toch de aanval worden
afgeslagen. Hierbij zou de Authenticatie bijvoorbeeld kunnen kijken naar het
geassocieerde IP-adres van een sessie en deze vergelijken met het IP-adres van
de aanvaller.
3.3.1 Identificeren
Kwetsbaarheden die te maken hebben met XSS zijn te vinden door te zoeken
naar zwakke plekken waar gebruikers waardes in kunnen vullen welke op het
scherm getoond worden. Als deze waardes niet worden geescaped, dan wordt
de kwetsbaarheid snel duidelijk. Een waarde die gebruikt kan worden om dit te
controleren kan iets simpels zijn als:
<script>alert('Vulnerable to XSS');</script>
Als dit wordt verstuurt, en daarna wordt er een popup getoond met \Vul-
nerable to XSS" dan is er een kwetsbaarheid gevonden.
3.4 Ongebeveiligde directe Object verwijzingen
Een directe object verwijzingen ontstaat als een ontwikkelaar een verwijzingen
naar intern object, zoals een bestand, directory, of database sleutel blootstelt.
Zonder toegangscontrole of andere beveiliging, kunnen aanvallers deze verwijzingen
manipuleren om toegang te krijgen tot onbevoegde data.
Dit wordt veroorzaakt doordat iedereen toegang heeft tot een verwijzingen
naar een object. Daarom is dit vrij gemakkelijk op te lossen door de gebruiker
nooit direct toegang te geven tot een object. In plaats van bijvoorbeeld een
dropdown list te gebruiken met als waarden de keys in de database, kan simpelweg
een nummer worden gebruikt van 1 t/m 6 om aan te geven wat de gebruiker
geselecteerd heeft [11].
3.4.1 Identificeren
Tools kunnen niet gebruikt worden om te identiceren wat hier de zwakheden
in zijn, dit komt doordat tools niet begrijpen wat er beveiligd moet zijn en wat
niet. Om dit te identiceren zal er dus een code review moeten worden gedaan.
3.5 Security Misconguratie
Een goede beveiliging vereist een veilige conguratie gedenieerd en gedeployed
voor de applicatie, frameworks, applicatie server, web server, database server,
en platform. Al deze instellingen zouden gedenieerd, geimplementeerd en onderhouden
moeten worden omdat veel hiervan niet worden geleverd met een
veilige standaard. Dit omvat ook het up to date houden van alle software.
Security misconguratie gebeurt vaak als de standaard conguratie niet
wordt aangepast. Hierdoor komen standaard instellingen zoals het weergeven
van errors, directory listing, en wachtwoorden van admin paginas op de server
te staan, wat ervoor zorgt dat aanvallers vrij spel krijgen. Om dit te voorkomen
moet na de installatie van nieuwe servers en/of andere software alle instelling
worden gecontroleerd of deze op een veilige manier zijn ingesteld. Deze veilige
manier van instellen behoort gedocumenteerd te zijn zodat dit snel en gemakkelijk
kan gebeuren.
3.5.1 Identificeren
Om te identificeren of de security goed is ingesteld, kan gebruik gemaakt worden
van de volgende checklist [11]:
1. Is er een proces aanwezig om alle software up-to-date te houden?
2. Zijn alle onnodigheden uitgezet? Denk aan poorten, services, accounts en
privileges
3. Zijn alle standaard wachtwoorden aangepast of uitgezet?
4. Is error handling ingesteld op zon manier dat stack traces nooit zichtbaar
zijn voor de buitenwereld?
5. Zijn de security settings van het development framework begrepen en goed
ingesteld?
3.6 Gevoelige Data Blootstelling
Veel webapplicaties beschermen gevoelige data niet op de juiste manier. Aanvallers
kunnen deze data stelen of aanpassen om identiteitsdiefstal, creditcard
fraude, en andere misdaded te plegen. Deze gevoelige data verdient extra beveiliging
zoals encryptie en speciale voorzorgsmaatregelen waneer deze worden
uitgewisseld met de browser.
Er zijn een aantal manieren om dit tegen te gaan. Er kan gebruik gemaakt
worden van Cryptographic Design Patterns zoals beschreven in Tropyc[1].
Daarnaast is het verstandig om gevoelige data zo kort mogelijk op te slaan,
en als deze eventueel wordt opgeslagen, deze encrypted opslaan met een sterk
encryptie algoritme (wachtwoorden kunnen bijvoorbeeld opgeslagen worden met
bcrypt). Het is aangeraden om [7]:
- Niet je eigen algoritme te schrijven: Cryptographische algoritmes zijn uitzonderlijk
lastig te schrijven, hierdoor is het zeer onverstandig om er zelf
een te schrijven
- Ongeencrypte data dichtbij het algoritme houden: Haal pas data op als
je klaar bent om er gebruik van te maken en sla het in zo min mogelijk
variabelen op
- Gebruik het correct algoritme en key grootte: Het is belangrijk dat het
juiste algoritme wordt gebruikt met een key grootte die voldoende beveiliging
biedt
- Beveilig je encryptie keys: Om encrypted data veilig te houden moet de sleutel
geheim blijven, deze moet daarom goed opgeborgen zijn zodat aanvallers
hier geen toegang tot kunnen krijgen
3.6.1 Identificeren
Het identiceren van gevoelige data is vrij gemakkelijk, data zoals credit cards,
wachtwoorden, en andere persoonlijke details moeten encrypted opgeslagen zijn
en de private sleutel moet niet toegankelijk zijn voor de buitenwereld.
3.7 Ontbrekende Function Level Toegangscontrole
Vrijwel alle webapplicaties verieren function level toegangscontrole rechten
voordat die functionaliteit zichtbaar wordt in de UI. Maar applicaties moeten
dezelfde toegangscontrole checks op de server uitvoeren zodra een functie
wordt benaderd. Als verzoeken niet geverieerd worden, hebben aanvallers de
mogelijkheid om verzoeken te vervalsen om zo toegang te krijgen tot onbevoegde
functionaliteit.
Als functies niet controleren of een gebruiker het juiste toegangsniveau heeft
voor een bepaalde functie, kan dat tot gevolg hebben dat bepaalde functies
uitgevoerd kunnen worden door onbevoegde personen. Een aanvaller kan hier
misbruik van maken door deze functies uit te voeren.
Dit kan verholpen worden door in elke functie te controleren of een gebruiker
wel het juiste toegangsniveau heeft. Daarnaast kan er in de UI voor worden
gezorgd dat als een persoon niet het juiste toegangsniveau heeft, dat bepaalde
delen in het UI niet worden geladen.
3.7.1 Identificeren
Zwakke plekken kunnen gemakkelijk geidenticeerd worden door de volgende
checklist uit te voeren voor elke applicatie functie:
1. Laat de UI navigatie zien naar functies waar de gebruiker geen toegang
tot heeft?
2. Zijn de juiste authenticatie en autorisatie gecontroleerd?
3. Zijn de checks uitgevoerd op de server zonder informatie vanuit de aanvaller?
3.8 Cross-Site Request Forgery(CSRF)
Een CSRF aanval forceert een ingelogd slachtoer zijn browser om een vervalst
HTTP verzoek te verzenden, deze bevat het slachtoer zijn sessie cookie en
eventueel andere automatisch toegevoegde authenticatie informatie, naar een
kwetsbare webapplicatie. Dit stelt de aanvaller in staat om het slachtoer zijn
browser te forceren verzoeken te genereren waarvan de kwetsbare applicatie
denkt dat deze legitiem zijn.
Als CSRF tokens onveilig worden verstuurd of vaak worden herbruikt voor
meerdere acties binnen een applicatie, en deze worden gestolen, dan kan een
aanvaller eenvoudig acties uitvoeren met de token van iemand anders. Hiermee
kan dus in principe een andere gebruiker worden geimiteerd. Een oplossing
hiervoor is om voor belangrijke transacties een unieke, eenmalige CSRF token
te gebruiken, en deze te verzenden via een GET request in de URL, of op een
nog veiligere manier, door deze in een hidden eld te stoppen en versturen door
middel van een POST request [2].
3.8.1 Identificeren
Om de identiceren of een web applicatie kwetsbaar is voor CSRF, moet worden
gecontroleerd of elke form en link een nieuwe CSRF token gebruikt.
3.9 Gebruik maken van kwetsbare Componenten
Kwetsbare componenten, zoals libraries, frameworks, en ander software modules
draaien bijna altijd met alle privileges. Dus als deze worden geexploiteerd
kunnen ze serieuze data verliezen veroorzaken of zelf een server overname. Applicaties
die deze kwetsbare componenten gebruiken kunnen ervoor zorgen dat
de verdediging tegen deze aanvallen wordt ondermijnt.
Het veiligst is om geen componenten te gebruiken die je zelf niet geschreven
hebt, dit is alleen vaak onrealistisch. Daarom is bij het gebruik van externe
componenten het van groot belang deze up-to-date te houden zodat het risico
op aanvallen het kleinst blijft.
3.9.1 Identificeren
Kwetsbare componenten identificeren is gemakkelijk omdat het meestal vrij duidelijk
welke componenten niet zelf geschreven zijn.
3.10 Ongevalideerde Redirects en Forwards
In veel webapplicaties worden redirects en forwards uitgevoerd, waarbij onbetrouwbare
data wordt gebruikt om de bestemming te bepalen. Dit kan worden
voorkomen door geen redirects en forwards uit te voeren, en, indien dit toch gedaan
wordt, geen gebruik te maken van user input [11]. Er kan hierbij gebruik
gemaakt worden van het Directed Session pattern. Dit houdt in dat gebruikers
niet naar andere paginas kunnen springen, maar dat het systeem altijd op een
URL blijft en de volgorde van webpaginas regelt en garandeerd [5].
3.10.1 Identificeren
Het identiceren van ongevalideerde redirects en forwards kan worden gedaan
door te controleren welke redirects en forwards gebruik maken van input van de
gebruiker en of deze input wordt gevalideerd.
4 Conclusie
Er zijn vele vormen van aanvallen die uitgevoerd worden op webapplicaties. Er
is geen universele oplossing voor deze aanvallen, maar door zoveel mogelijk te
denken aan security tijdens de ontwikkeling, en security patterns te implementeren,
kan de kans op een succesvolle aanval verkleint worden.
Referenties
[1] A Braga, C Rubira, and Ricardo Dahab. Tropyc: A pattern language for
cryptographic software. 1999.
[2] Cyrill Brunschwiler. Cross site request forgery. 2008.
[3] Asish Kumar Dalai and Sanjay Kumar Jena. Evaluation of web application
security risks and secure design patterns. In Proceedings of the 2011
International Conference on Communication, Computing Security, 2011.
[4] WG Halfond, Jeremy Viegas, and Alessandro Orso. A classication of sqlinjection
attacks and countermeasures. In Proceedings of the IEEE Inter-
national Symposium on Secure Software Engineering, Arlington, VA, USA,
pages 13{15, 2006.
[5] Darrell M Kienzle, Matthew C Elder, David Tyree, and James Edwards-
Hewitt. Security patterns repository version 1.0. DARPA, Washington DC,
2002.
[6] Diallo Abdoulaye Kindy and AK Pathan. A survey on sql injection: Vulnerabilities,
attacks, and prevention techniques. In Consumer Electro-
nics (ISCE), 2011 IEEE 15th International Symposium on, pages 468{471.
IEEE, 2011.
[7] J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla,
and Anandha Murukan. Design guidelines for secure web applications,
6 2003.
[8] ASVS Project. OWASP.
[9] Webscarab Project. OWASP.
[10] Kevin Spett. Cross-site scripting. SPI Labs, 2005.
[11] Je Williams and Dave Wichers. The ten most critical web application
security risks, 2013.