Sicherheitstechnisch verschiedene Eingaben filtern

[Forumsgast]

Hallo,

ich stehe vor dem Problem, dass ich verschiedene Eingaben filtern muss bezüglich deren Sicherheit. Dabei sind mir grundsätzlich folgende Varianten eingefallen:

1. Zahlen:
Die Eingabe soll eine einfache Zahl wie 4,55345,334 oder so sein. -> zur Sicherheit durch intval() durchjagen und schon sind böse Eingaben zerstört.

2. Begriffe ohne Leerzeichen:
Begriffe wie "delete", "neu", "edit" oder auch "de-at" sollen gefiltert werden. -> ?

3. Text mit Leerzeichen:
Eine Eingabe der Form "Hier ist es schön" zum Beispiel. -> ?

4. ganze normale Texte:
Ganz normale Texte mit Leerzeichen, Leerzeilen....... -> ?

Gesamt stellt sich auch die Frage, ob zum Beispiel immer in den MySQL-Befehlen ein addslashes() bei jeder Eingabe Sinn macht. Denn damit wird ja selbst bei nem Versuch von einer SQL-Injektion einfach dieser SQL-Code in der DB als Text gespeichert.

Gibts sonst noch paar Sicherheitstipps?

Dankeschön, denn ich möchte mir für ein CMS ein Gesamtsicherheits-System überlegen und deswegen diese Grundsatzfragen.

[Forumsgast]

Hi,

PHP: mysql_real_escape_string - Manual ?

[Forumsgast]

Ich verstehe nicht ganz, was du in Beispiel zwei bis drei meinst.

PHP Security Consortium: Projects

[Forumsgast]

1. Zahlen:
Die Eingabe soll eine einfache Zahl wie 4,55345,334 oder so sein. -> zur Sicherheit durch intval() durchjagen und schon sind böse Eingaben zerstört.

4,55345,334 das ist ein Sting und kein Integer.

Gesamt stellt sich auch die Frage, ob zum Beispiel immer in den MySQL-Befehlen ein addslashes() bei jeder Eingabe Sinn macht. Denn damit wird ja selbst bei nem Versuch von einer SQL-Injektion einfach dieser SQL-Code in der DB als Text gespeichert.

Verwende immer mysql_real_escape_string, da diese Funktioniert mehr escapt als addslashes().

Bei 2 und 3 kann ich kein problem erkennen.

4. ganze normale Texte:
Ganz normale Texte mit Leerzeichen, Leerzeilen....... -> ?

Hier musste du bei der Ausgabe auf sonderzeichen achten.
Da man sonst z.b. JS Code einschleusen kann.

htmlspecialchars

Du musst alles zu 100% Validieren, was vom Client kommt. Egal ob es $_POST, $_GET, $_COOKIE oder JS ist. Alles kann böse Inhalte haben.

Bei Sessions wird das ganze dann recht Kompliziert. Sessions können übernommen werden.
Es können vom User ausversehen Links mit der Session_id verteilt werden.
Cookies können übernommen werden usw.

Hier muss man dann abwiegen wie viel sicherheit man braucht und wieviel Usability man bieten möchte.

[BartTheDevil89]

Hi,

vielen Dank für die Hilfe.

Also ich fasse mal zusammen:

1. Zahlen:
Mit 5,345345,454 waren halt die Zahlen 5 und 345345 und 454 zum Beispiel gemeint. Und die werf ich doch am einfachsten durch intval durch.

2. Begriffe ohne Leerzeichen:
Einfach durch mysql_real_escape_string durch und gut...

3. Text mit Leerzeichen und 4.:

Durch htmlspecialchars durch und dann eben noch mysql_real_escape_string.

Und ansonsten alles, bis auf Fall 1 mit den Zahlen, was in eine DB reinkommen soll, durch mysql_real_escape_string durchjagen. Hab mir da auch noch bisschen was durchgelesen und hab gefunden, dass von wenigen Ausnahmen der Fall ist. Aber jetzt mal im Ernst....was könnte so eine Ausnahme sein?

Die Validierung jeglicher Eingaben, aber auch COOKIE,_SERVER-Wert, etc. müssen natürlich gemacht werden. Deswegen überleg ich mir eben ein komplettes System.

Also passt meine Übersicht jetzt oder sollte noch was mit gemacht werden?

Dankeschön

[Forumsgast]

mysql_real_escape_string reicht vollkommen beim Speichern.

Beim Ausgeben von Benutzereingaben anstelle von htmlspecialchars htmlentities verwenden. Nicht beim Speichern in der DB (wenn du alles auf utf-8 gestellt hast, kriegst da auch keine Probleme)

string htmlentities ( string $string [, int $quote_style= ENT_COMPAT [, string $charset [, bool $double_encode= true ]]] )
Die Funktion ist komplett identisch zu htmlspecialchars(), allerdings wandelt htmlentities() wirklich alle Zeichen, die eine HTML-Code-Entsprechung haben, in diese Entsprechung um.

[Forumsgast]

Durch htmlspecialchars durch und dann eben noch mysql_real_escape_string.

Ich würde immer alles ungefiltert in die Db schreiben. Mit der ausnahme von mysql_real_escape_string.

Man kann nie wissen, wie man die Daten noch verarbeiten muss.
Beispiel:
Wenn man BB Code verwendet, würde ich diesen Text ungeparst in die db schreiben, weil du nie wissen kannst ob beim Parsen mal änderungen gemacht werden müssen.

Machst du das vor dem Speichern in der Db und hast schon 100.000 Datensätze muss du dir wieder was einfallen lassen.

[BartTheDevil89]

OK gut...und würdet ihr das mysql_real_escape_string im speichern in der DB verwenden, oder sobald die mit $_POST oder so übergeben wird?

[Forumsgast]

Du mußt mysql_real_escape_string schon in Zusammenhang mit der db resource verwenden.
Sprich am Script Anfang ein array_map("mysql_real_escape_string",$_POST), ohne vorher die db Verbindung zu initialisieren, macht gar keinen Sinn.

Also in den query string rein und du machst nichts verkehrt.


Gruß

[BartTheDevil89]

Achso ok....also grundsätzlich meinst du so?

$data = $_POST['data'];
//hier passiert etwas mit den Daten, die beispielsweise durch if-abfragen gezogen werden
mysq_query("insert into db set data = '"mysql_real_escape_string($data).."'"); 

So oder soll ich das schon irgendwie vorher durchziehen? Denn da finden vielleicht noch if-Abfragen oder so mit der $data-Variable statt.

[Forumsgast]

Naja ich würde das Feld selbst noch prüfen. Das mysql_real_escape_string hast schon richtig eingesetzt im Query.

Ich würde vorher aber die Variablen noch mit

if(get_magic_quotes_gpc() ==1 && get_magic_quotes_runtime())
{
      $data = stripslahes($data);
} 

und das auch gleich nachdem du die Variablen zugewiesen bzw. initialisiert hast.

[BartTheDevil89]

Hi....achso, also doch noch durch paar Funktion durchjagen? Welche würdest du denn jeweils bei meinen Fällen empfehlen? Also bei ner Zahl halt einfach intval() aber bei den anderen?