nicht angemeldet
Tach,
Ich weiß halt nicht, wie weit ich mit meinen Absicherungen gehen soll, gehen kann.
so weit wie möglich, ohne dass es problematisch wird natürlich :-)
Z.B. will ich für ein Skript Vorgaben per INI machen. Dazu gehören auch Pfadangaben. Die Pfade kann ich auf ihre Existenz prüfen, aber ob mir hypothetisch jemand, der die INI manipuliert hat, einen anderen Pfad unterjubelt, natürlich nicht.
Nehmen wir mal das Beispiel: Erstmal solltest du sicherstellen, dass beim Parsen einer Config-Datei kein darin vorhandener Code ausgeführt wird (außer genau das ist der Plan), das wäre etwas, was ich als sehr unerwartet betrachten würde (und weswegen ich Config-Dateien nicht als inkludierten Code auslegen würde). Dann Pfade, da kann man erstmal prüfen, ob das ausgelesene überhaupt ein Pfad sein kann (z.B. kann ein Pfad im Allgemeinen kein NUL enthalten; einzelne Komponenten können nicht größer sein als x; muss hier ein absoluter Pfad erlaubt sein, oder reicht ein relativer; kann ein relativer „höher“ liegen als ein definiertes Root-Directory) (im besten Falle, indem man diese Prüfungen der zuständigen Klasse der verwendeten Sprache überlässt und vielleicht ob der Pfad Sinn ergibt (eine Log-Datei unter /bin oder als Sym-Link?), ob der verwendete Pfad existiert und die Rechte passend gesetzt sind (sofern das Programm das nicht selber übernimmt). Und dann kann man natürlich auch noch überprüfen, ob die Konfigurationsdatei selber sinnvolle Dateirechte hat („chmod g+w ~/.ssh“ führt dazu, dass ssh erstmal nichts mehr tut), damit kann man tatsächlich die Manipulation von Config-Dateien verhindern.
Wenn die Prüfungsmöglichkeiten aber nicht genügen oder ich die Hälfte übersehe, müsste ich die Werte gleich hart in das Programm schreiben.
Das kann durchaus nötig sein, z.B. der Pfad zur Konfigurationsdatei ist bei kompilierten Sprachen häufiger nur beim Kompilieren setzbar.
Was hier noch dazu kommt, sind fehlerhafte (also aus Security-Sicht) Protokolle und API-Definitionen; wenn du z.B. einen nutzbaren SMTP-Server implementieren würdest, gehört eine Menge mehr an Checks dazu, als das Protokoll selber vorschreibt.
Nee, lass mal. Sowas wäre mir ein ganzes Stück zu hoch.
Ah, SMTP ist vergleichsweise einfach (Mails verschicken, Mails entgegennehmen und spichern oder weiterleiten), deswegen habe ich es als Beispiel gewählt, aber die weiteren Implikationen sind dann halt ziemlich groß und dann erstmal nicht im Protokoll vorgesehen (wer darf hier eigentlich Mails verschicken und wie groß dürfen die sein und darfst du tatsächlich nachfragen, welche Adressen bei mir existieren?).
Bei Sicherheitsfragen ist also im Prinzip immer die Betrachtung der Grenzfälle wichtig; was macht mein Programm, wenn die INI-Datei 1 GB groß ist oder die Zeilenlänge sehr groß wird oder Zeichen enthält, die ich normalerweise nicht erwarte. Ich hatte schonmal CVE und CERT verlinkt (sowie ein paar andere Quellen für allgemeines genannt), das sind Quellen aus denen man lernen kann, was andere so allgemein falsch machen und dann vielleicht zum passenden Zeitpunkt selber dran denken.
Fehler, die einen Python aufgrund von Bugs machen oder doch besser durch zusätzliche Prüfungen vermeiden lässt, passt wohl eher. :-)
Genau das ist aber der Punkt, wo du ansetzen kannst/musst; die Fallstricke kennen, die sich aus deiner spezifischen Umgebung ergeben und diese sinnvoll umgehen. Bei Python stehen diese häufig schonmal im Handbuch auch wenn sie sich eigentlich bei kurzem Nachdenken selbst ergeben, z.B. dass mit pickle Daten zu lesen, wenn man nicht weiß, wo sie herkommen, keine gute Idee ist, habe ich schonmal jemandem erklären müssen.
Interessant ist es aber, auch wenn sich vieles auf den 2-er Zweig bezieht.
Häufiger steht einfach nicht dran, wenn auch 3 betroffen ist, stelle ich fest, siehe z.B. pickle.
mfg
Woodfighter
Auge