Sicherheit, Filtern von Benutzereingaben nach Sonderzeichen

Hallöchen,

während meiner Überlegungen zur Gestaltung meiner Webseite kam ich an dem Sicherheitsaspekt nicht vorbei.

Ich verwerte Benutzereingaben von Formularen und übergebe teilweise Werte per GET.

Da kam mir der Gedanke "Warum mysql_real_escape usw. verwenden, wenn ich auch einfach die übergebenen Werte auf Sonderzeichen überprüfen kann und bei Vorhandensein kritischer Zeichen eine Fehlerausgabe erzeuge und die Abarbeitung des Scripts abbreche?"

Mir schwebt da eine Verwendung von einem Schnippsel wie

PHP-Code:

function keinesonderzeichen($string)
  {
    if (ereg('[!"§$%&/()=?`´\/,\']', $string ) )
    {
    return true;
    }
  } 


vor.
Suchpattern ist nicht vollständig.
Daher meine Frage an euch: Hinkt mein Gedanke?

Danke im Voraus und viele Grüße,

Boris

mysql_real_escape_string beachtet das Charset der DB-Verbindung. Das macht deine Funktion nicht. Außerdem: Warum das Rad neu erfinden? PHP bietet eine Funktion, die genau das macht, was du brauchst. Es hat absolut keinen Sinn, diese Funktion zu ignorieren und es selbst zu implementieren.

Hallo,

Zitat von Ghostrider28

Hinkt mein Gedanke?

Ja und zwar im Zusammenhang mit Multibyte-Zeichen. Nimm auf jeden Fall mysql_real_escape_string!

Weitere Infos findest du über das Stichwort „SQL Injection“.

Gruß,

Amica

Zitat von onemorenerd

Warum das Rad neu erfinden? PHP bietet eine Funktion, die genau das macht, was du brauchst.

Welche wäre das?

Auf php.net habe ich diese Klasse gefunden, bringt die soweit mit, was mir meine Variablen auf ein erträgliches Maß absichert?

PHP-Code:


<?php

class secure
{
    function secureSuperGlobalGET(&$value, $key)
    {
        $_GET[$key] = htmlspecialchars(stripslashes($_GET[$key]));
        $_GET[$key] = str_ireplace("script", "blocked", $_GET[$key]);
        $_GET[$key] = mysql_escape_string($_GET[$key]);
        return $_GET[$key];
    }
    
    function secureSuperGlobalPOST(&$value, $key)
    {
        $_POST[$key] = htmlspecialchars(stripslashes($_POST[$key]));
        $_POST[$key] = str_ireplace("script", "blocked", $_POST[$key]);
        $_POST[$key] = mysql_escape_string($_POST[$key]);
        return $_POST[$key];
    }
        
    function secureGlobals()
    {
        array_walk($_GET, array($this, 'secureSuperGlobalGET'));
        array_walk($_POST, array($this, 'secureSuperGlobalPOST'));
    }
}

?>

Zitat von Ghostrider28

Welche wäre das?

mysql_real_escape_string()


… zumindest für die Verwendung von Benutzereingaben in MySQL-Queries.

Zitat von Ghostrider28

Welche wäre das?

Wie schon gesagt: mysql_real_escape_string.

Zitat von Ghostrider28

Auf php.net habe ich diese Klasse gefunden, bringt die soweit mit, was mir meine Variablen auf ein erträgliches Maß absichert?

Das ist ganz großer Käse. Man escapet immer nur für den konkreten Kontext.

Also keine "Allroundklassen- und Lösungen" verwenden und lieber situationsbezogen vorgehen?

Bevor ich eure Antworten gerade gelesen habe, hatte ich mir schon einen Teil der Klasse umgepfriemelt.

PHP-Code:

function sichern($string)
{
$result = htmlspecialchars(stripslashes($string);
$result = str_ireplace("script", "blocked", $result);
$result = mysql_escape_string($result);
return $result;
} 


Ich bitte um Entschuldigung, wenn ich im Umgang mit Sicherheit etwas unbeholfen wirke, ich habe ehrlich gesagt ignoriert, mich damit zu beschäftigen. Und das rächt sich jetzt.

Sicherheit erreichst du nicht, indem du alle Eingaben am Anfang des Scripts prüfst, bereinigst oder löschst. Denn eine Eingabe kann in einer Situation harmlos sein und in einer anderen höchst gefährlich. Kontext eben …

Das Problem an diesen „Allroundlösungen“ ist z. B., dass der Text

Dann können Sie innerhalb der <description>-Tags eine Beschreibung angeben. Per 'Copy&Paste' kann der Eintrag...

dann so in der DB steht und da hat niemand was davon, außer Problemen:

Dann können Sie innerhalb der &lt;deblockedion&gt;-Tags eine Beschreibung angeben. Per &apos;&apos;Copy&amp;Paste&apos;&apos; kann der Eintrag...

Zitat von onemorenerd

Sicherheit erreichst du nicht, indem du alle Eingaben am Anfang des Scripts prüfst, bereinigst oder löschst. Denn eine Eingabe kann in einer Situation harmlos sein und in einer anderen höchst gefährlich. Kontext eben …

Wenn ich nun aber eine Variable bzw. deren Inhalt bereits am Anfang entschärft habe, warum sollte sie dann wiederrum später gefährlich werden können?

Der Zusammenhang ist mir noch nicht ganz klar ;-)

Belies dich über Kontextwechsel, SQL-Injection, E-Mail-Injection, da bekommst du einen guten Überblick.

Zitat von Ghostrider28

Da kam mir der Gedanke "Warum mysql_real_escape usw. verwenden, wenn ich auch einfach die übergebenen Werte auf Sonderzeichen überprüfen kann und bei Vorhandensein kritischer Zeichen eine Fehlerausgabe erzeuge und die Abarbeitung des Scripts abbreche?"

Weil es schlichtweg einfach nur idiotisch wäre, zu sagen, dass bspw. ein Anführungszeichen ein „kritisches Zeichen“ wäre, und dann die Verarbeitung abzubrechen.

Dann könnte nie überhaupt ein Text eingetragen werden, der ein Anführungszeichen enthält - hier im Forum würde das bspw. heissen, dass wir die meisten PHP-Probleme gar nicht diskutieren könnten.

Bei mir wäre aber der Kontext, dass es auf meiner Webseite keinen Bereich gibt, in denen Sonderzeichen, auch wenn es nur ein " ist, eingegeben werden sollen.

Dass es in einem Forum schlichtweg Blödsinn wäre, ist mir klar. Bei mir jedoch kommt der User nicht in die Verlegenheit, irgendwas, außer einen Login, der aus einer Verkettung von Ziffern besteht und einem Passwort einzugeben.

Ledigleich für das Passwort würde ich einige Sonderzeichen erlauben. Aber im Endeffekt, wenn ausser beim Passwort niemals ein Sonderzeichen zum tragen kommt, spricht doch nichts dagegen, wenn ich einfach alle Sonderzeichen aussortiere, oder?

Zitat von Ghostrider28

spricht doch nichts dagegen, wenn ich einfach alle Sonderzeichen aussortiere, oder?

Aber nur in diesem Fall! Es besteht aber dann die Gefahr, dass du beim nächsten Projekt denkst, dass du das wiederverwenden könntest.

Nein, nein, um Gottes Willen.

Ich habe das schon verstanden, ich habe die oben genannten Beispiele eigentlich nur auf meine aktuelle Seite bezogen. Vielleicht wäre es klüger gewesen, wenn ich gleich gesagt hätte, dass nur wenige vom User selbst zu tätigende Eingaben vorhanden sein werden.