Sicher Scripten mit PHP!

MC-René

MC-René

Erfahrenes Mitglied
Hallo!

Hab jetzt schon recht viel gelesen bzgl. "sicheres Programmieren" mit PHP... hier im Forum als auch mit :google: ...

Allerdings kann mir vielleicht einer an nem Beispiel erläutern, welchen Vorteil Sessions haben.

Als Beispiel:
- Habe ein Script "daten_form.php" --> Das Formular, als auch ein Script "daten_lesen.php"
- Register Globals sind "off", Daten werden mittels Post übergeben...

daten_lesen.php:

PHP: 
$daten1=$_POST['datenfeld1'];
$daten2=$_POST['datenfeld2'];
//...usw...

//...Variablen noch auf Inhalte prüfen + dann verarbeiten

Wie gesagt, ich habs scheinbar nicht kappiert, aber ich finde die Sicherheitslücke net...

Wer kann mir das mal am Beispiel erklären!?
 
Der Vorteil ist das du die Variablen Inhalte auf deiner ganzen Seite benutzen kannst.

Ich frag mich jetzt nur was wir mit diesem Code Beispiel anfangen sollen, weil wir sehen ja nur wie du Variablen eine andere Variable zuweist.
 
Dem nach es um Sicherheit geht hab ich auch schon die erste Lücke in deine Code endeckt auch wenn es nur 2 Zeilen waren.

Du darf nie was von Aussen kommt ungeprüft reinlassen.Sonst hat der Angreifer die Möglichkeit dir all mögliche werte zu schicken und auch die Db zu Manipulieren

Keine Prüfung
$daten1=$_POST['datenfeld1'];
$daten2=$_POST['datenfeld2'];

Du mußt den Post inhalt voher Prüfen auf gefährlich code elemente und erst dann den Variablen zu ordnen.

Mfg Splasch
 
Zu den 2 Zeilen gab es auch 2 Zeilen Kommtare, wo er auf das Prüfen der Variablen hingewiesen hat!
Allerdings ist gerade diese Prüfung sehr wichtig.


Um sicherzustellen, dass die Daten auch daher kommen, von wo sie kommen sollen, könntest du eine Tabelle erstellen, in der md5-Hashes gespeichert werden. Jedes Forumalr ruft dann die Zielseite mit dem md5 Hash als GET-Parameter auf. 1. Schritt: prüfen ob der md5 Hash in der Tabelle ist, wenn ja, weiter die Variablen prüfen. So sollte zumindest ein Cross-Site-Scripting auf die auswertende Seite unterbunden werden. Evtl. kann man das auch als Hidden-Field machen, wer es schöner findet. Natürlich muss man dann auch nen Garbage-Collector schreiben, der die Einträge nach x Sekunden löscht, wenn kein Submit gekommen ist.
 
Schönen Gruss an die Datenbank, wenn Du mit der Variante "md5-von-jedem-formular" ein Forum auf die Beine stellen willst :D ...denn lieber ein XML-File oder so
 
@RadHad
hmhmmm...
wie willste bitte checken, ob man wirklich die korrekten Daten des echten Formulars von der korrekten Webadresse aus bekommen hat?

Das ist praktisch alles gehupft wie gesprungen. Man baue sich einen Bot, der die Website ausliest und wie ein Browser auch Cookies annehmen kann, Formulare und dessen Hidden-Felder ausliest und zack haste des prob, dass er auch automatisch den MD5-Hash hat. Selbiges geht mit Cookies. Selbiges geht mit Urls und deren $_GET-Parametern.

Du könntest praktisch den Referer auswerten und sagen "Sorry, kein Referer angegeben, ich kann deine Daten nicht durchlassen" - damit sperrst du aber ehrliche Anwender und Besucher deiner Seite aus. Und das nicht wenig, glaub mir^^

Defacto ists nicht zweifelsfrei herauszufinden, von wo die Daten kommen. Einzig was dir bleibt, ist JEDWEDE Daten, die vom Besucher kommen, zu checken, und zwar gründlichst. auch $_SERVER. Nutze kein $_REQUEST. Nutze überwiegend $_POST. Nutze wenig $_GET, nur dann wenns nötig ist. Sichere vor allem die $_GET-Variablen ab, insbesondere da, wo die $_GET (und natürlich alle anderen globalen Variablen) in die Nähe der Datenbank kommen. Speichere in Cookies KEINE Userdaten ab, weder Nicknamen, noch UserID, schon gar keinen Passworthash. Nutze nicht die PHPSession-ID allein, sondern nutze zusätzlich ein eigenes Sessionsystem, dass beide Sessions als Cookie und in der Datenbank abspeichert Wenn nur eine Session nicht stimmt muss der User ausgeloggt werden. Stell eine nicht zu lange Lebensdauer des Cookies ein. "Dauerlogins" sind zwar sehr bequem, aber in der Regel unsicher (insbesondere, wenn man ausschliesslich nur die PHP-SessionID als Identifizierung nutzt und eine XSS-Lücke auf der Seite besteht). Checke alle globalen Variablen auf Javascript-Elemente und iFrames. filtere sie strikt raus (oder alternativ ein die(); ). Sind Bilder beispielsweise in einem Forenbeitrag möglicht musst du per Script checken, ob diese Bilder auch wirklich Bilder sind (per Header-Daten). Nutze den ctracker (http://www.cback.de) um SQL-Injections abzufangen. Nutze mysql_real_escape_string(); für JEDE (!) Variable in einer SQL-Abfrage. Verbiete per Script die Nutzung von register_globals (ich checke per PHP, ob register_globals an ist, falls ja gibts ein die(); ). Lass HTML nicht zu - mit BB-Codes kannste praktisch sämtliche HTML-Funktionen einwandfrei nachbilden und nutzen. Manipulation unmöglich. Wenn du HTML nutzen willst, musst du sämtliche Javascript-Otionen wie onclick, onmouseover, onmousemove etc pp komplett rausfiltern. Tags mit src="" element müssen streng geprüft werden (insbesondere bei Bildern). iFrames komplett verbieten.

Mag Paranoid klingen, aber was andres bleibt einem nicht. In Maßen Paranoid zu sein schadet einem verantwortungsvollen Programmierer nicht.
 
Die genannten Maßnahmen sind auf jeden Fall eine gründliche Überlegung wert. Denn es gibt mehr Fallgruben, in die man unwissend stolpern kann, als man sich denkt. Die Sensibilisierung gegenüber solcher Schwachstellen und das Verständnis der Problematik finde ich dabei fast noch wichtiger als das endgültige Lösen des Problems.
Das Hauptaugenmerk sollte dabei auf der angemessenen Verarbeitung der Benutzereingaben (auch der versteckten) gelegt werden. Denn diese sind die einzige Möglichkeit, eine Anwendung etwas anderes machen zu lassen, als der Entwickler es gewollt hat.
 
Japp, so seh ich das auch. Und bestes Beispiel ist da grad n Anzeigenmarkt mit dem ich arbeite, dürft ich eigentlich gar nicht erwähnen, so brisant ist das. SQL-Inject, XSS, DDoS... das Script bietet praktisch die komplette Palette dessen, was ein Entwickler falsch machen kann. ich kann nur hoffen dass mein eingener Anzeigenmarkt bzw. das gesamte CMS schnell fertig ist...

@Gumbo
ich seh grad du bist moderator, vielleicht kannste das in deinem eigenen "Sicherheitsfokus" da mal ergänzen, denn ich persönlich finds wichtig, dass gerade die obrigen Punkte (die denk ich mal längst nicht alle sind, denn man kann auch noch sagen: "Wenn eine Zahl gefordert ist, dann darf da auch nur ne Zahl ankommen" etc pp) beachtet, nein, berücksichtigt werden. Oder ein komplett neuen "Sicherheitsfokus" erstellen.
 
Zuletzt bearbeitet:
Ich weiß zwar gerade nicht, auf welchen Artikel genau du dich beziehst. Doch ich denke, dass es nicht viel bringt, auf alle Möglichkeiten einzeln einzugehen, da es einfach zu viele gibt. Deswegen habe ich die Artikel auch so allgemein wie möglich gehalten.
Und wie bereits genannt, finde ich es wichtiger, dass der Leser für mögliche Sicherheitslücken ein Gespür entwickelt, als dass für einzelne Fälle eine konkrete Lösung geboten bekommt. Denn dadurch ist es ihm auch möglich, andere Probleme zu lösen, die vielleicht noch gar nicht entdeckt oder für die es noch keine Lösung gibt.

Eine einfache Gegenüberstellung: Welcher Ratschlag wird auf langer Sicht mehr helfen?
  1. MySQL-Injektionen können mit mysql_real_escape_string() verhindert werden.
  2. Für alle zu übergebenden Werte gilt: maskiere die jeweiligen Metazeichen des Zielsystems.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück