Webserver programmiert - nun auf Sicherheit testen, aber wie?

[Kennung Eins]

Hallo,

ich hatte malwieder Bock auf ein bisschen coden und hab ne kleine Webserver Applikation geschrieben. Mein Code basiert hierauf (http://www.computerleben.net/artikel/Einfacher_Webserver-287.html), d.h. ich verwende keine .NET Webserverfunktionalität.

Kurz zusammengefasst, was das Programm macht:
- Der Webserver verbindet auf einem festen Port.
- kein Multi-User-Check (Sessions, IP, o.ä.)
- Es wird eine HTML-Datei von der Festplatte gesendet.
- Klickt der Nutzer auf der HTML-Datei Buttons /Checkboxen an, so wird dies beim Absenden per <form action="1.html"> an den Webserver gesendet. Es entsteht also ein Adressstring wie "http://127.0.0.1:333/1.html?c=0&typ=Einfach&eingabe=aaa&Param=273"
- Die übergebenen Parameter wertet der Webserver aus und bereitet Daten vor, die dann wieder in die Seite eingebunden werden.

Es wird also ständig auf einer Seite vom Benutzer etwas angeklickt und beim Absenden die Seite aktualisiert mit neuen Daten geladen.

Jetzt würde ich mein Programm gern mal auf Angreifbarkeit testen. Wie könnte ich das tun?

[nalye]

"http://127.0.0.1:333/1.html?c=0&typ=Einfach&eingabe=aaa&Param=273"
Damit könnte man evtl. Schindluder treiben... XSS oder SQL-Injection, je nachdem...

[Kennung Eins]

Hm - SQL hängt da nicht dran, sollte also (hoffentlich?) keinerlei Auswirkungen haben.

XSS verstehe ich so, dass man damit quasi ne Umleitung über einen mit Schadcode versehenen Webserver macht? Falls das so ist, scheint man dagegen nix tun zu können oder?

Was könnte ich ganz konkret mal ausprobieren?

[edit]
Ach ja, der WS versteht nur "GET" und kein "POST".

[AlecWhite]

Jetzt würde ich mein Programm gern mal auf Angreifbarkeit testen. Wie könnte ich das tun?
Du schreibst Angriffsprogramme? Dafür definierst du was der Server tun darf (und zwar ausschließlich) und versuchst ihn nun quasi dazu zu überreden etwas anders zu tun (irgendwie).

Spontan würde mich interessieren, ob wie der Server auf die Eingabe von

"http://127.0.0.1:333/../../1.html"

reagiert.

[Kennung Eins]

Hehe, nein das mach ich nicht, da hoff ich auf die Kompetenz hier :)

Das war schonmal gut - er leitet einfach nur wieder auf "http://127.0.0.1:333/1.html" um, da ich sowas mache:

int pos = words[1].LastIndexOf("/");
if (pos > -1) {
...

[Senior Sanchez]

Hallo Meister :D

Du könntest auch probieren, ob du durch die Definition einer seltsamen URL den Server irgendwie zum Absturz oder in eine Schleife bringen kannst.

Kann dein Server nur eine Anfrage gleichzeitig bearbeiten oder wird das irgendwie gethreadet? Was passiert, wenn du sehr viele Anfragen gleichzeitig an ihn schickst?

[Kennung Eins]

Hehe moin :)

Ja das hatte ich auch schon überlegt und gestern mal getestet. Ich habs mit einem String von 600kb Größe getestet. Beim Datentyp Int sagt er als Rückmeldung nur, dass es für ein Int32 zu groß ist (das Verhalten ist so in Ordnung und gewünscht). Bei String frisst er ihn (wird als Eingabe in ein anderes Fenster genutzt - kann ja sein, dass der Anwender so einen riesen langen String wirklich eingeben möchte, d.h. auch in Ordnung).

Könnte man die GET Anfrage noch irgendwie so umformulieren, dass irgendwas negatives entsteht?

Wie groß müsste eine solche Anfragen sein, damit ein Buffer Overflow entsteht?

Der Server hat einen Hauptverarbeitungsthread, in dem sowas läuft:

while (running)
{
if (server.Poll(0, SelectMode.SelectRead))
{
...
}
Thread.Sleep(1);
}

[AlecWhite]

Könnte man die GET Anfrage noch irgendwie so umformulieren, dass irgendwas negatives entsteht?
Unendlich langer Request würde mir da spontan einfallen.

Bist du sicher, dass der Server bei GET ../../ nicht aus dem Document Root ausbricht (und dem Angreifer somit Zugriff auf alle Dateien des Systems gibt?)

[Kennung Eins]

Unendlich langer Request würde mir da spontan einfallen.
Ok, wie lang müsste der sein? Wie gesagt, habe es mit einem 600kb großen Request probiert (s.o.), also etwa so:
"http://127.0.0.1:333/1.html?c=0&typ=Einfach&eingabe=aaaaaaaaaaaaa(..)aa&Param=273" <-- so viele "a" dass es 600kb werden.

Bist du sicher, dass der Server bei GET ../../ nicht aus dem Document Root ausbricht (und dem Angreifer somit Zugriff auf alle Dateien des Systems gibt?)Ja, hab ich probiert. Die Verarbeitung läuft so, dass er nach dem letzten "/" im String sucht und erst ab da arbeitet.

Angenommen das Arbeitsverzeichnis ist "c:\webserver" und darin liegen 2 Dateien "1.html" und "2.html":

Beim der Anforderung "/1.html/../../2.html" würde die Verarbeitung alles vor dem letzten "/" ignorieren und nur "/2.html" als Eingabestring nutzen.

Macht man das so oder ist das problematisch?

[Senior Sanchez]

Beim der Anforderung "/1.html/../../2.html" würde die Verarbeitung alles vor dem letzten "/" ignorieren und nur "/2.html" als Eingabestring nutzen.

Macht man das so oder ist das problematisch?

Naja, das hätte eben das Problem, dass du keine Unterverzeichnisse im Webserver-Verzeichnis (da wo die Daten liegen) verwenden kannst.

Alternativ könnte man ja auch den String erstmal ganz normal interpretieren. Bibliotheksfunktionen für Dateizugriffe sollten .. und so weiter da richtig interpretieren können. Dann würde es ja reichen, zu überprüfen, ob der angegebene Pfad noch ein Unterpfad vom Webserver-Verzeichnis ist.

[Kennung Eins]

Ja das stimmt, das funktioniert dann nicht. Mal gucken, bisher brauche ich die Funktionalität nicht, aber wenn es soweit ist, scheint das ne gute Lösung zu sein. :up:

[AlecWhite]

Ok, wie lang müsste der sein? Wie gesagt, habe es mit einem 600kb großen Request probiert (s.o.), also etwa so:
"http://127.0.0.1:333/1.html?c=0&typ=Einfach&eingabe=aaaaaaaaaaaaa(..)aa&Param=273" <-- so viele "a" dass es 600kb werden.
Der Request wird einfach nicht gestoppt - dadurch lauscht der Server auf dem Socket halt ewig weiter und es kann niemand anders konnektieren -> DoS.

[Kennung Eins]

Ah sehr guter Tipp, das werde ich verhindern durch ne max. Länge je Request. Ist dann halt so, dass der Anwender da keine Romane reinhauen kann, sollte kein Manko sein :) Cool danke!

[Gast]

1.)
Ich würde mal eine Ebene weiter unten ansetzen:

Hast du die maximale Anzahl an Verbindungen pro IP Adresse limitiert?
Was machst du, wenn eine Verbindung nach der anderen zu dir aufbaut (kostet dich ca. 64KB RAM) und diese nicht mehr schließt.
Da kann man sehr schnell einen TCP Server zum stehen bringen, wenn der RAM ausgeht.
Falls das ganze dann auch noch virtualisiert ist und man die RAM Verteilung nicht ordentlich gemacht hat, dann nimmt man auch noch alle anderen Anwendungen auf dem Server mit.

2.) Ich glaube das Sinnvollste wäre es den Webserver einfach auf einem Testrechner laufen zu lassen, so dass er von außen erreichbar ist und die IP hier posten. Wenn es jemand schafft ihn in die Knie zu zwingen, dann soll er hier schreiben, wie er es angestellt hat und wie man es evenutell verbessern könnte. Die selbe Attacke sollte dann halt nicht noch einmal gefahren werden ;-)

[sei laut]

2.) Ich glaube das Sinnvollste wäre es den Webserver einfach auf einem Testrechner laufen zu lassen, so dass er von außen erreichbar ist und die IP hier posten. Wenn es jemand schafft ihn in die Knie zu zwingen, dann soll er hier schreiben, wie er es angestellt hat und wie man es evenutell verbessern könnte. Die selbe Attacke sollte dann halt nicht noch einmal gefahren werden ;-)
Wenn man das macht - was durchaus einen Spaßfaktor hätte - sollte man sich aber die Zeit notieren, damit Kennung Eins nicht gänzlich durcheinander kommt und nichts mehr zuordnen kann. :D

[Kennung Eins]

Danke, gute Hinweise. Im Moment murkle ich mit GDI/Win32 Sachen rum, wenn die Grundfunktionalität steht, dann werde ich den Server mal von außen zugreifbar machen. Die Server-Funktionalitäten sind zwar fertig, aber das eigentliche Programm noch nicht.

sei laut,
hehe jo :)