php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 03-03-2009, 22:12
h3llo
 Registrierter Benutzer
Links : Onlinestatus : h3llo ist offline
Registriert seit: Mar 2009
Beiträge: 7
h3llo ist zur Zeit noch ein unbeschriebenes Blatt
Standard Sicherheit und Validierung der Eingabedaten

Hallo

Es soll eine PHP Applikation erstellt werden, dafür habe ich mir nun zuerst einige Gedanken zur Sicherheit und zur Validierung der Eingabedaten gemacht. Die Anwendung soll u.a. einen Userbereich mit einem Anmeldeformular für selbigen enthalten.

Ich möchte folgendermaßen vorgehen:
(Auf dem Entwicklungs- als auch auf dem Zielserver ist magic_quotes_gpc = off)

1) Formulareingaben werden entsprechend des erwarteten Typs geprüft:

- Name: preg_match("/^[a-zA-ZÄÖÜßäöüéèêáàâ&-.\s]$/", $_POST['name']);

- Email: preg_match("/^[A-Z0-9._%+-ÄÖÜäöü]+@[A-Z0-9.-ÄÖÜäöü]+\.[A-Z]{2,6}$/i", $_POST['mail'])

- URL: preg_match("/^(http|https)\:\/\/[a-z0-9-.\/]$/i", $_POST['url'])

- Passwort: Die Speicherung würde als MD5 Hash erfolgen: md5($_POST['password'].$salt)
Hier möchte ich im Prinzip alle erdenklichen Zeichen zulassen, fürchte nur, daß es irgendwelche bösen Zeichen gibt, mit denen ich mir möglicherweise ein Loch ins Script reiße (Beispiel siehe [1]). So gesehen ist es vielleicht sinnvoller, das Passwort auch auf den Zeichenvorrat des Namens einzuschränken.

- Textfeld: preg_match("/^[a-zA-Z0-9-ÄÖÜßäöü.,:!?\s\r\n]$/", $_POST['text'])

Ist es notwendig, vor der Validierung mit preg_match() die Funktion strip_tags() anzuwenden?


2) Wenn die unter 1) genannte Validierung fehlschlägt, wird das Formular erneut mit den bereits eingetragenen, möglicherweise bösen Werten angezeigt. Diese werden vor der Ausgabe noch einmal mit htmlentities() bearbeitet.


3) Wenn alle Eingaben den regulären Ausdrücken entsprechen, werden die Daten in eine MySQL Datenbank eingetragen. Dazu nutze ich die unter [2] genannte erweiterte mysqli Klasse, welche mit Prepared Statements arbeitet.

Bin ich hier wirklich sicher vor SQL Injections oder kann es unter irgendwelchen Umständen trotzdem dazu kommen, so daß weiterhin mit mysql(i)_real_escape_string gearbeitet werden sollte?


4) Ist es ein Risiko, strtolower() auf eine ungeprüfte Variable anzuwenden? Gleiches wäre interessant für die Verarbeitung einer ungeprüften Variable in einer switch/case Anweisung.


5) Ebenso könnte über die superglobale Variable $_SERVER unerwünschter Input eingeschleust werden. Genügt es hier, beispielsweise für den Useragent, addslashes($_SERVER['USER_AGENT']) anzuwenden oder reicht das nicht bzw. wäre eine andere Funktion sinnvoller? Kann auch $_SERVER['REMOTE_ADDR'] gefakt werden und sollte daher erst validiert werden?


Erstmal vielen Dank an alle, die dieses lange Posting bis hier durchgelesen haben
Ich bin für sinnvolle Tips, Anregungen und Ergängzungen zu der beschriebenen Vorgehensweise sowie für die Beantwortung der gestellten Fragen dankbar. Wenn jemand ein sicherheitstechnisches "Problem" entdeckt, beispielsweise ein fälschlicherweise zugelassenes böses Zeichen in einem der regulären Ausdrücke, bin ich ebenfalls für einen Hinweis dankbar.

[1] http://www.phpbb.de/community/viewtopic.php?t=110637
[2] http://www.robpoyntz.com/blog/?p=191
Mit Zitat antworten
  #2 (permalink)  
Alt 03-03-2009, 22:26
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard Re: Sicherheit und Validierung der Eingabedaten

Zitat:
Original geschrieben von h3llo
- Passwort: Die Speicherung würde als MD5 Hash erfolgen: md5($_POST['password'].$salt)
Hier möchte ich im Prinzip alle erdenklichen Zeichen zulassen, fürchte nur, daß es irgendwelche bösen Zeichen gibt, mit denen ich mir möglicherweise ein Loch ins Script reiße (Beispiel siehe [1]). So gesehen ist es vielleicht sinnvoller, das Passwort auch auf den Zeichenvorrat des Namens einzuschränken.
Nein.
Ich wuesste nicht, welche Zeichen das sein sollten.

Wenn man ueberhaupt die zulaessigen Zeichen fuer die Wahl eines Passwortes einschraenkt, dann macht man das aus anderen Gruenden - z.B. koennte man Umlaute verbieten, weil diese problematisch werden, wenn der Nutzer sich mal von einem Rechner mit nicht-deutscher Tastatur aus einloggen will.

Zitat:
Ist es notwendig, vor der Validierung mit preg_match() die Funktion strip_tags() anzuwenden?
Was wuerdest du dir davon versprechen?

strip_tags sollte man meiner persoenlichen Meinung nach "nie" verwenden - es taugt nichts, und macht unter Umstaenden mehr "kaputt", als es hilft.
"Tags" braucht man nicht herauszufiltern - vielleicht will der Nutzer ja irgendwas posten, was HTML-Beispielcode enthaelt, in einem Forum wie diesem hier zum Beispiel - da waere es doch saubloede, wenn das per strip_tags bearbeitet wuerde.

Allerdings sind Zeichen, die in HTML Sonderbedeutung haben, natuerlich entsprechend zu behandeln; Stichwort htmlspecialchars.

Zitat:
2) Wenn die unter 1) genannte Validierung fehlschlägt, wird das Formular erneut mit den bereits eingetragenen, möglicherweise bösen Werten angezeigt. Diese werden vor der Ausgabe noch einmal mit htmlentities() bearbeitet.
Bei Verwendung einer passenden Zeichenkodierung reicht htmlspecialchars aus.

Zitat:
3) Wenn alle Eingaben den regulären Ausdrücken entsprechen, werden die Daten in eine MySQL Datenbank eingetragen. Dazu nutze ich die unter [2] genannte erweiterte mysqli Klasse, welche mit Prepared Statements arbeitet.

Bin ich hier wirklich sicher vor SQL Injections oder kann es unter irgendwelchen Umständen trotzdem dazu kommen, so daß weiterhin mit mysql(i)_real_escape_string gearbeitet werden sollte?
Bei der Nutzung von prepared statements ist das nicht noetig.

Der Grund, warum man mysql_real_escape_string bei einem "normalen" Statement verwendet ist der, dass dort Befehlsbestandteile und Daten "in einem" uebertragen werden, und daher sichergestellt werden muss, dass Daten von der Datenbank-Schnittstelle nicht mit Befehlsbestandteilen verwechselt werden.

Bei prepared statements werden die Daten jedoch getrennt vom Befehlsteil des Statements uebertragen, also muss man sich hier nicht noch extra um sowas kuemmern.

Zitat:
4) Ist es ein Risiko, strtolower() auf eine ungeprüfte Variable anzuwenden? Gleiches wäre interessant für die Verarbeitung einer ungeprüften Variable in einer switch/case Anweisung.
Das "Risiko" bei strtolower auf einen ungeprueften Wert ist, dass du dann die klein geschriebene Version dieses ungeprueften Wertes bekommst. Klingt das sonderlich gefaehrlich ...?

Bei switch/case sollte man natuerlich aufpassen, welche Werte ggf. in den default-Case reinlaufen.
Und auch was die automatische Typkonvertierung von PHP bei Vergleichen unterschiedlicher Datentypen angeht, lauert da manchmal der ein oder andere Fallstrick.

Zitat:
5) Ebenso könnte über die superglobale Variable $_SERVER unerwünschter Input eingeschleust werden. Genügt es hier, beispielsweise für den Useragent, addslashes($_SERVER['USER_AGENT']) anzuwenden oder reicht das nicht bzw. wäre eine andere Funktion sinnvoller?
Ob ein Wert "gefaehrlich" sein kann oder nicht, kommt immer darauf an, was du mit diesem Wert machst.

Die Szenarios, in denen addslashes sinnvoll sein koennte, duerften allerdings verschwindend gering sein. (Das meintest du doch hoffentlich nicht in Bezug auf die Verwendung in einer MySQL-Query?)

Zitat:
Kann auch $_SERVER['REMOTE_ADDR'] gefakt werden und sollte daher erst validiert werden?
Validiert gegen was?


----------

Grundsaetlich gilt beim Umgang mit Daten immer:
Wann immer du einen Wert in einen Kontext ueberfuehrst, musst du ihn kontextspezifisch behandeln.
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #3 (permalink)  
Alt 09-03-2009, 15:03
h3llo
 Registrierter Benutzer
Links : Onlinestatus : h3llo ist offline
Registriert seit: Mar 2009
Beiträge: 7
h3llo ist zur Zeit noch ein unbeschriebenes Blatt
Standard Re: Re: Sicherheit und Validierung der Eingabedaten

Zitat:
Original geschrieben von wahsaga
Ob ein Wert "gefaehrlich" sein kann oder nicht, kommt immer darauf an, was du mit diesem Wert machst.

Die Szenarios, in denen addslashes sinnvoll sein koennte, duerften allerdings verschwindend gering sein. (Das meintest du doch hoffentlich nicht in Bezug auf die Verwendung in einer MySQL-Query?)
Wenn ich den Useragent aus $_SERVER['USER_AGENT'] in der Datenbank speichern wollte, dann sehe ich durch Anwendung von Prepared Statements keinerlei Risiko.
Für die Ausgabe würde ich noch einmal htmlentities() rüberlaufen lassen.
Besteht hier trotzdem noch irgendein Risiko, beispielsweise auch dadurch, daß ich in einer Session mit dem Useragent arbeite (Vergleich Sessionwert <>$_SERVER['USER_AGENT']), der die Anwendung von addslashes erfordert?

Zitat:
Original geschrieben von wahsaga
Validiert gegen was?
Ebenfalls per Regex prüfen, ob nur erlaubte Zeichen drin vorkommen, so daß nichts eingeschleust werden kann.



6) Ich habe unter [1] einen Artikel zur Filterung der Session IDs gelesen. Der Inhalt des Session Cookies kann natürlich auch manipuliert werden. Ich arbeite allerdings nicht direkt mit der Session ID, sondern überlassen dies alleine PHP. Ich arbeite nur mit dem $_SESSION Array, so daß ich keinen wirklichen Grund für die Filterung der übermittelten session_id() sehe. Ist das korrekt oder habe ich dabei etwas übersehen?


7) Beim testen mit folgender Email Regex
PHP-Code:
(preg_match("/^[A-Z0-9._-ÄÖÜäöü]+@[A-Z0-9.-ÄÖÜäöü]+\.[A-Z]{2,6}$/i",$email)) 
fiel auf, daß der Ausdruck bei Angabe einer Testadresse direkt im Script matcht, nicht aber bei Übermittlung des selben Teststrings per Post-Methode.
Beim Post konnte man beispielsweise \n an die Adresse anhängen oder auch mehrere @ Zeichen verwenden und der Ausdruck matchte trotzdem.
Ich sehe zwar keine Grundlage für eine Email Injection, da :, %, & nicht matchen aber eine Erklärung für dieses Verhalten wäre schon interessant.


[1] http://phpperformance.de/session-ids...rmant-filtern/
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

ADSMAN V3 - Werbe-Manager ansehen ADSMAN V3 - Werbe-Manager

ADSMAN V3 - mehr als nur ein Bannermanager! Banner, Textanzeigen und PagePeel Manager! Mit ADSMAN PRO haben Sie die Marketinglösung für eine effektive und effiziente Werbeschaltung mit messbaren Ergebnissen. Unterstützt werden Bannerformate in beliebi

25.10.2018 virtualsystem | Kategorie: PHP/ Bannerverwaltung
PHP News und Artikel Script V2

News schreiben, verwalten, veröffentlichen. Dies ist jetzt mit dem neuen PHP News & Artikel System von virtualsystem.de noch einfacher. Die integrierte Multi-User-Funktion und der WYSIWYG-Editor (MS-Office ähnliche Bedienung) ermöglichen...

25.10.2018 virtualsystem | Kategorie: PHP/ News
Top-Side Guestbook

Gästebuch auf Textbasis (kein MySQL nötig) mit Smilies, Ip Sperre (Zeit selbst einstellbar), Spamschutz, Captcha (Code-Eingabe), BB-Code, Hitcounter, Löschfunktion, Editierfunktion, Kommentarfunktion, Kürzung langer Wörter, Seiten- bzw. Blätterfunktion, V

22.10.2018 webmaster10 | Kategorie: PHP/ Gaestebuch
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 23:01 Uhr.