Thema: Sicherheit

[Hennieliminator]

Hallo,
ich beschäftige mich schon seit einigen Jahren mit PHP habe allerdings noch nie wirklich auf "Sicherheit" geachtet... Dies wollte ich nun mal tun. Wo bestehen in PHP sicherheitslücken?
Klar in nutzereingaben und URL parametern...
Man kann nur bestimmte URL parameter oder nutzereingaben zulassen...
Aaber was gibt es noch?
Ich mein das komplett allgemein...
Freue mich über jeden Beitrag der eine mögliche sicherheitslücke schließen könnte ...

MfG
Hennieliminator

[Falk Prüfer]

Hallo Hennieliminator,

wirkliche PHP-Sicherheitslücken sollte es in den aktuellen Distributionen von PHP nicht geben. Das Problem ist doch eher: Welche Sicherheitslücken baut der Programmierer (in seiner Sorglosigkeit/Unwissenheit) in seine PHP-Anwendungen ein. RegisterGlobals ist z.B. KEINE Sicherheitslücke in PHP - es ist ein Feature. Allerdings KANN es zum erheblichen Sicherheitsrisiko werden, wenn es in "schlampig" programmierten Anwendungen genutzt wird.
Und genau das ist es was es schwierig macht "Sicherheitslücken" in PHP zu benennen. Falsch eingesetzt können viele Funktionen von PHP zum Sicherheitsrisiko werden.
Prinzipiell sollte man als Programmierer einfach ein paar "Grundregeln" beachten:

• Belege alle Variablen vor ihrer ersten Verwendung selbst vor
• Mistraue jedem Inhalt der von "draußen" (Post-, Get-Variablen, Cookies, etc.) kommt
• Verlasse dich nicht auf die Eingabeprüfung durch JavaScript
• Setze Techniken mit erhöhtem Gefahrenpotenzial (Systemaufrufe, Dateimanipulation, Upload, etc.) mit Bedacht ein
• Schütze Include-Dateien vor direktem Aufruf oder Auslesen
• Nutze die Sicherheitseinstellungen von PHP - was damit nicht funktioniert ist potenziell gefährlich
• Vermeide den Einsatz fremder/ungeprüfter Scripte oder Snippets
• ...

Die Liste ist mit Sicherheit unvollständig und läßt sich beliebig erweitern .

Gruß Falk

[Hennieliminator]

danke^^ einen Teil davon beachte ich schon, einen anderen wiederum nicht.. Ich denke das wird mir weiterhelfen :P *sauberer Programmieren muss*

MfG
Hennieliminator

[Creator1981]

Hallo,

wenn du mit Datenbanken zusammenarbeitest ( bzw: MYSQL ) dann achte immer auf SQL Injektion.

Wenn du mit PHP Mails versenden musst ist da auch Vorsicht geboten.
Um kein Spamer zu werden, kann ich dir die PHPMailer Klasse empfehlen.
Kenne nicht besseres.

SSL möchte ich auch noch erwehnen, damit wird die Communication zwischen Client und Server verschlüsselt. So kann der jenige der zuhört mit den Daten nix anfangen.
Ist allerdings Kostenpflichtig. Für z.b. ein Shopsystem aus meiner sicht aber Pflicht.

Wenn du mit Sessions arbeitest, gibt es da auch einiges zu beachten, allerdings verringert das den Comfort der Seiten bedienung.
Hier musst du dann je nach Projekt entscheiden, was wichtiger ist.

[Johny]

Im letzten PHP Magazin war nen guter Grundlegender Artikel über Security im Sonderheft von der rückseite aus gelesen, den solltest du unbedingt mal Lesen.

[ins0]

Hallo Hennieliminator,

wirkliche PHP-Sicherheitslücken sollte es in den aktuellen Distributionen von PHP nicht geben. Das Problem ist doch eher: Welche Sicherheitslücken baut der Programmierer (in seiner Sorglosigkeit/Unwissenheit) in seine PHP-Anwendungen ein. RegisterGlobals ist z.B. KEINE Sicherheitslücke in PHP - es ist ein Feature. Allerdings KANN es zum erheblichen Sicherheitsrisiko werden, wenn es in "schlampig" programmierten Anwendungen genutzt wird.
Und genau das ist es was es schwierig macht "Sicherheitslücken" in PHP zu benennen. Falsch eingesetzt können viele Funktionen von PHP zum Sicherheitsrisiko werden.
Prinzipiell sollte man als Programmierer einfach ein paar "Grundregeln" beachten:

• Belege alle Variablen vor ihrer ersten Verwendung selbst vor
• Mistraue jedem Inhalt der von "draußen" (Post-, Get-Variablen, Cookies, etc.) kommt
• Verlasse dich nicht auf die Eingabeprüfung durch JavaScript
• Setze Techniken mit erhöhtem Gefahrenpotenzial (Systemaufrufe, Dateimanipulation, Upload, etc.) mit Bedacht ein
• Schütze Include-Dateien vor direktem Aufruf oder Auslesen
• Nutze die Sicherheitseinstellungen von PHP - was damit nicht funktioniert ist potenziell gefährlich
• Vermeide den Einsatz fremder/ungeprüfter Scripte oder Snippets
• ...

Die Liste ist mit Sicherheit unvollständig und läßt sich beliebig erweitern .

Gruß Falk

sehr schön wiedergegeben

• Typen-Definition von Werten ( integer, etc... bsp."Evil Null-Byte") vor ihrer Verwendung

mehr fällt mir so spontan auch nicht ein.... ein großes Spektrum von Falk wurde abgedeckt

grüße Marco

[Herbert Rotke]

RegisterGlobals ist z.B. KEINE Sicherheitslücke in PHP - es ist ein Feature. Allerdings KANN es zum erheblichen Sicherheitsrisiko werden, wenn es in "schlampig" programmierten Anwendungen genutzt wird.

Sorry, aber da stimme ich dir nicht zu. Es wurde zu gutem Grund seit PHP3 standardmaessig bei Installation ausgeschaltet und wird vorraussichtlich auch von PHP6 nicht mehr unterstuetzt (siehe auch hier).
Meiner Ansicht nach ist jegliche Verwendung bedenklich, bin aber neugierig und auch auch evtl. lernwillig, wie Du Dir eine sichere Verwendung davon vorstellst? Validation?

Ich bin der Meinung, dass register_globals ein Feature ist, das eine Sicherheitsluecke ist

[Falk Prüfer]

Meiner Ansicht nach ist jegliche Verwendung bedenklich, bin aber neugierig und auch auch evtl. lernwillig, wie Du Dir eine sichere Verwendung davon vorstellst? Validation?

Mit Validation hat das nichts zu tun! Validieren muß ich auch, wenn ich keine global registrierten Variablen verwende, sondern den expliziten Weg über $_GET bzw. $_POST gehe. Das gefährliche an register_globals ist, daß jede in einem globalen Kontext verwendete Variable von außen manipuliert werden kann - auch die die der Programmierer gar nicht als Post- oder Get-Variable vorgesehen hat.
z.B. Unsicher:

...
if (isset($param1) && $param1 == 'set') // $param1 ist eine gewünschte "register_globals"
  $setParam = 1;  // $setParam ist eigentlich nur als "interne" Variable gedacht
...
if ($setParam) {
  geheimeFunktion($param2); // $param2 ist eine gewünschte "register_globals"
}
... 

Die geheimeFunktion kann hier auch dadurch aufgerufen werden, daß ein (eigentlich nicht angedachter) Parameter setParam=1 an die URL angehängt wird.
dagegen sicher:

...
$setParam = 0; // $setParam ist eine "interne" Variable und wird VOR der ersten Verwendung initialisiert
if (isset($param1) && $param1 == 'set') // $param1 ist eine gewünschte "register_globals"
  $setParam = 1;  // $setParam ist eigentlich nur als "interne" Variable gedacht
...
if ($setParam) {
  geheimeFunktion($param2); // $param2 ist eine gewünschte "register_globals"
}
... 

Der Angriff mit setParam=1 in der URL ist hier nicht mehr möglich. Durch die Abschaltung von register_globals und die explizite Verwendung $_GET bzw. $_POST wird der Programmierer lediglich gezwungen sauber zwischen "internen" und "externen" Variablen zu trennen. Möglich wäre dies jedoch auch mit aktiviertem register_globals - aber zugegebenermaßen sehr viel schwieriger .

Ich bin der Meinung, dass register_globals ein Feature ist, das eine Sicherheitsluecke ist

register_globals war sicherlich als nette Vereinfachung und Feature gedacht, welches sich jedoch schnell als Sicherheitsproblem herausgestellt hat, da es eben "schlampig" verwendet wurde.
Durch Schlampigkeit und Unaufmerksamkeit passieren jährlich zigtausend Unfälle mit Leitern im Haushalt - sind Leitern deshalb gefährlich und ein Sicherheitsproblem?

Gruß Falk

[Herbert Rotke]

Hello Falk,
ja, ich kann nachvollziehen, was Du gerade genannt hast. Aber dabei hast du etwas Wichtiges vergessen...

1. $_POST und $_GET sind nur 2 Beispiele fuer die register_globals relevant ist und es sind zugegebenermassen die, bei denen die Sicherheit fast keine Rolle spielt, denn wie Du schon sagst, validieren muss ich sowieso und ich kann POST und GET variablen allzu leicht im Browser manipulieren.
   Also - wo bleibt dann der Benefit von register_globals in $_POST und $_GET wenn ich sowieso validieren (und register_globals sogar initialisieren!) muss?

1. Dieser Punkt ist jedoch viel wichtiger: Du hast $_SESSION und $_COOKIE ausgelassen und eben diese stellen den Hauptangriffspunkt bei register_globals dar. Du kannst sie NICHT mit einem Standard-Wert initialisieren und moechtest auf keinen Fall, dass jemand von seitens des Browsers deren Werte veraendert. Genau dies ist hier moeglich und meines Wissens nach gibt es keine Moeglichkeit genau dieses zu vermeiden. Alle Vorschlaege diesbezueglich sind Katz-und-Maus Spiel mit dem Angreifer, bestenfalls workarounds. Warum dann nicht gleich $_SESSION verwenden? Ist nicht in Wirklichkeit $_SESSION und $_COOKIE das feature?

Durch Schlampigkeit und Unaufmerksamkeit passieren jährlich zigtausend Unfälle mit Leitern im Haushalt - sind Leitern deshalb gefährlich und ein Sicherheitsproblem?

Leitern sind gefaehrlich und ein Sicherheitsproblem, ja - jedoch nicht nur durch Schlampigkeit, sondern auch durch externe Einfluesse.
Ich moechte jetzt nicht ueber Leitern streiten, aber ich finde Dein Vergleich hinkt, da er auf dieser These aufsetzt

Lass mich mal folgenden Vergleich anfuehren...

Angenommen Du hast eine Holzleiter von der Du weisst, dass der Rahmen und die Sprossen jederzeit bersten koennen.
Wenn Du nun die Holz-Sprossen absaegen, und Alu-Schienen auf den Rahmen nieten musst, die Leiter an das Dach annageln musst und jemanden brauchst, der Dich am oberen Ende mit einem Seil hochzieht um Dich sicher zu fuehlen...
Ist das dann noch immer eine Leiter und warum hast Du dann nicht gleich eine Aluleiter mit Wiederhaken und Seil-Absicherung verwendet?
Klar, Du findest mit beiden Leitern auf's Dach, aber warum darf ich dann die Holzleiter nicht als "unsicher" bezeichnen?

Gruesse,

Herbert

[Falk Prüfer]

Hallo Herbert,

ich will mich nicht mit dir über das Thema RegisterGlobals streiten! (Mein Bsp. gilt übrigens nicht nur für Post- und Get- sondern auch für Cookie- und Sessionvariablen, da ich immer nur von "gewünschte register_globals" gesprochen habe) Mglws. war das Bsp. mit der Leiter jedoch etwas unglücklich gewählt. Aber ich bin trotzdem der Meinung das nicht das Feature RegisterGlobals die Sicherheitslücke ist, sondern die konkrete Umsetzung in einer Anwendung. Daran ändert auch die Tatsache nichts das ich persönlich RG für gefährlich halte (evtl. sind wir uns ja hierbei einig ), weil man eben als Programmierer allzu leicht einen Fehler machen und Sicherheitslücken programmieren kann.

Neues Beispiel: Wer ist hier die Sicherheitslücke? Der Tempomat oder der Typ der nach dem Einschalten desselben in den hinteren Teil seines Wohnmobils gegangen ist, um sich einen Kaffee zu kochen und sich gewundert hat als sein Wohnmobil von der Straße abkam und sich überschlug? (siehe hier auf Platz 1)

Gruß Falk

[Herbert Rotke]

Hi Falk,

Daran ändert auch die Tatsache nichts das ich persönlich RG für gefährlich halte (evtl. sind wir uns ja hierbei einig )

gut! Lass uns auf den Punkt beharren, dass wir nun einen Punkt gefunden haben, indem wir uns einig sind

Hehehe, der Stella Liebeck Preis ist immer nen Blick Wert, wenn man gelangweilt ist - aber ich muss zugeben... dieses Jahr ist er besonders gut und ich stimme total zu, dass der Tempomat Typ auf Patz 1 muss
Dennoch - mich macht der Preis immer traurig, da er davon zeugt, dass man in den Staaten gegen ALLES klagen kann... mir tun dabei die Unternehmen leid: Zum Beispiel der Restaurantbesitzer in Pennsylvania, der fuer die Dummheit einer Besucherin $113.500 zahlen muss und dagegen im Prinzip ueberhaupt nichts unternehmen kann - nunja. ausser in Zukunft ein Schild aufzuhaengen:

"Wir haften nicht fuer Schaeden verursacht durch Speisen und Getraenke die mutwillig auf den Boden geschuettet wurden"

... selbstverstaendlich FALLS er genug Geld hat, den Laden nicht dichtzumachen.

Gruesse,

Herbert