Lesestoff zu Python gesucht

[Auge]

Hallo

Da hier eh gerade nach hier nicht so gängigen Programmiersprachen gefragt wurde, möchte ich eine Frage zu Python stellen. Bisher habe ich Webanwendungen in PHP geschrieben, also Skripte, die auf einem Webserver ausgeführt werden. Nun tauche ich gerade in die Welt von Python ein und schreibe meine ersten Skripte, die auf einem PC oder Windowsserver im lokalen Kontext laufen sollen.

Die Anforderungen an die Sicherheit von Programmen (Absicherung des Zugriffs und der Ausführung) sind im lokalen Kontext andere, als auf dem Webserver. Ich suche nun nach Lesestoff (unter Anderem) zu diesem Themenbereich und verliere mich dabei im Wust der Angebote. Hat jemand von euch Empfehlungen, die er mit mir (und natürlich der hiesigen Öffentlichkeit) teilen möchte?

Danke und tschö, Auge

[woodfighter]

Tach,

Die Anforderungen an die Sicherheit von Programmen (Absicherung des Zugriffs und der Ausführung) sind im lokalen Kontext andere, als auf dem Webserver.

ja sie sind anders; im Prinzip könnte man sagen sie sind (erstmal) geringer (sie verschieben sich halt anderswo hin), ich muss mir keine Sorgen darum machen, dass ein User Code mit erhöhten Rechten ausführen kann (bei HTTP möchte ich im allgemeinen verhindern, dass ein User Code im Context des Webservers ausühren kann), dafür ist das OS zuständig. Was man hier verhindern will, ist dass ein Script unerwartete Dinge tut, wenn es unerwarteten Input bekommt und das läuft im Prinip wieder auf die hinreichend beliebten Kontextwechsel hinaus.

Hat man aber Python-Code, der im Kontext eines anderen Users läuft (z.B. ein Daemon) und ein User soll dann wiederum darauf zugreifen, bist du im Prinzip wieder bei genau den selben Überlegungen wie bei Python auf dem Webserver. 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.

Ich suche nun nach Lesestoff (unter Anderem) zu diesem Themenbereich und verliere mich dabei im Wust der Angebote. Hat jemand von euch Empfehlungen, die er mit mir (und natürlich der hiesigen Öffentlichkeit) teilen möchte?

Für allgemeine Fehler, die man mit Python leicht machen kann, würde ich z.B. mal in https://github.com/ebranca/owasp-pysec/wiki schauen.

mfg
Woodfighter

[Auge]

Hallo

Was man hier verhindern will, ist dass ein Script unerwartete Dinge tut, wenn es unerwarteten Input bekommt und das läuft im Prinip wieder auf die hinreichend beliebten Kontextwechsel hinaus.

Soweit alles wie gehabt. (Nicht, dass das alles wäre)

Ich weiß halt nicht, wie weit ich mit meinen Absicherungen gehen soll, gehen kann. 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. 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.

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.

Ich suche nun nach Lesestoff (unter Anderem) zu diesem Themenbereich und verliere mich dabei im Wust der Angebote. Hat jemand von euch Empfehlungen, die er mit mir (und natürlich der hiesigen Öffentlichkeit) teilen möchte?

Für allgemeine Fehler, die man mit Python leicht machen kann, würde ich z.B. mal in https://github.com/ebranca/owasp-pysec/wiki schauen.

Fehler, die einen Python aufgrund von Bugs machen oder doch besser durch zusätzliche Prüfungen vermeiden lässt, passt wohl eher. :-)

Interessant ist es aber, auch wenn sich vieles auf den 2-er Zweig bezieht.

Tschö, Auge

[Peter Silie]

Die Anforderungen an die Sicherheit von Programmen (Absicherung des Zugriffs und der Ausführung) sind im lokalen Kontext andere, als auf dem Webserver.

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. 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.

Dein Problem wird nicht so ganz klar, insbesondere, was das mit Python und Webservern zu tun haben soll.

Dateien können grundsätzlich immer manipuliert worden sein, völlig egal, ob das sie nutzende Programm in PHP, Python, C oder sonstwas geschrieben wurde, oder ob das Programm von einem Webserver gestartet wurde oder händisch in der Befehlszeile.

Es hilft dir erstmal auch nichts, Werte fest einzuprogrammieren (fest, nicht veränderbar; hart ist was anderes), auch dein Skript kann schließlich manipuliert werden.

Deine Frage dreht sich alleine um die Rechtevergabe im Dateisystem und inwieweit du dem Nutzer deines Programms die Nutzung zutraust. Erlaubst du dem Nutzer, Einstellungen in einer separaten Datei zu sichern, wirst du dich damit abfinden müssen, dass er da auch Unsinn reinschreibt (und diesen Unsinn im Programm abfangen müssen), anders geht es nicht.
Welchen Unsinn du nun wiederum zulässt, hängt ganz vom Einsatzbereich deines Programms ab, dazu kann es keine Allgemeinplätze geben. Welche Dateirechte du unter Windows setzen kannst, hat nichts mit Python zu tun oder mit Webservern.

[Auge]

Hallo

Die Anforderungen an die Sicherheit von Programmen (Absicherung des Zugriffs und der Ausführung) sind im lokalen Kontext andere, als auf dem Webserver.

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. 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.

Dein Problem wird nicht so ganz klar,

Steht doch da: Übersehe ich etwas (die Hälfte)?

insbesondere, was das mit Python und Webservern zu tun haben soll.

Kontext im Eröffnungsposting. Die Anforderungen an die Absicherung von auf einem Webserver laufenden Skripten sind mir bekannt, die für lokal ausgeführte Programme/Skripte hingegen nicht.

Dateien können grundsätzlich immer manipuliert worden sein …

Es hilft dir erstmal auch nichts, Werte fest einzuprogrammieren (fest, nicht veränderbar; hart ist was anderes), auch dein Skript kann schließlich manipuliert werden.

Das ist klar.

Deine Frage dreht sich alleine um die Rechtevergabe im Dateisystem und inwieweit du dem Nutzer deines Programms die Nutzung zutraust. Erlaubst du dem Nutzer, Einstellungen in einer separaten Datei zu sichern, wirst du dich damit abfinden müssen, dass er da auch Unsinn reinschreibt (und diesen Unsinn im Programm abfangen müssen), anders geht es nicht.

Darum geht es mir. Gibt es besonderheiten im Vorgehen bei lokalen Programmen, um „diesen Unsinn im Programm ab[zu]fangen“? Definitionen von Wertebereichen oder die Überprüfung, ob ein Verzeichnis existiert (o.Ä.) sind ja hier wie dort möglich und sinnvoll. Aber gibt es da noch anderes?

Tschö, Auge

[Peter Silie]

Deine Frage dreht sich alleine um die Rechtevergabe im Dateisystem und inwieweit du dem Nutzer deines Programms die Nutzung zutraust. Erlaubst du dem Nutzer, Einstellungen in einer separaten Datei zu sichern, wirst du dich damit abfinden müssen, dass er da auch Unsinn reinschreibt (und diesen Unsinn im Programm abfangen müssen), anders geht es nicht.

Darum geht es mir. Gibt es besonderheiten im Vorgehen bei lokalen Programmen, um „diesen Unsinn im Programm ab[zu]fangen“?

Nein. Es ist grundsätzlich völlig unerheblich, auf welchem Rechner dein Programm Dateien lädt und auswertet.

Wenn man zudem bedenkt, dass gerade PHP in der meist anzutreffenden Konfiguration als Modul des Webservers (-programmes) ein Problem an sich ist, da alle Skripte aller Servernutzer dann immer mit den Rechten des Webservers laufen, bist du mit eigenständig laufenden Skripten, d.h. solchen, die mit deinen Rechten unter deinem Namen laufen, sogar noch etwas mehr auf der sicheren Seite (was jetzt keine Laissez-faire-Politik sein soll, hingucken muss man trotzdem).

Um nochmal auf konkrete Punkte zurückzukommen und dabei zu erklären, warum deine Frage mich etwas verwirrt:

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.

Es ist Zweck einer Konfigurationsdatei, manipuliert zu werden, "manipuliert" im neutralen Sinne.
Möchtest du nicht, dass ein Wert manipuliert, lies: geändert wird, dann hat er in dieser Konfigurationsdatei nichts zu suchen (vielleicht in einer anderen, zweiten, die durch das Dateisystem vor unberechtigtem Zugriff geschützt wird; es gibt für viele Programme systemweite Einstellungen und solche des Benutzers). Hat nichts mit PHP, Python oder Webservern zu tun.

Dass von Benutzern eingegebene Werte, auch via Datei, immer innerhalb eines Bereichs fallen müssen, alleine schon, weil Benutzer auch mal Fehler machen, hast du ja bereits selbst erwähnt und ist auch keine Besonderheit. Anders gesagt: Ob dein Skript brav in seinem Arbeitsverzeichnis wurschtelt oder gerade sich selbst ausgibt, mitsamt den MySQL-Zugangsdaten, hast du hoffentlich bereits bei deinem (hypothetischen) in PHP geschriebenen Download-Formular geprüft.

Die Knochenarbeit beim Einlesen von .ini-Dateien kannst du https://docs.python.org/3/library/configparser.html überlassen.

Die Werteprüfung bei Pfaden wurde im anderen Beitrag schon beschrieben. Unbrauchbare Pfade weist das Dateisystem von sich aus zurück, du musst nicht selbst prüfen, ob ein Objektname ungültige Zeichen enthält oder länger als x ist (Paranoia mal beiseite).

Du solltest hingegen prüfen, ob der Pfad sich in einem akzeptablen Bereich befindet. Dateifunktionen bei PHP haben IIRC die unangenehme Eigenart, unter Umständen URLs zu akzeptieren. Bei Python ist das grundsätzlich nicht so, informiere dich trotzdem in der Beschreibung der jeweiligen Funktion.

Je nach Anwendung bietet es sich an, in der Konfigurationsdatei eine einzige, zentrale Wurzel angeben zu lassen; alle anderen Pfade dürfen nur relativ sein, sich auf diese Wurzel beziehen und im Endeffekt nicht auf Ziele oberhalb dieser Wurzel verweisen.

Ohne mich jetzt wiederholen zu wollen: Das sind allgemeine Fragen des sicheren Umgangs mit Benutzereingaben. Dass du unter dem Stichwort Python dazu nichts finden konntest, liegt vielleicht einfach daran, dass es nichts mit Python zu tun hat. Du wirst vielleich eher fündig, wenn du dich auf den speziellen Anwendungsfall konzentrierst, bei den Pfadangaben beispielsweise den Konventionen unter Windows (Rechte, Organisation des Dateisystems, speziell Benutzerverzeichnisse, %USERPROFILE% usw.).

[Auge]

Hallo

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.

Es ist Zweck einer Konfigurationsdatei, manipuliert zu werden, "manipuliert" im neutralen Sinne.

Erwünscht ist die Manipulation aber eben nur, wenn jemand Einstellungen vornimmt, die nachher nicht verändert werden, solange sie gültig sind/sein sollen. Um beim Beispiel der Pfade zu bleiben, werden die in der INI angegebenen Pfade bisher auf ihre Existenz geprüft und das Programm mit einer Meldung im Log gleich wieder beendet, wenn sie nicht existieren.

Möchtest du nicht, dass ein Wert manipuliert, lies: geändert wird, dann hat er in dieser Konfigurationsdatei nichts zu suchen (vielleicht in einer anderen, zweiten, die durch das Dateisystem vor unberechtigtem Zugriff geschützt wird; es gibt für viele Programme systemweite Einstellungen und solche des Benutzers). Hat nichts mit PHP, Python oder Webservern zu tun.

An dieser Stelle gleichen die Anforderungen also denen auf einem Webserver.

Dass von Benutzern eingegebene Werte, auch via Datei, immer innerhalb eines Bereichs fallen müssen, alleine schon, weil Benutzer auch mal Fehler machen, hast du ja bereits selbst erwähnt und ist auch keine Besonderheit. Anders gesagt: Ob dein Skript brav in seinem Arbeitsverzeichnis wurschtelt oder gerade sich selbst ausgibt, mitsamt den MySQL-Zugangsdaten, hast du hoffentlich bereits bei deinem (hypothetischen) in PHP geschriebenen Download-Formular geprüft.

Die Knochenarbeit beim Einlesen von .ini-Dateien kannst du https://docs.python.org/3/library/configparser.html überlassen.

Das tu ich schon.

[Tips und Tricks]

Ohne mich jetzt wiederholen zu wollen: Das sind allgemeine Fragen des sicheren Umgangs mit Benutzereingaben. Dass du unter dem Stichwort Python dazu nichts finden konntest, liegt vielleicht einfach daran, dass es nichts mit Python zu tun hat. Du wirst vielleich eher fündig, wenn du dich auf den speziellen Anwendungsfall konzentrierst, bei den Pfadangaben beispielsweise den Konventionen unter Windows (Rechte, Organisation des Dateisystems, speziell Benutzerverzeichnisse, %USERPROFILE% usw.).

Das ist durchaus möglich. :-)

Tschö, Auge

[woodfighter]

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]

Hallo

[Haufenweise wertvoller Input] …

… den ich mir wohl noch ein paar Male werde durchlesen 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.

Alle Punkte die ich durchstöbert habe, gelten bis spätestens Python 3.2. Der letzte Code wurde vor über einem Jahr eingecheckt. Neuere Versionen scheinen nicht berücksichtigt worden zu sein. Das ändert nichts am grundsätzlichen Wert der Doku.

Tschö, Auge

[Kay nicht angemeldet]

Die Anforderungen an die Sicherheit von Programmen (Absicherung des Zugriffs und der Ausführung) sind im lokalen Kontext andere, als auf dem Webserver. Ich suche nun nach Lesestoff (unter Anderem) zu diesem Themenbereich und verliere mich dabei im Wust der Angebote. Hat jemand von euch Empfehlungen, die er mit mir (und natürlich der hiesigen Öffentlichkeit) teilen möchte?

Die Doku vom Zope Applikationsserver lesen und das Konzept dahinter verstehen. Es war immer recht einfach Firmenstrukturen damit im Intranet abzubilden. Und die Sicherheit kam auch nicht zu kurz. Ist zwar Python 2, aber für Python 3 dürfte es ein paar alternative Applikationsserver geben.

Die Frage ist ja auch immer, was will man genau machen. Frag mich aber nicht weiter zu Python, meine aktuelle Baustelle ist Erlang.

[Christian Kruse]

Hallo Kay,

Frag mich aber nicht weiter zu Python, meine aktuelle Baustelle ist Erlang.

Ah, noch jemand, der dieses schöne Ökosystem zu schätzen gelernt hat? :)

LG,
CK

[Kay nicht angemeldet]

Ah, noch jemand, der dieses schöne Ökosystem zu schätzen gelernt hat? :)

Ich schätze es sehr. Aber bin immer noch am lernen, hätte ich schon vor Jahren kennen lernen müssen.

[Christian Kruse]

Hallo Kay,

Ah, noch jemand, der dieses schöne Ökosystem zu schätzen gelernt hat? :)

Ich schätze es sehr. Aber bin immer noch am lernen, hätte ich schon vor Jahren kennen lernen müssen.

Cool! Vielleicht gibts demnächst dann ja hier Erlang- oder Elixir-Fragen.

LG,
CK

[Kay nicht angemeldet]

Cool! Vielleicht gibts demnächst dann ja hier Erlang- oder Elixir-Fragen.

Glaube ich kaum, aber Tips für Bücher (ja auch die physischen Dinger), Wiki, Doku Tutorial etc. in meiner Muttersprache sind immer willkommen.

Pavlo Baron "Erlang/OTP Plattform für massiv-parallele und fehlertolerante Systeme" habe ich.

Zur Not auch in englischer Sprache.

Fred Hebert "Learn You Some Erlang for Greats Good!" tue ich mir gerade an.

[Kay nicht angemeldet]

Role-Based Access Control Models

Links

Deutsch

Englisch

Englisch

Englisch

Englisch

Python

Python

Python

Python

Python

Python

Python

Python

[Auge]

Hallo

Role-Based Access Control Models

Links

Meine Fresse, 'ne Menge Lesestoff. Danke. :-)

Tschö, Auge