Hoe te voorkomen dat Cross-Site Scripting aanvallen?

Wat is preventie van Cross-Site Scripting?

cross-site scripting prevention is het proces van het detecteren en herstellen van XSS kwetsbaarheden in uw websites of webapplicaties voordat ze op de productie. De detectie van XSS kwetsbaarheden kan automatisch worden gedaan, met behulp van een geautomatiseerde kwetsbaarheidsscanner, of handmatig door het uitvoeren van penetratietests. In dit artikel leert u de beste praktijken voor cross-site scripting preventie en hoe u ze onmiddellijk kunt implementeren. Aan het einde van het artikel vindt u ook een link naar een Gratis, Ontwikkelaar-gerichte kwetsbaarheidsscanner, zodat u kunt beginnen met het detecteren en herstellen van cross-site scripting kwetsbaarheden vroeg en vaak, als onderdeel van uw ontwikkeling pijpleidingen

In dit artikel, zult u leren:

  • Wat is Cross-Site Scripting preventie?
  • Hoe werkt cross-site scripting?
  • wat zijn de typen XSS-aanvallen?
  • hoe belangrijk is preventie van cross-site scripting?
  • Cross site scripting bescherming
    • Escape dynamische content
    • Whitelist waarden
    • het Implementeren van een content security policy
    • Desinfecteren HTML
    • HTTP-only Cookies
  • XSS-Preventie met code voorbeelden
    • Cross-site scripting-preventie in Python (Django)
    • Cross-site scripting-preventie in Ruby (Rails)
    • Cross-site scripting-preventie in Java (Java Server Pages)
    • Cross-site scripting-preventie in C# (ASP.NET)
    • cross-site scripting preventie in Node
      • snor.js
      • stof.js
      • Nunjucks
    • Cross-site scripting prevention in PHP
    • cross-site scripting prevention in AngularJS
    • Cross-site scripting prevention in React
  • Hoe kunnen geautomatiseerde tools cross-site scripting helpen voorkomen?

Hoe werkt cross-site scripting?

Cross-Site Scripting (XSS) aanvallen zijn een vorm van injectie aanval, waarbij kwaadaardige scripts worden geïnjecteerd in vertrouwde webapplicaties.

Hoe werkt cross site scripting diagram

een aanvaller kan de webtoepassing gebruiken om kwaadaardige code, meestal in de vorm van een browser side script, naar een andere eindgebruiker te sturen, wat resulteert in een XSS-aanval.

XSS-kwetsbaarheden komen vaak voor, wanneer een webtoepassing input gebruikt van een geldige gebruiker die zich in de gegenereerde output bevindt, maar zonder de juiste validatie of codering.

als het kwaadaardige script naar de gebruiker wordt gestuurd, kan de browser niet categorisch weten dat het script niet vertrouwd moet worden, en voert hij het script vervolgens uit. Dit script heeft dan toegang tot een veelheid aan gegevens, waaronder cookies, session tokens, of zelfs andere gevoelige informatie die door de browser voor die site kan worden bewaard.

wat zijn de typen XSS-aanvallen?

er zijn drie belangrijke typen XSS-aanvallen:

  1. gereflecteerd XSS: kwaadaardig script komt van het huidige HTTP-verzoek
  2. opgeslagen XSS: kwaadaardig script komt uit de website database
  3. DOM-gebaseerde XSS: waar de kwetsbaarheid bestaat in client-side code in plaats van server-side code.

hoe belangrijk is preventie van cross-site scripting?

de schade door het exploiteren van een XSS-kwetsbaarheid hangt af van de gevoeligheid van de gegevens die uw site verwerkt. Hier zijn enkele voorbeelden waar hackers XSS kwetsbare apps uitgebuit:

  • wormen verspreiden op sociale media: Facebook, Twitter en YouTube zijn allemaal succesvol aangevallen op deze manier.
  • session hijacking: Kwaadaardige JavaScript kan in staat zijn om de sessie-ID te sturen naar een externe site onder controle van de hacker, waardoor de hacker om die gebruiker te imiteren door het kapen van een sessie in uitvoering.
  • identiteitsdiefstal: als de gebruiker vertrouwelijke informatie zoals creditcardnummers invoert op een gecompromitteerde website, kunnen deze gegevens worden gestolen met behulp van kwaadaardig JavaScript.
  • Denial of service aanvallen en website vandalisme.
  • diefstal van gevoelige gegevens, zoals wachtwoorden.
  • financiële fraude op banksites.

cross-site scripting protection

Escape dynamische inhoud

gewoonlijk wordt dynamische inhoud in HTML geweven wanneer een webpagina wordt gerenderd. Als de dynamische inhoud onjuist wordt behandeld, kan een aanvaller die gebruiken om een opgeslagen XSS-aanval te construeren. De aanvaller zou misbruik maken van een bewerkbaar veld door het invoegen van een aantal kwaadaardige JavaScript-code, die wordt geëvalueerd in de browser wanneer een andere gebruiker bezoekt die pagina.

mogelijk wilt u niet dat uw gebruikers ruwe HTML schrijven, tenzij uw site een content-management systeem is. Ontsnap aan alle dynamische inhoud afkomstig van een gegevensopslag, zodat de browser weet dat het moet worden behandeld als de inhoud van HTML-tags, in tegenstelling tot ruwe HTML.

Ontsnappen dynamische inhoud bestaat meestal uit het vervangen van belangrijke tekens met de HTML-entiteit codering:

” &#34
# &#35
& &#38
‘ &#39
( &#40
) &#41
/ &#47
; &#59
< &#60
> &#62

Zoals u zult zien in de onderstaande codevoorbeelden, meest moderne kaders zullen ontsnappen aan de dynamische inhoud van de standaard.

door op deze manier bewerkbare inhoud te ontsnappen, zal de inhoud nooit als uitvoerbare code door de browser worden behandeld. Dit voorkomt de meeste XSS-aanvallen.

Whitelist-waarden

als een dynamisch gegevensitem slechts een handvol geldige waarden kan aannemen, beperk dan de waarden in het gegevensarchief. Zorg er ook voor dat je rendering logica alleen bekende, juiste waarden toestaat.

een voorbeeld waarin u deze aanpak wilt gebruiken, is door een gebruiker te vragen zijn land te selecteren uit een vervolgkeuzelijst, in plaats van het handmatig in te typen.

implementeer een inhoud-beveiligingsbeleid

moderne browsers ondersteunen inhoud-beveiligingsbeleid. Content – beveiligingsbeleid staat de auteur van een webpagina toe om te bepalen waar JavaScript en andere bronnen kunnen worden geladen en uitgevoerd.

om een XSS-aanval mogelijk te maken, moet de aanvaller kwaadaardige scripts kunnen uitvoeren op de webpagina van een gebruiker – hetzij door inline <script> tags te injecteren ergens binnen de <html> tag van een pagina, of door de browser te misleiden om het JavaScript te laden vanaf een kwaadaardig domein van derden.

het instellen van een content security policy in de response header zal u toelaten om de browser te vertellen om nooit inline JavaScript uit te voeren, en om de domeinen te kiezen die JavaScript voor een pagina kunnen hosten:

Content-Security-Policy: script-src 'self' https://apis.google.com
door de URL ‘ s van waaruit scripts kunnen worden geladen op een witte lijst te zetten, verklaart u impliciet dat inline JavaScript niet is toegestaan.

u kunt het inhoudsbeveiligingsbeleid ook in een <meta> – tag plaatsen in het <head> – element van een pagina:

<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">

deze aanpak is zeer effectief in het beschermen van uw gebruikers, maar vereist discipline om uw site klaar voor een dergelijke header te maken. Hoewel het hebben van inline scripts wordt beschouwd als een slechte praktijk in de moderne web-ontwikkeling, ze zijn gebruikelijk in oudere, legacy sites.

om stapsgewijs weg te migreren van inline scripts, overweeg gebruik te maken van CSP-schendingen. Door een rapport-uri-richtlijn toe te voegen aan uw beleidsheader, zal de browser u op de hoogte stellen van beleidsovertredingen, in plaats van te voorkomen dat inline JavaScript wordt uitgevoerd:

Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports

dit geeft je de zekerheid dat er geen slepende inline scripts zijn, voordat je ze regelrecht verbant.

ontsmet HTML

voor sommige sites is er een legitieme noodzaak om ruwe HTML op te slaan en te renderen. Als uw site rijke inhoud opslaat en weergeeft, moet u een HTML-ontsmettingsbibliotheek gebruiken om ervoor te zorgen dat kwaadaardige gebruikers geen scripts kunnen injecteren in hun HTML-inzendingen.

HTTP-only Cookies

kwaadaardig JavaScript kan worden gebruikt om een cookie met de sessie-ID van de gebruiker te stelen. Er is zelden een goede reden om cookies te lezen of te manipuleren in client-side JavaScript, dus overweeg het markeren van cookies als HTTP-only, wat betekent dat cookies worden ontvangen, opgeslagen en verzonden door de browser, maar niet kunnen worden gewijzigd of gelezen door JavaScript.

XSS preventie met code voorbeelden

cross-site scripting preventie in Python (Django)

Templates in Django escape HTML standaard, dus alles wat eruit ziet als het volgende is over het algemeen veilig:

**{{ contents }}**

u kunt escape overschrijven met behulp van het / safe filter. Er zijn vaak goede redenen om dit te doen, maar je moet code reviews uit te voeren op alles wat dit commando gebruikt:

**{{ contents | safe }}**

merk op dat HTML-escaping ook in-of uitgeschakeld kan worden met het {% autoescape %} label.

cross-site scripting preventie in Ruby (Rails)

Rails sjablonen ontsnappen standaard HTML, dus alles wat eruit ziet als het volgende is over het algemeen veilig:

<%= contents %>

u kunt escape overschrijven met de raw-functie of met de <%== – operator. Vaak zijn er goede redenen om dit te doen, maar je moet voeren code beoordelingen op iets dat maakt gebruik van deze functies:

<% raw contents %>

<%== contents %>

Cross-site scripting-preventie in Java (Java Server Pages)

Gebruik de c:out tag om veilig te ontsnappen HTML:

<c:out value="${contents}">

De volgende manieren van het schrijven van een sjabloon niet ontsnappen HTML, dus moet u ze met zorg:

<%= contents %>

${contents}

<%
out.println(contents);
%>

Cross-site scripting-preventie in C# (ASP.NET)

gebruik een van de volgende functies om veilig te ontsnappen aan HTML (het <%: formulier werd geïntroduceerd in ASP.NET 4.0):

<%= HttpUtility.HtmlEncode(contents) %>

<%: contents %>

de volgende manier van schrijven naar een sjabloon ontsnapt niet automatisch aan HTML, dus je moet ze voorzichtig gebruiken:

<%= contents %>

gebruik HttpUtility.HtmlEncode(...) als u HTML handmatig wilt ontsnappen.

cross-site scripting preventie in Node

snor.js

in snor.js, alle tags in dubbele snorren automatisch ontsnappen HTML:

{{ contents }}

Houd er rekening mee dat tags in triple snorren niet ontsnappen aan HTML, dus gebruik ze met zorg:

{{{ contents }}}

stof.js

Toets tags automatisch te ontsnappen HTML:

{ contents }

Echter, ontsnappen kan worden uitgeschakeld met de |s operator, dus gebruik deze met zorg

{ contents | s }

Nunjucks

Als de auto-om te ontsnappen is ingeschakeld in de omgeving, Nunjucks automatisch ontsnappen tags voor de veilige uitgang:

{{ contents }}

Inhoud gemarkeerd met de veilige filter zal niet ontkomen zijn, gebruik deze functie met zorg:

{{ contents | safe }}

Auto-ontsnappen kan worden uitgeschakeld voor een sjabloon, in welk geval tags moeten worden ontsnapt handmatig:

{{ contents | escape }}

Cross-site scripting-preventie in PHP

Het echo commando in PHP niet aan de HTML-standaard, wat betekent dat een code zoals de volgende die trekt de gegevens rechtstreeks uit de HTTP-aanvraag, is kwetsbaar voor XSS-aanvallen:

<?php
Echo $_POST;
?>

Cross-site scripting-preventie in AngularJS

geschreven inhoud in accolades automatisch aan te ontkomen, dus het volgende is veilig:

<div>{{dynamicContent}}</div>

Houd in gedachten dat elke code die bindt dynamische content aan het kenmerk innerHTML zal niet worden automatisch ontsnapt:

<div ="dynamicContent"></div>
<div innerHTML]="{{dynamicContent}}"></div>

Cross-site scripting-preventie in Reageren

Alle dynamische content geschreven in accolades wordt automatisch ontsnapte in Reageren, dus de volgende code veilig:

render() {
return <div>{dynamicContent}</div>
}

U kunt ook schrijven raw HTML-per bindend inhoud aan de dangerouslySetInnerHTML eigendom. De naam is geen toeval, dus kijk uit voor elke code die eruit ziet als de volgende:

render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}

Hoe kunnen geautomatiseerde tools cross-site scripting helpen voorkomen?

zoals hierboven vermeld, kan het voorkomen van cross-site scripting aanvallen eenvoudig zijn, met veel frameworks ontsnappen dynamische inhoud standaard. Maar dat gemak kan leiden tot onbedoelde en een aantal ernstige tekortkomingen in de beveiliging van uw toepassing en uw bedrijf.
zorg er altijd voor dat u uw applicaties scant op kwetsbaarheden voordat u ze vrijmaakt voor productie, idealiter als onderdeel van uw DevOps-en CI/CD-pijpleidingen om beveiligingsproblemen vroegtijdig te detecteren en op te lossen bij elke build / commit.

u kunt vandaag beginnen met het automatiseren van uw beveiligingstests met Nexploit, de Dynamic Application Security Testing scanner van NeuraLegion. Gebouwd voor ontwikkelaars en zonder valse positieven, kunt u het integreren in uw pijpleidingen om beveiligingstests naar links te verschuiven en door het ontwerp veilig te zijn.
Meld u hier aan voor uw gratis account: https://nexploit.app/signup

Leave a Reply

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.