nicht angemeldet
Gutes Nächtle Euch allen!
Kleine Warnung vorweg. Das hier könnte etwas länger werden. Ich habe zwar gerade einmal nicht so ganz konkret ein Problem, Fragen aber trotzdem. :)
Im Prinzip ist mein Anliegen ganz einfach. Nachdem ich mich so langsam in PHP eingearbeitet habe interessiert mich zur Zeit vor allem was - und worauf - man insgesamt achten sollte, wenn man erreichen will das seine eigenen Scripte nicht das Sprichwörtliche Scheunentor darstellen. Eventuell will man die ja auch einmal auf die Menschheit loslassen. Ganz konkret ist das Thema also welche Sicherheitsrelevanten Aspekte man kennen sollte.
Mir ist klar das mir jetzt hier wohl kaum jemand eine ausführliche Einführung geben wird/will; ist auch gar nicht meine Absicht. Habe mir schon selbst die paar Quellen die ich finden konnte zu Gemüte geführt (Und mir sogar den einen oder anderen eigenen Gedanken gemacht ;o) ). Nur habe ich hier und dort noch ein paar kleine Nachfragen Und natürlich interessiert mich auch alles das was mir bisher noch so entgangen ist.
Mit Eurer Erlaubnis werde ich deshalb eben einfach mal kurz die Dinge aufzählen die ich bisher herausfinden konnte und dann ggf. dazu Nachfragen stellen. Vielleicht kann damit ja sogar auch noch der ein oder andere etwas anfangen?
(Ohne Eure Erlaubnis mach ich das natürlich trotzdem. Da kenn' ich ja nix.)
Übrigens dürfen natürlich auch gerne die Perl-Profis Antworten. Das ich jetzt selber PHP benutze spielt ja keine Rolle, müßten doch die generellen Probleme auch dort die gleichen sein. Denn mal los...
Punkt 1: 'Input'-Daten auf Gültigkeit überprüfen.
-------------------------------------------------
• Daten auf formale Richtigkeit prüfen.
• Daten die an externe Programme/die Shell/ oder kritische Funktionen ('eval();') gehen auf ungültige Zeichenfolgen prüfen. (z.B. '|' bei Daten an Sendmail) Bzw. prüfen das nur gültige Zeichenfolgen vorkommen.
• Wenn es sich um Pfadangaben zu Dateien/Verzeichnissen handelt prüfen ob nicht unerlaubterweise versucht wird den Dateipfad zu wechseln. Bsp. '../../../etc' o.ä.
FARGE: In wieweit macht es Sinn das oben gesagte auch auf eventuell vorhandene eignen (Text-) Konfigurationsdateien anzuwenden? Man weis ja nie... Oder gilt eher, wenn die erst manipuliert wurden ist es es schon zu spät?
Punkt 2: 'Environment'-Variablen prüfen.
----------------------------------------
• Konkret habe ich am Fall von PATH gelesen das man diese, wenn möglich, in seinen Script 'per Hand' setzen sollte wegen möglicher Manipulation.
FRAGE: Gehe ich also richtig davon aus, das den meisten anderen Environment-Variablen genau so wenig zu trauen ist und ich ähnlich gelagerte Evs grundsätzlich besser 'selber setzte'?
Punkt 3: Dateien/Dateihandling.
-------------------------------
• Dateien in die geschrieben werden soll in Unterverzeichnisse ablegen und nur in diesen Schreibzugriffe zulassen.
• Wenn übergebene Daten z.B. zur Generierung von HTML-Dateien benutzt werden darauf achten das keine 'aktiven Inhalte' wie eingebetetes PHP oder auch SSI darin vorkommen. (Bsp. PHP-Dateien, da dort möglicherweise ein „echo phpinfo();" drinnen stehen könnte, das Auskunft über die interne Struktur des Servers liefert)
Alternative im Verzeichnis der generierten Dateien keine aktiven Inhalte zulassen.
• Wen in Dateien geschrieben wird FLOCK/File-Locking benutzen. Atomare Zugriffe gewährleisten.
FRAGE: Wo kann ich ins besondere zum letzten Punkt (FLOCK ,... und wie man dieses am besten sicherstellt) nähere Informationen finden?
Punkt 4: Datei-Upload.
----------------------
• Überprüfen ob korrektes Dateiformat. Z.B. über die MimeType-Angabe.
• Auf Dateigröße überprüfen. (Beschränkungen der Dateigröße ins Programm fest verdrahten und sich nicht auf 'Hidden-Formular-Fields' mit der gespeicherten Größe verlassen.)
• Alles unter Punkt 3 aufgeführtes.
FRAGE: Die MimeType-Angabe ist doch bestimmt auch nicht gerade die sicherste Methode das Dateiformat zu prüfen, oder? Die wird doch vom Browser mit übergeben, weshalb da im Prinzip doch beliebiges drin auftauchen könnte. Wäre also eine Überprüfung auf Dateiendungen nicht sinnvoller?
Punkt 5: Sonstiges.
-------------------
• Auf Buffer-Overflow achten.
FRAGE: In wieweit Betrifft das noch Scriptsprachen? In PHP z.B. kann man eh keine explizite Größe von Variablen festlegen und zweitens scheinen ihn übergroße Werte nicht zu sonderlich zu stören (Quick-Test von eben) sondern er begrenzt diese Werte automatisch.
FRAGE: Andere Frage, ähnliches Thema. Was ist, wenn ich den Script übergroße Mengen an Daten (z.B. per GET) zuschicke? Glaube irgendwo einmal gelesen zu haben das man damit die Programme wunderbar abschießen können soll. Wenn ja, was kann man dagegen machen? Ist das Script nicht schon gecrasht bevor ich überhaupt dazu gekommen bin eventuelle Prüfungen auf Buffer-Overflows durchzuführen?
• Wichtige (Konfigurations-) Daten (z.B. Paßworte) immer verschlüsseln.
FRAGE: [Nur PHP?] Sollten wichtige (Konfigurations-) Daten nicht in 'ausführbare Dateien' abgelegt werden? Die Nachfrage bezieht sich auf ein (Forums-) Script (in PHP geschrieben) das ich vor einiger Zeit gefunden hatte. Dort hatte der Autor seine ganzen Konfigurationsdaten in einer *.inc Datei als normale Variablen in der Form „$var = wert;" deklariert. (So übrigens auch beim unverschlüsselten Paßwort) Nun soll es aber mit PHP laut Handbuch per 'Include' auch erlaubt sein Dateien auf fremden Servern in seine Scripte einzubinden. Würde das nicht bedeuten das ich mir in aller Seelenruhe diese Datei in mein eigenes Miniscript linken kann, um mir dann alle Werte ausgeben zu lassen? Oder habe ich da im PHP-Handbuch etwas falsch verstanden?
Sollte jemand mit lesen bis hierhin gekommen sein und dann auch noch die Muße finden zu antworten, dann schon einmal im Voraus vielem Dank.
Welche ganz wichtigen Aspekte sind mir also bisher entgangen? Auch Links zu weiterführenden Artikel sind immer gerne willkommen. (Wenn es nicht gerade die unter [1*] genanten sind. Die kenn' ich schon. :o) )
Mfg,
S(*schnarch*)önke
[1*] http://www.xwolf.com/
http://stars.com/Authoring/Scripting/Security/
http://www.go2net.com/people/paulp/cgi-security/safe-cgi.txt