Was würde passieren, wenn nun ein Böswilliger mit nem Script übergroße Datenpakete senden würde?

Kann es dann zu Buffer-Overflows kommen?
Wenn ja, wie kann ich diese ausschließen (verhindern)?

Meines Wissens würde recv() nicht mehr als im Parameter angegebene Bytes zu meinem Buffer weiterleiten, sondern würde das, was zu viel ist, abschneiden und wegschmeissen.

Da ich unter keinen Umständen DOS-Attacken-Opfer werden will und das Programm ständig läuft wäre gut zu wissen, ob Gefahr besteht.

Mfg. Tolga.

Wenn dein Protokoll die Übertragung von Strings vorsieht, kann es z.B. sein, daß dann der 0-Terminator fehlt.

Finde ich aber Klasse, daß du dir um so etwas Gedanken machst. Weiter so

Danke für die Antworten. Es war gut zu erfahren, dass recv() nicht den überschüssigen Teil wegschmeisst. War mir neu.

Was passiert wenn dieser Queue auch voll wird (was ja allein wegen der Logik ganz sicher auftritt wenn permanent mehr geschickt wird als ich rauslese)?
Schmeisst Windows dann teile weg oder nimmt winsock keine neuen daten mehr an oder ist das die Geburt des Buffer-Overflows??

Bin dafür ich als Programmierer verantwortlich oder ist es Windows' Aufgabe sowas zu verhindern?

Bisher wurde mir nur empfohlen es einfach zu testen mit Übergroßen Paketen.
Sagen wir mal, ich ahbe es getestet und mein Programm stürzt ab. Wie kann man dann dagegen vorgehn?

Was mir spontan einfällt ist einfach immer 10 Bytes größeren Buffer anzugeben bei recv() als meine datenpakete groß sind. Dann könnte man eine Attacke im Keim erstekicken indem man, sobald ein größeres Paket ankommt als vorgesehn die Verbindung zum Remote sofort beendet wird.

Ich nehme mal an dass das auch der konventionelle Weg ist oder gibts da ne bessere Lösung?

Danke für die Antworten. Es war gut zu erfahren, dass recv() nicht den überschüssigen Teil wegschmeisst. War mir neu.

Ist jetzt nicht böse gemeint, aber lies dir unbedingt erst mal die Dokumentation im MSDN durch. Dort stehen die Antworten auf alle deine Fragen. Der 'Remarks'-Teil sollte unbedingt immer komplett durchgelesen werden.

Was passiert wenn dieser Queue auch voll wird (was ja allein wegen der Logik ganz sicher auftritt wenn permanent mehr geschickt wird als ich rauslese)?
Schmeisst Windows dann teile weg oder nimmt winsock keine neuen daten mehr an oder ist das die Geburt des Buffer-Overflows??

Wie im MSDN nachzulesen, hängt das vom Protokoll ab. Bei TCP wird nichts weggeschmissen.

Was mir spontan einfällt ist einfach immer 10 Bytes größeren Buffer anzugeben bei recv() als meine datenpakete groß sind. Dann könnte man eine Attacke im Keim erstekicken indem man, sobald ein größeres Paket ankommt als vorgesehn die Verbindung zum Remote sofort beendet wird.

Was genau du machen solltest, hängt von deinem Protokoll. Zwei Beispiele:

1. Der Client schickt immer nur ein Paket pro Verbindung.
In diesem Fall liest du einfach so viele Bytes, wie du für deine Pakete brauchst. Danach bearbeitest du dein Paket und schickst die Antwort zurück. Dann machst du einfach die Verbindung zu; wenn der Client zu viel geschickt hat, dann ignorierst du das einfach.

2. Der Client schickt mehrere Pakete pro Verbindung.
Dann machst du einfach das folgende in einer Schleife:
- Lies so viele Bytes ein, wie du für ein Paket brauchst.
- Überprüfe, ob das Paket gültige Daten enthält.
- Bearbeite das Paket.

Sollte der Client jetzt ein gültiges Paket plus Extra-Bytes schicken, dann würde der erste Teil der Daten (das gültige Paket) bearbeitet werden. Der Rest würde dann bei der Gültigkeits-Überprüfung durchfallen, und du würdest die Verbindung schließen.

Wichtig: recv() kann auch weniger Bytes zurückgeben als du haben möchtest. Die Buffer-Größe ist nur ein Maximal-Wert!

Wie gesagt: Lies dir mal ganz genau die Doku im MSDN durch; dann sollten die meisten Fragen beantwortet sein. Ansonsten einfach nochmal nachfragen.

Das mit dem 10 Bytes größeren Buffer vergiss schnell wieder. Viel zu umständlich, und sicher ist es auch nicht (z.B. weil recv() weniger als die Buffer-Größe zurückliefern kann etc.).

Ich nehme mal an dass das auch der konventionelle Weg ist oder gibts da ne bessere Lösung?

Die Lösung ist keine Lösung (siehe oben). Vergiss das bitte ganz schnell wieder.

Gruß

Raving Tux

@Raving Tux:
Danke für den tollen Tipp. Hört sich gut an. Wenn Extrabytes mitgeschickt werden die cniht zum Paket gehören, dann würden diese beim nächsten Aufruf von recv() als ein Teil des nächsten Pakets eingelesen und ich könnte mit ner Benachrichtigung über die falschen Daten die Verbindung zum Remote beenden.
Scheint auch sauberer zu sein.

@Geeky: Dann müsste der Client sich den Umständen anpassen und sinnvoll senden statt den Server voll zu schießen.

--- Hier mit ist der Thread für mich geschlossen. Thx @ll ---

Was passiert dann wenn nen mit 1 Gigabit angebundener Client eine 50 GB Datei empfängt, aber dessen Festplatte die Datei nur mit 0,5 Gigabit speichern kann ?
Dann würde die Queue ja ziemlich schnell ziemlich groß....

Stichwort Flusskontrolle. Bei TCP werden für jedes empfangene Paket eine Bestätigung verschickt, außerdem schickt der Server maximal x Pakete gleichzeitig auf die Reise. Das heißt, wenn der Empfänger mit Speichern nicht nachkommt, bekommt der Server weniger Bestätigungen und sendet automatisch langsamer.