CompTIA SY0-701: Applicatie- & Webbeveiliging — Studiegids
Onderdeel van de CompTIA Security+ SY0-701 — Studiegids. Oefen met geverifieerde antwoorden in het CompTIA-examencentrum, of doe getimede oefentests op ExamRoll.io.
Moderne applicaties bevinden zich op het snijvlak van bedrijfslogica, gevoelige data en niet-vertrouwde gebruikersinvoer. Omdat web- en mobiele front-ends worden blootgesteld aan het hele internet, vormen ze een van de grootste en meest consistent misbruikte aanvalsoppervlakken in elke onderneming. De verdediging ervan vereist gelaagde beveiligingsmaatregelen die beginnen bij de manier waarop code wordt geschreven en zich uitstrekken tot runtime-beveiliging, integriteitsverificatie en continu testen.
Injectieaanvallen
Injectie blijft de archetypische webkwetsbaarheid. Het treedt op wanneer een applicatie niet-vertrouwde invoer samenvoegt in een interpreter — een SQL-query, een shell-commando, een LDAP-filter, een XML-parser of een template-engine — zonder code en data correct te scheiden. Bij een SQL-injectie (SQLi) manipuleert een aanvaller een query zodat de database door de aanvaller gecontroleerde logica uitvoert. Een klassiek kwetsbaar patroon in PHP ziet er als volgt uit:
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
Het invoeren van admin' OR '1'='1 transformeert de query in een tautologie die elke rij retourneert. Meer geavanceerde varianten omvatten union-based extractie (' UNION SELECT credit_card FROM payments--), blinde booleaanse of op tijd gebaseerde inferentie (' AND SLEEP(5)--), en out-of-band exfiltratie via DNS-callbacks. De definitieve oplossing is het gebruik van geparameteriseerde queries of prepared statements, die de query-template en de parameters als afzonderlijke structuren naar de database sturen:
cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))
Command-injectie volgt hetzelfde patroon, maar richt zich op de shell van het besturingssysteem. Code zoals os.system("ping " + host) stelt een aanvaller in staat om 8.8.8.8; cat /etc/passwd in te voeren en willekeurige commando’s uit te voeren. De oplossing vereist het volledig vermijden van het aanroepen van de shell, het gebruik van API’s die argument-arrays accepteren (subprocess.run(["ping", host], shell=False)), en het toepassen van strikte validatie op basis van een allow-list op elke waarde die een shell moet bereiken.
Cross-Site Scripting en CSRF
Cross-site scripting (XSS) is de injectie van kwaadaardig script in pagina’s die door een vertrouwde applicatie worden gerenderd, waardoor de browser van het slachtoffer de code van de aanvaller uitvoert binnen de origin van de site. Gereflecteerde XSS kaatst payloads terug via een kwetsbare parameter; opgeslagen XSS bewaart de payload in de database en levert deze aan elke bezoeker; DOM-gebaseerde XSS vindt volledig plaats in client-side JavaScript dat niet-vertrouwde data wegschrijft naar innerHTML, document.write of vergelijkbare sinks. De gevolgen variëren van sessiekaping en keylogging tot volledige overname van accounts door geforceerde acties.
Cross-site request forgery (CSRF) is een afzonderlijke maar complementaire aanval. Het misbruikt het feit dat de browser automatisch cookies meestuurt om een geauthenticeerde gebruiker te verleiden een ongewenst verzoek in te dienen — bijvoorbeeld een verborgen formulier op een kwaadaardige site dat een POST-verzoek doet naar bank.com/transfer. Verdedigingsmechanismen omvatten synchronizer tokens (willekeurige, per sessie unieke waarden die in formulieren worden ingebed en server-side worden geverifieerd), het SameSite=Lax of SameSite=Strict cookie-attribuut, en het vereisen van herauthenticatie voor gevoelige acties. XSS en CSRF worden vaak door elkaar gehaald, maar XSS voert code uit in de browser van het slachtoffer, terwijl CSRF de browser slechts een verzoek laat versturen; een succesvolle XSS-aanval kan de meeste CSRF-verdedigingen omzeilen.
Secure Coding: Invoervalidatie versus Uitvoer-encoding
Twee maatregelen worden vaak met elkaar verward, maar ze lossen verschillende problemen op. Invoervalidatie zorgt ervoor dat data voldoet aan de verwachte structuur — lengte, type, tekenset, bereik, formaat — voordat de applicatie ermee aan de slag gaat. Dit moet op de server gebeuren, waarbij waar mogelijk gebruik wordt gemaakt van allow-lists (^[A-Za-z0-9_]{3,20}$ voor een gebruikersnaam). Client-side validatie met JavaScript is alleen een bruikbaarheidsfunctie; het kan worden omzeild met elke HTTP-proxy en mag nooit de beveiligingsgrens zijn.
Uitvoer-encoding zorgt ervoor dat data veilig wordt weergegeven in de context waarin het terechtkomt. Dezelfde string die perfect geldige invoer is, kan een andere behandeling vereisen afhankelijk van waar deze belandt: HTML body-context vereist HTML entity encoding (< → <), attribuutcontext vereist ‘quoted attribute encoding’, JavaScript-context vereist \xHH escaping, en URL’s vereisen percent-encoding. Een gebruikersnaam als O'Brien is legitieme invoer, maar moet worden geëncodeerd als O'Brien wanneer deze in HTML wordt geplaatst. Invoervalidatie kan uitvoer-encoding niet vervangen, en encoding kan validatie niet vervangen — ze pakken verschillende problemen aan op verschillende punten in de datalevenscyclus.
Aanvullende hardening omvat Content Security Policy (CSP)-headers om scriptbronnen te beperken, HttpOnly- en Secure-flags op sessiecookies, en geparameteriseerde API’s bij elke vertrouwensgrens.
WAF’s en beveiliging voor het uploaden van bestanden
Een web application firewall (WAF) inspecteert HTTP-verkeer en blokkeert verzoeken die overeenkomen met bekende kwaadaardige patronen — SQLi-signaturen, XSS-payloads, path traversal-sequenties, protocol-anomalieën. Wanneer deze wordt ingezet als een reverse proxy (ModSecurity met de OWASP Core Rule Set, AWS WAF, Cloudflare, F5), biedt het waardevolle virtuele patching wanneer een kwetsbaarheid wordt ontdekt voordat de code kan worden gerepareerd. Een WAF is echter een compenserende maatregel, geen vervanging voor secure coding. Gevorderde aanvallers omzeilen WAF’s routinematig door middel van encoding-trucs, HTTP-parametervervuiling en payload-fragmentatie.
Bestandsuploads verdienen speciale aandacht omdat ze niet-vertrouwde inhoud combineren met server-side opslag en, vaak, uitvoering. Beveiligingsmaatregelen omvatten het valideren van het bestandstype door de magic bytes te inspecteren in plaats van te vertrouwen op de extensie of de Content-Type-header, het opslaan van uploads buiten de web root, het hernoemen van bestanden naar door de server gegenereerde identifiers (om directory traversal via gefabriceerde bestandsnamen te voorkomen), het scannen met antivirussoftware vóór opslag, en het serveren van door gebruikers geüploade inhoud vanaf een afzonderlijk domein om same-origin scriptuitvoering te voorkomen.
Praktijkscenario: SQL-injectie die leidt tot volledige compromittering van de database
Het zoek-eindpunt voor producten van een retailbedrijf accepteerde een category-parameter die zonder sanering rechtstreeks in een SQL-query werd geconcateneerd. Een beveiligingsonderzoeker ontdekte dat het indienen van ' UNION SELECT table_name,null,null FROM information_schema.tables-- een lijst van alle databasetabellen in de respons teruggaf. Daaropvolgende verzoeken extraheerden de customers-tabel, wat 1,2 miljoen records opleverde, inclusief namen, e-mailadressen en met bcrypt gehashte wachtwoorden. De aanvaller ontdekte ook een stored procedure die via SQL-injectie kon worden aangeroepen om bestanden naar de web-root te schrijven, wat de implementatie van een webshell en volledige compromittering van de server mogelijk maakte. De kwetsbaarheid was al drie jaar aanwezig en was bij twee eerdere penetratietesten over het hoofd gezien, omdat de testers alleen het inlogformulier hadden getest en niet het zoek-eindpunt. De les: injectietesten moeten elke parameter in elk eindpunt omvatten, niet alleen de voor de hand liggende authenticatiepaden.
← Incidentrespons · Alle domeinen · Cloud →
Oefen deze vragen → · Getimede oefening op ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Slaag voor je examen →