Elke programmeertaal heeft zijn eigen set beveiligingskwetsbaarheden, en JavaScript is geen uitzondering. Het misbruiken van JavaScript-kwetsbaarheden kan leiden tot gegevensmanipulatie, sessie-overnames, ongeautoriseerde toegang tot gegevens en meer. Hoewel JavaScript-beveiligingsrisico’s doorgaans geassocieerd worden met client-side functionaliteit, kunnen ze ook aanzienlijke bedreigingen vormen in server-side omgevingen.
Voor elke toepassing is het vertrouwen van klanten van groot belang. Dit vertrouwen behouden vereist het beschermen van klantgegevens en het waarborgen van de beveiliging van toepassingen. Gelukkig kunnen het implementeren van juiste waarborgen deze risico’s verminderen en de beveiliging van uw toepassing verbeteren.
In dit artikel zullen we enkele van de meest voorkomende JavaScript-beveiligingsbedreigingen verkennen en effectieve tools en strategieën bespreken om uw toepassing te beschermen tegen mogelijke aanvallen.
Cross-Site Scripting
Cross-site scripting (XSS) is een beveiligingslek dat een aanvaller in staat stelt kwaadaardige client-side code in een website te injecteren. Volgens het Open Web Application Security Project (OWASP) Top 10 beveiligings kwetsbaarheden uit 2021, staat XSS op de derde plaats als meest voorkomende aanvalsvector.
Hoe XSS te mitigeren
Inputvalidatie
Zorg ervoor dat gebruikersinvoer overeenkomt met verwachte gegevenstypen, formaten en bereiken. Verwijder of escape potentieel schadelijke karakters om injectie te voorkomen.
function validateInput(input) {
return input.replace(/[^a-zA-Z0-9]/g, ''); // Allow only alphanumeric characters
}
Uitvoercodering
Zet speciale tekens in de uitvoer om naar hun HTML-entity-equivalenten om mogelijk schadelijke scripts te neutraliseren voordat ze worden weergegeven.
function encodeHTML(input) {
return input.replace(/&/g, '&')
.replace(/</g, '<')
.replace(/>/g, '>')
.replace(/"/g, '"')
.replace(/'/g, ''');
}
Klikkenkapen
Klikkenkapen is een bedrieglijke aanval die gebruikers misleidt om te klikken op een element waar ze niet mee willen interacteren. Deze techniek houdt in dat een legitieme website wordt ingebed in een kwaadaardige website – vaak met behulp van een onzichtbare of misleidend gepositioneerde HTML <iframe>
– om gebruikersacties te kapen. Als gevolg hiervan kunnen aanvallers inloggegevens stelen, ongeautoriseerde machtigingen verkrijgen, of zelfs gebruikers bedriegen om onbewust malware te installeren.
Een veelvoorkomende manier om dit te bereiken is door CSS te gebruiken om een overlappende knop toe te voegen met opacity
ingesteld op bijna 0. Hiermee wordt de gebruiker misleid om op een onbedoelde knop of link te klikken.
Hoe klikkenkapen te voorkomen
De X-Frame-Options instrueert de browser of de site kan worden ingebed binnen een iframe. Het heeft drie opties:
- DENY – Voorkomt dat de pagina volledig in een iframe wordt weergegeven
- SAMEORIGIN – Staat toe dat de pagina alleen wordt ingebed als het verzoek afkomstig is van hetzelfde domein
- ALLOW-FROM – Staat toe dat de pagina alleen wordt ingebed door een specifiek, vertrouwd domein
In Node.js kunt u helmet
gebruiken om deze opties in te stellen, zoals hieronder weergegeven:
const helmet = require("helmet");
const app = express();
app.use(
helmet({
xFrameOptions: { action: "sameorigin" },
}),
);
Een effectieve verdediging tegen clickjacking is het implementeren van de Content Security Policy (CSP) header. CSP biedt gedetailleerde controle over hoe en waar inhoud kan worden ingesloten, waardoor ongeautoriseerd inlijsten wordt voorkomen.
Om clickjacking risico’s te verminderen, moet de frame-ancestors
richtlijn worden opgenomen in uw CSP header. Bijvoorbeeld:
Content-Security-Policy: frame-ancestors 'self' https://www.example.org;
Deze beleidsregel zorgt ervoor dat het beveiligde document alleen kan worden ingesloten door zijn eigen oorsprong ('self'
) en expliciet toegestane domeinen, zoals example.org
. Het blokkeert alle ongeautoriseerde pogingen om de inhoud in te kaderen, waardoor gebruikers worden beschermd tegen clickjacking-aanvallen.
Opmerking: Als frame-ancestors en X-Frame-Options beide zijn ingesteld, zullen browsers die frame-ancestors ondersteunen X-Frame-Options negeren.
Cross-Site Request Forgery (CSRF)
CSRF (soms ook XSRF genoemd) maakt misbruik van het vertrouwen dat een website heeft in de browser van een gebruiker door ongeautoriseerde verzoeken namens de gebruiker te doen. Aanvallers misleiden gebruikers om acties uit te voeren zonder hun medeweten, wat kan leiden tot gegevenslekken of ongewenste transacties. Enkele voorbeelden zijn het bijwerken van de persoonlijke gegevens van het slachtoffer, het starten van een geldoverdracht van de bankrekening van het slachtoffer, of zelfs het omleiden van een pakketlevering naar een ander adres.
Laten we eens naar een specifiek voorbeeld hiervan kijken. Je bezoekt de website van je bank en je bent ingelogd. Stel dat je een e-mail krijgt voor een weggeefactie die zich voordoet als je bank. De link brengt je naar een ogenschijnlijk onschuldige webpagina. Achter de schermen wordt een POST-verzoek geactiveerd en verzonden naar de legitieme banktoepassing.
curl --location --request POST 'https://acmebank.com/transfer?routing=852363&fromAccountNumber=123456789&toAccountNo=987654321' \
--header 'Cookie: session=acmebanksessionwaarde'
Aan de kant van de acmebank.com-toepassing verzendt de “script”-tag het formulier zodra de gebruiker de pagina laadt, zonder enige gebruikersvalidatie of dat de gebruiker zelfs opmerkt wat er gebeurt, zoals hieronder wordt getoond.
<html>
<body>
<form action="https://acmebank.com/transfer" method="POST">
<input type="hidden" routing="852363" fromAccountNo="123456789" toAccountNo="987654321" amount="5000" />
</form>
<script>
window.addEventListener("DOMContentLoaded", () => {
document.querySelector("form").submit();
});
</script>
</body>
</html>
Het bovenstaande formulier genereert het volgende verzoek naar de daadwerkelijke toepassing, acmebank. Het verzoek bevat de legitieme gebruikerssessiecookie, maar bevat ons bankrekeningnummer! Omdat je sessie met je bank nog actief is, zal de overboeking van het bedrag doorgaan als er geen andere validatie plaatsvindt.
Hoe jezelf te verdedigen tegen CSRF
Stel de SameSite-attribuut in op Strikt. Hiermee wordt gecontroleerd of een cookie wordt verzonden bij cross-site-verzoeken.
- Zulke sessiecookies zouden een korte levensduur moeten hebben. Vereis herauthenticatie voor gevoelige acties om risico’s te beperken.
Gebruik CSRF-sessie-unieke tokens. Deze token kan vervolgens worden opgenomen in een formulier dat door de browser wordt gepost. Voor elk verzoek vergelijkt de server de door de client verzonden token met de opgeslagen waarde voor de sessie. Gebruik de bibliotheek csrf-csrf om unieke tokens te configureren.
Stelen van sessiegegevens
Sessiekaping treedt op wanneer een aanvaller de sessietoken van een gebruiker steelt, waardoor ze de gebruiker kunnen imiteren en ongeautoriseerde toegang tot hun account kunnen krijgen.
Hoe sessiekaping voorkomen
Gebruik beveiligde cookies
Stel de Secure
en HttpOnly
vlaggen in op sessiecookies om ongeautoriseerde toegang te voorkomen. Het instellen van het Secure attribuut voorkomt dat de sessiecookie in platte tekst wordt verzonden en staat alleen verzending toe via HTTPS-verbindingen. Het instellen van het Http-Only
attribuut dwingt de browser om geen toegang tot de cookie vanuit de DOM toe te staan waardoor client-side scriptgebaseerde aanvallen geen toegang hebben tot de gevoelige gegevens die in die cookies zijn opgeslagen.
Activeer Multi-Factor Authenticatie (MFA)
Voeg een extra beveiligingslaag toe om gebruikers te verifiëren. Dit is een zeer gebruikelijke methode die je zult tegenkomen in de meeste veilige applicaties. Gemakkelijke integraties zijn beschikbaar via providers zoals Okta en Duo.
Implementeer Sessie Verloop
Laat inactieve sessies automatisch verlopen om aanvalsmogelijkheden te verminderen.
Coderingspraktijken en -tools voor hoogwaardige beveiliging
Vulnerability Scanning
Een kwetsbaarheidsscanner zorgt voor de beveiliging van uw toepassing. Door uw bibliotheken, netwerk, toepassingen en apparaten te scannen, worden zwakke plekken blootgelegd die aanvallers zouden kunnen misbruiken. Tools zoals Snyk en Sonarqube kunnen eenvoudig worden geïntegreerd in JavaScript-codebases. Deze tools werken parallel met bekende lijsten van kwetsbaarheden onderhouden door OWASP. Met naadloze integratie als onderdeel van het ontwikkelingsproces bieden deze scanners ontwikkelaars en beveiligingsteams real-time en nauwkeurig inzicht in codekwetsbaarheden en oplossingen om ze te verhelpen.
Penetratietesten en beoordelingen
Ontwikkelaars kunnen penetratietestpraktijken aannemen om actief potentiële kwetsbaarheden binnen een toepassing te onderzoeken en te misbruiken. Ethische hackers simuleren aanvallen in de echte wereld om de beveiligingspositie van webtoepassingen te beoordelen door het manipuleren van JavaScript-code en gebruikersinteracties.
Om dit te bereiken, kunnen ontwikkelaars klantgerichte JS-code schrijven om de scenario’s te simuleren, of ze kunnen gespecialiseerde penetratietesttools gebruiken die JavaScript benutten om het proces van scannen naar veelvoorkomende kwetsbaarheden zoals XSS te automatiseren, met behulp van OWASP ZAP. Meer informatie over penetratietesten is beschikbaar in de officiële gids van OWASP.
Web Application Firewall (WAF)
Naarmate applicaties groeien, neemt ook het webverkeer toe, waardoor de blootstelling aan aanvallen toeneemt. Het implementeren van een Web Application Firewall (WAF) helpt bij het beschermen tegen kwaadaardig verkeer door het filteren en monitoren van HTTP-verzoeken. Dit houdt in dat integratie met externe WAF-providers zoals Cloudflare of AWS WAF. Met WAF kunt u regels definiëren zoals:
- Land of geografische locatie waar de verzoeken vandaan komen.
- IP-adres, CIDR-bereik en domeinnamen waar de verzoeken vandaan komen.
- Beperken van verzoeklengtes en queryparameters om injectieaanvallen te voorkomen.
- SQL-code die waarschijnlijk kwaadaardig is. Aanvallers proberen gegevens uit uw database te extraheren door kwaadaardige SQL-code in een webverzoek in te sluiten. Dit staat bekend als SQL-injectie.
- Het detecteren en blokkeren van ingesloten scripts die deel kunnen uitmaken van XSS-aanvallen.
Een WAF kan ook helpen bij het mitigeren van Distributed Denial of Service (DDoS) aanvallen, waardoor de beschikbaarheid van de applicatie wordt gewaarborgd.
Bescherm de gegevensintegriteit
Het implementeren van robuuste maatregelen voor gegevensintegriteit is essentieel bij het opslaan of openen van veilige informatie. Best practices omvatten:
- Het afdwingen van sterke wachtwoordbeleid en het aanmoedigen van het gebruik van wachtwoordmanagers. Daarnaast, moedig je gebruikers aan om een wachtwoordmanager te gebruiken, zodat ze complexere wachtwoorden kunnen gebruiken en zich geen zorgen hoeven te maken over het onthouden ervan (Gebruik LastPass of 1Password).
- Bescherm tegen brute force aanvallen op inlogpagina’s met snelheidbeperkingen, accountvergrendelingen na een bepaald aantal mislukte pogingen en CAPTCHA-uitdagingen.
- Het gebruik van HTTP-headers zoals:
- HTTP Access-Control-Allow-Origin om te controleren welke oorsprongen toegang hebben tot bronnen.
- HTTP X-Content-Type-Options om MIME-type beveiligingsrisico’s te voorkomen.
- Subresource integriteit (SRI) om ervoor te zorgen dat bronnen van CDNs ongewijzigd zijn.
Conclusie
JavaScript-beveiliging is een voortdurend proces dat een proactieve aanpak vereist om applicaties te beschermen tegen evoluerende bedreigingen. Het implementeren van beste praktijken zoals invoervalidatie, CSP-headers, veilig sessiebeheer en kwetsbaarheidsscans kan het risico op aanvallen zoals XSS, CSRF en sessie-overnames aanzienlijk verminderen.
Bovendien versterkt het gebruik van beveiligingstools zoals WAF’s, penetratietests en MFA de veerkracht van applicaties. Door veiligheid te prioriteren in elke ontwikkelingsfase kunnen ontwikkelaars robuuste, op vertrouwen van gebruikers gebaseerde applicaties bouwen die beschermd blijven tegen moderne cyberbedreigingen.
Source:
https://dzone.com/articles/enhancing-security-in-javascript