In deze sectie zullen we een aantal algemene principes beschrijven voor het voorkomen van kwetsbaarheden in scripting tussen sites en manieren om verschillende gangbare technologieën te gebruiken voor het beschermen tegen XSS-aanvallen.

preventie van cross-site scripting kan over het algemeen worden bereikt via twee verdedigingslaagjes:

• gegevens coderen bij uitvoer
• invoer valideren bij aankomst

coderen van gegevens op uitvoer

coderen moet direct worden toegepast voordat gebruikersbesturbare gegevens naar een pagina worden geschreven, omdat de context waarin u schrijft bepaalt wat voor soort codering u moet gebruiken. Bijvoorbeeld, waarden in een JavaScript string vereisen een ander type escaping dan die in een HTML context.

In een HTML-context, moet u het omzetten van niet-vertrouwde waarden in de HTML-entiteiten:

• < converteert naar: <
• > converteert naar: >

In een JavaScript-string context, niet-alfanumerieke waarden moeten worden Unicode-escape:

• < converteert naar: \u003c
• > converteert naar: \u003e

Soms moet je toepassen van meerdere lagen van de codering, in de juiste volgorde. Om bijvoorbeeld veilig gebruikersinvoer in een event handler in te sluiten, moet u zowel de JavaScript-context als de HTML-context behandelen. Dus je moet eerst Unicode-ontsnappen aan de invoer, en dan HTML-coderen:

<a href="#" onclick="x='This string needs two layers of escaping'">test</a>

invoer valideren bij aankomst

codering is waarschijnlijk de belangrijkste regel van XSS-verdediging, maar het is niet voldoende om XSS-kwetsbaarheden in elke context te voorkomen. U moet ook de invoer zo strikt mogelijk valideren op het moment dat deze voor het eerst van een gebruiker wordt ontvangen.

voorbeelden van inputvalidatie zijn::

• als een gebruiker een URL indient die wordt geretourneerd in antwoorden, valideren dat het begint met een veilig protocol zoals HTTP en HTTPS. Anders zou iemand uw site kunnen exploiteren met een schadelijk protocol zoals javascript of data.
• als een gebruiker een waarde levert die naar verwachting numeriek is, valideren dat de waarde daadwerkelijk een geheel getal bevat.
• het valideren van die invoer bevat alleen een verwachte set tekens.

invoervalidatie zou idealiter moeten werken door ongeldige invoer te blokkeren. Een alternatieve benadering, van het proberen om ongeldige invoer schoon te maken om het geldig te maken, is meer foutgevoelig en MOET waar mogelijk worden vermeden.

Whitelisting vs blacklisting

bij invoervalidatie moet over het algemeen gebruik worden gemaakt van whitelists in plaats van blacklists. Bijvoorbeeld, in plaats van een lijst te maken van alle schadelijke protocollen (javascript, data, enz.), maak gewoon een lijst van veilige protocollen (HTTP, HTTPS) en niet toe te staan iets dat niet op de lijst. Dit zorgt ervoor dat je verdediging niet breekt wanneer er nieuwe schadelijke protocollen verschijnen en maakt het minder gevoelig voor aanvallen die ongeldige waarden proberen te verdoezelen om een zwarte lijst te ontwijken.

het toestaan van “veilige” HTML

het toestaan van gebruikers om HTML-opmaak te plaatsen moet waar mogelijk worden vermeden, maar soms is het een zakelijke eis. Bijvoorbeeld, een blog site kan toestaan commentaren worden geplaatst met een aantal beperkte HTML-opmaak.

de klassieke aanpak is om te proberen potentieel schadelijke tags en JavaScript uit te filteren. U kunt proberen om dit te implementeren met behulp van een witte lijst van veilige tags en attributen, maar dankzij verschillen in browser parsing motoren en eigenaardigheden zoals mutation XSS, deze aanpak is uiterst moeilijk om veilig te implementeren.

de minst slechte optie is om een JavaScript-bibliotheek te gebruiken die filtering en codering uitvoert in de browser van de gebruiker, zoals DOMPurify. Andere bibliotheken stellen gebruikers in staat om inhoud in markdown-formaat te bieden en de markdown om te zetten in HTML. Helaas, al deze bibliotheken hebben XSS kwetsbaarheden van tijd tot tijd, dus dit is niet een perfecte oplossing. Als u er een gebruikt, moet u nauwlettend controleren op beveiligingsupdates.

hoe te voorkomen dat XSS een template engine

gebruikt veel moderne websites gebruiken server-side template engines zoals Twig en Freemarker om dynamische inhoud in HTML in te bedden. Deze definiëren hun eigen ontsnappingssysteem. In Twig kunt u bijvoorbeeld het filter e() gebruiken, met een argument dat de context definieert:

{{ user.firstname | e('html') }}

sommige andere template engines, zoals Jinja en React, ontsnappen standaard aan dynamische inhoud die effectief voorkomt dat de meeste exemplaren van XSS.

we raden u aan escaping features nauwkeurig te bekijken wanneer u evalueert of een bepaalde template engine of framework gebruikt moet worden.

How to prevent XSS in PHP

in PHP is er een ingebouwde functie om entiteiten genaamd htmlentitieste coderen. Je zou deze functie moeten aanroepen om te ontsnappen aan je invoer in een HTML context. De functie moet worden aangeroepen met drie argumenten:

• uw invoerstring.
• ENT_QUOTES, Dat is een vlag die aangeeft dat alle aanhalingstekens moeten worden gecodeerd.
• de tekenset, die in de meeste gevallen UTF-8 zou moeten zijn.

bijvoorbeeld:

<?php echo htmlentities($input, ENT_QUOTES, 'UTF-8');?>

wanneer in een JavaScript string context, je nodig hebt om Unicode-escape input zoals reeds beschreven. Helaas, PHP biedt geen API om Unicode-escape een string. Hier is een aantal code om dat te doen in PHP:

<?php

function jsEscape($str) {
$output = '';
$str = str_split($str);
for($i=0;$i<count($str);$i++) {
$chrNum = ord($str);
$chr = $str;
if($chrNum === 226) {
if(isset($str) && ord($str) === 128) {
if(isset($str) && ord($str) === 168) {
$output .= '\u2028';
$i += 2;
continue;
}
if(isset($str) && ord($str) === 169) {
$output .= '\u2029';
$i += 2;
continue;
}
}
}
switch($chr) {
case "'":
case '"':
case "\n";
case "\r";
case "&";
case "\";
case "<":
case ">":
$output .= sprintf("\u%04x", $chrNum);
break;
default:
$output .= $str;
break;
}
}
return $output;
}
?>


hier is hoe de jsEscape functie in PHP te gebruiken:

<script>x = '<?php echo jsEscape($_GET)?>';</script>

u kunt ook een template engine gebruiken.

hoe te voorkomen dat XSS-client-side in JavaScript

om te ontsnappen aan gebruikersinvoer in een HTML-context in JavaScript, hebt u uw eigen HTML-encoder nodig omdat JavaScript geen API biedt om HTML te coderen. Hier is een voorbeeld van JavaScript-code die een tekenreeks converteert naar HTML-entiteiten:

function htmlEncode(str){
return String(str).replace(//gi, function(c){
return '&#'+c.charCodeAt(0)+';';
});
}


u zou dan deze functie als volgt gebruiken:

<script>document.body.innerHTML = htmlEncode(untrustedValue)</script>

als je invoer in een JavaScript string zit, heb je een encoder nodig die Unicode escaping uitvoert. Hier is een voorbeeld Unicode-encoder:

function jsEscape(str){
return String(str).replace(//gi, function(c){
return '\u'+('0000'+c.charCodeAt(0).toString(16)).slice(-4);
});


}

u zou dan deze functie als volgt gebruiken:

<script>document.write('<script>x="'+jsEscape(untrustedValue)+'";<\/script>')</script>

hoe XSS te voorkomen in jQuery

de meest voorkomende vorm van XSS in jQuery is wanneer je gebruikersinvoer doorgeeft aan een jQuery selector. Webontwikkelaars gebruiken vaak location.hash en geven het door aan de selector die XSS zou veroorzaken omdat jQuery de HTML zou renderen. jQuery herkende dit probleem en patched hun selector logica om te controleren of de invoer begint met een hash. Nu zal jQuery alleen HTML renderen als het eerste teken een <is. Als u niet-vertrouwde gegevens doorgeeft aan de jquery-selector, zorg er dan voor dat u de waarde correct ontsnapt met de jsEscape – functie hierboven.

het beperken van XSS met behulp van content security policy (CSP)

Content security policy (CSP) is de laatste verdedigingslinie tegen cross-site scripting. Als uw XSS-preventie mislukt, kunt u CSP gebruiken om XSS te beperken door te beperken wat een aanvaller kan doen.

met CSP kunt u verschillende dingen beheren, zoals of externe scripts geladen kunnen worden en of inline scripts uitgevoerd zullen worden. Om CSP te implementeren moet u een HTTP response header (Content-Security-Policy) opnemen met een waarde die uw beleid bevat.

een voorbeeld CSP is als volgt:

default-src 'self'; script-src 'self'; object-src 'none'; frame-src 'none'; base-uri 'none';

dit beleid geeft aan dat bronnen zoals afbeeldingen en scripts alleen kunnen worden geladen vanuit dezelfde oorsprong als de hoofdpagina. Dus zelfs als een aanvaller met succes een XSS-payload kan injecteren, kunnen ze alleen bronnen van de huidige oorsprong Laden. Dit vermindert sterk de kans dat een aanvaller de XSS kwetsbaarheid kan exploiteren.

als u het laden van externe bronnen nodig hebt, zorg er dan voor dat u alleen scripts toestaat die een aanvaller niet helpen om uw site te exploiteren. Als u bijvoorbeeld bepaalde domeinen op de witte lijst plaatst, kan een aanvaller elk script uit die domeinen Laden. Probeer waar mogelijk resources te hosten op je eigen domein.

als dat niet mogelijk is, kunt u hash – of nonce-gebaseerd beleid gebruiken om scripts op verschillende domeinen toe te staan. Een nonce is een willekeurige tekenreeks die wordt toegevoegd als een attribuut van een script of bron, die alleen zal worden uitgevoerd als de willekeurige tekenreeks overeenkomt met de server-gegenereerde. Een aanvaller is niet in staat om de willekeurige tekenreeks te raden en kan daarom geen script of bron aanroepen met een geldige nonce en dus zal de bron niet worden uitgevoerd.