nicht angemeldet
Gutes Nächtle Euch allen!
Ja schlafe du auch gut ;)
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?
Konfigdateien sind ein heikles thema, da hier sensible daten drinne-
stehen. Manipulation kannst du aber relativ einfach ausschließen;
Als Schnellschuß würde ich vorschlagen, einen Haswert zu bilden,
speichern und den beim einlesen vergleichen
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'?
Bei $ENV{CONTENT_LENGTH} stelle ich mir schwierig vor. Aber wenn du
den Path benötigst, und dein server feststeht schreibe ihn in deine
Kocfig-Datei. Document Root etc. setze ich meistens von hand.
Punkt 3: Dateien/Dateihandling.
FRAGE: Wo kann ich ins besondere zum letzten Punkt (FLOCK ,... und wie man dieses am besten sicherstellt) nähere Informationen finden?
perldoc -f flock ist recht informativ. In web.pm von xwolf ist ein
anderes und evtl. flexibleres verfahren erklärt. Mir dünkt Wolfgang
Wiese könnte hier mehr wissen ;)
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?
Imho macht der browser zumindest solange er NN heist auch nur den
Suffixtest. IE rät gemessen an SEINEN Maßstäben. Sinn und Unsinn
seien dahingestellt. Wenn ich eine *.pl Datei *.jpg benenne kann sie
trotzdem schaden machen. Letztendlich hängt die sicherheit auch an
der Server-conf (endungs oder verzeichnisbeschränkte Ausführungs-
rechte).
Dateigröße prüfen ist immer wichtig und gut denke ich.
Darüber hinaus will ich eigentlich immer wissen, wer bei mir files
ablegt -> Zugangsbeschränkung
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.
übergib mal ein 4mb binärfile an pack('u',$file). Da wirst du Ärger
bekommen. Wenn die Dateien ein bestimmte größe überschreiten würde
ich 'häppchenweise' vorgehen.
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?
Etwas Mathe:
Priviligierte haben max. 128kB/s Upload. Viel Server habe 90s Timeout
für scripte. 128*90/8 = 1.3MB -> sollte machbar sein.
Alles andere würde ich mit
if ($ENV{CONTENT_LENGTH} > 1000000) {
exit;}
oder ähnlich abfangen.
• 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?
Wie du vielleicht bemerkt hast ist php nicht meine stärke.....
Weiß ich nicht.
Aber denk mal über folgendes nach. Passworte kann =~ s/kann/sollte/g
man hashen. Wenn du aber Konfiguration verschlüsselst, musst du
irgendwo deinen Key ablegen oder jedesmal vom client senden lassen,
der dir was husten wird.
Hier muss halt für gute sicherung deines cgi-bin gesorgt sein.
HTH
Bye Ed X