Webapplicatiebeveiliging bestaat uit een groot aantal beveiligingscontroles die ervoor zorgen dat een webapplicatie:
- Functioneert zoals verwacht.
- Kan niet worden uitgebuit om buiten de grenzen te opereren.
- Kan geen bewerkingen starten die niet mogen worden uitgevoerd.
Webapplicaties zijn alomtegenwoordig geworden na de uitbreiding van Web 2.0, waarbij sociale mediaplatforms, e-commercewebsites en e-mailclients de internetruimte de afgelopen jaren hebben verzadigd.
Naarmate de applicaties nog gevoeligere en uitgebreidere gegevens verbruiken en opslaan, worden ze een steeds aantrekkelijker doelwit voor aanvallers.
Algemene aanvalsmethoden
De drie meest voorkomende kwetsbaarheden op dit gebied zijn injecties (SQL, externe code), cryptografische fouten (voorheen blootstelling aan gevoelige gegevens) en verbroken toegangscontrole (BAC). Vandaag zullen we ons concentreren op injecties en verbroken toegangscontrole.
Injecties
SQL is de meest gebruikte databasesoftware en host een overvloed aan betalingsgegevens, PII-gegevens en interne bedrijfsdocumenten.
Een SQL-injectie is een aanval waarbij kwaadaardige SQL-code wordt gebruikt voor manipulatie van de backend-database om toegang te krijgen tot informatie die niet bedoeld was om te worden weergegeven.
Het uitgangspunt hiervoor is een commando zoals hieronder:
Hierdoor worden ALLE rijen uit de tabel “Gebruikers” geretourneerd, omdat OR 1=1 altijd TRUE is. Als we hiermee verder gaan, zal deze methode ook wachtwoorden retourneren als die er zijn.
Stel je voor dat een aanval als deze wordt uitgevoerd tegen een groot sociale-mediabedrijf of een groot e-commercebedrijf, en je kunt beginnen te zien hoeveel gevoelige gegevens met slechts één commando kunnen worden opgehaald.
Kapotte toegangscontrole
Broken Access Control (BAC) is in de OWASP-top tien gestegen van de vijfde plaats naar de meest voorkomende beveiligingsrisico’s voor webapplicaties. De 34 Common Weakness Enumerations (CWE’s) die zijn toegewezen aan Broken Access Control kwamen vaker voor in applicaties dan welke andere categorie dan ook tijdens de recente tests van OWASP.
De meest voorkomende typen BAC zijn verticale en horizontale privilege-escalatie. Verticale escalatie van bevoegdheden vindt plaats wanneer een gebruiker dat kan verheffen hun privileges en het uitvoeren van acties, waartoe zij geen toegang zouden mogen hebben.
De CVE-2019-0211, een Apache Local Privilege-escalatie. Deze kritieke kwetsbaarheid uit 2019 trof Apache HTTP-servers die op Unix-systemen draaien, vooral die welke gebruik maken van de mod_prefork-, mod_worker- en mod_event-bibliotheken.
Dit gaf aanvallers de mogelijkheid om scripts zonder privileges uit te voeren, wat mogelijk leidde tot root-toegang en gedeelde hostingdiensten in gevaar bracht. Het misbruiken van deze fout vereist manipulatie van gebieden met gedeeld geheugen binnen de werkprocessen van Apache, wat moet worden gedaan voordat Apache op een sierlijke herstart kan beginnen.
Hieronder ziet u een screenshot van de POC-code. Zoals u kunt zien, is in dit opzicht een bepaald niveau van technische vaardigheid vereist, maar verticale escalatie van bevoegdheden kan net zo gemakkelijk plaatsvinden wanneer de machtigingen van een gebruiker te tolerant zijn, of niet worden ingetrokken wanneer deze een bedrijf verlaat.
Dit brengt ons terug bij het principe van de minste privileges, een alomtegenwoordige term die overal in de IT-wereld voorkomt en die nu steeds gebruikelijker wordt naarmate we beseffen hoe cruciaal webapplicaties zijn geworden.
Bij horizontale privilege-escalatie krijgt een gebruiker toegang tot gegevens waartoe hij geen toegang zou moeten hebben, maar die gegevens worden op hetzelfde niveau bewaard als zijn eigen machtigingen. Dit is te zien wanneer de ene standaardgebruiker toegang heeft tot de gegevens van een andere standaardgebruiker. Hoewel dit niet mag worden toegestaan, stijgen de privileges niet verticaal, maar verspreiden ze zich horizontaal. Dit wordt soms als gevaarlijker gezien, omdat het kan gebeuren zonder dat er waarschuwingen op beveiligingssystemen worden gegenereerd.
Nu BAC de afgelopen jaren steeds prominenter aanwezig is, is het belangrijk om het volgende te onthouden:
- Het uitsluitend afhankelijk zijn van verduistering is niet voldoende voor toegangscontrole.
- Als het niet de bedoeling is dat een bron toegankelijk is voor het publiek, moet deze standaard de toegang worden ontzegd.
- Ontwikkelaars moeten expliciet de toegestane toegang voor elke bron opgeven op codeniveau, waarbij toegangsweigering de standaardinstelling is.
Best Practices – Tussen de regels door lezen (van code!)
Om de veiligheid te behouden, moeten ontwikkelaars binnenkomende gegevens verifiëren, geparametriseerde queries implementeren bij interactie met databases en effectieve sessiebeheermethoden toepassen om gevoelige gegevens te beschermen. Een groot deel hiervan is afhankelijk van zowel de beveiliging van webbrowsers, maar ook van de back-endbeveiliging van de webservers die webinhoud leveren, wat leidt tot een scheiding van taken op het gebied van webbeveiliging.
Het grootste probleem dat zich hier voordoet, is dat hoewel Web Application Firewalls (WAF’s) deze risico’s kunnen beperken, een groot deel van de verantwoordelijkheid voor de veilige implementatie van webinhoud bij de ontwikkelaars terechtkomt die deze sites hebben samengesteld. Cyberbeveiliging kan vaak een bijzaak worden, waarbij functionaliteit de voorkeur krijgt.
Praktijkvoorbeeld – Invoervalidatie
Invoervalidatie is de eenvoudigste en meest effectieve manier om veilige codering te implementeren, in dit voorbeeld om SQL-injecties te voorkomen.
- Gebruikersinvoer: De gebruiker geeft invoer, bijvoorbeeld:
- Opschoning: de gebruikersinvoer wordt niet rechtstreeks in de SQL-query ingevoegd. Het wordt opgeschoond en behandeld als gegevens, niet als SQL-code.
- Queryuitvoering: De SQL-query wordt uitgevoerd met de gebruikersinvoer als parameter:
- Als zodanig komt de query de backend binnen, zoals hieronder:
In deze code is de (user_input,) een tupel die de invoer van de gebruiker bevat. Het databasestuurprogramma zorgt voor het ontsnappen en correct afhandelen van deze invoer. Het zorgt ervoor dat de invoer wordt behandeld als een gegevenswaarde en niet als uitvoerbare SQL-code.
Als de gebruikersinvoer schadelijke code bevat, zoals ‘105 of 1=1’, wordt deze niet als SQL uitgevoerd. In plaats daarvan wordt het behandeld als een waarde die moet worden vergeleken met de UserId in de database.
Het databasestuurprogramma zorgt automatisch voor het ontsnappen van de invoer, waardoor wordt voorkomen dat dit de structuur van de SQL-query beïnvloedt of beveiligingskwetsbaarheden introduceert.
Firewalls voor webapplicaties (WAF’s)
Een WAF werkt op laag 7 van het OSI-model en fungeert als een reverse proxy, waardoor het clientverkeer door de WAF gaat voordat het de backend-server binnengaat. De regels of het beleid op de WAF beschermen tegen de gedocumenteerde kwetsbaarheden die aanwezig zijn in deze backend-servers en filteren kwaadaardig verkeer eruit.
Er is een overvloed aan WAF’s op de markt, en deze kunnen allemaal een sterke verdediging bieden tegen de meer nieuwe aanvallen, en goed bijdragen aan een diepgaande verdedigingsaanpak. De praktijk van veilige codering is iets dat ervoor zorgt dat de basis van de webapplicatie veilig is veilig zijn en in de toekomst niet het slachtoffer zullen worden van complexere of nieuwere aanvallen.
WAF’s evolueren momenteel naar een combinatie van beveiligingsmodellen die gedragsanalysetechnologieën gebruiken om kwaadwillige bedreigingen te detecteren en de bedreigingen van meer geavanceerde ‘bots’ verder te beperken die zijn ingezet voor aanvallen met weinig inspanning op websites.
Het belangrijkste nadeel van het gebruik van een WAF, afgezien van de extra latentie en HTTP-overhead, is het feit dat een WAF kan worden omzeild door een 0-day exploit tegen een webapplicatie te gebruiken, waardoor veilige codering en correcte opschoning effectiever kunnen worden tegengegaan. het compenseren van alle webapplicatiebeveiliging naar een WAF. Het is belangrijk om te onthouden dat een WAF slechts een beveiligingslaag is en niet de hele oplossing.
Incidentrespons en herstel
Suggesties van SecurityHQ om aanvallen te beperken:
- Het inzetten van een WAF als eerste verdedigingslinie is van cruciaal belang om ervoor te zorgen dat bedrijven zich kunnen verdedigen tegen een groot aantal aanvallen.
- Zorg ervoor dat er up-to-date en sterke standaardalgoritmen en protocollen worden gebruikt, dit moet gepaard gaan met goed sleutelbeheer.
- Versleutel gegevens tijdens de overdracht met veilige protocollen zoals TLS met forward secrecy (FS)-cijfers en cijferprioritering door de server. Dwing versleuteling af met behulp van richtlijnen zoals HTTP Strict Transport Security (HSTS).
- Schakel botbeheerstrategieën op websites in en zorg voor een gedocumenteerd incidentresponsplan.
- Zorg ervoor dat er veilige ontwikkelingspraktijken zijn, met een gedocumenteerd proces voor het testen van nieuwe functies op webapplicaties en zorg ervoor dat invoervalidatie wordt geïmplementeerd.
- Dit moet gepaard gaan met het waarborgen van het beginsel van de minste privileges.
- Test regelmatig op kwetsbaarheden, met Vulnerability Management en Managed Defense met IBM-tooling, en houd de versies van componenten bij.
- Gebruik een rode applicatietest om kwetsbaarheden te ontdekken die scanners niet kunnen vinden.
- Zorg ervoor dat ontwikkelaars regelmatig worden getraind om op de hoogte te blijven van de nieuwste beveiligingstrends en opkomende bedreigingen.
Voor meer informatie over deze bedreigingen kunt u hier contact opnemen met een expert. Of als u een beveiligingsincident vermoedt, kunt u hier een incident melden.
Opmerking: dit artikel is vakkundig geschreven door Tim Chambers, Senior Cyber Security Manager bij SecurityHQ
