PHP Klasse zum säubern von _POST - Werte zu oft enthalten

Blackbenji

Lieutenant
Registriert
Nov. 2009
Beiträge
565
Hallo,

ich wollte mir eine Klasse zum säubern von _POST schreiben. Das Problem ist nur, dass die Ausgabe zu viele Werte enthält.

PHP:
class Cleaner {

    public $input = array();
    public $cleaned = array();

    public function cleaner() {
        foreach($_POST as $key => $value) {
            $this->cleaned[] = $this->cleanValue($key,$value);
        }
        return $this->cleaned;
    }

    private function cleanValue($key,$value) {
        if (get_magic_quotes_gpc()) {
            $this->input[$key] = stripslashes($value);
        }
        $this->input[$key] = strip_tags($value);
        $this->input[$key] = htmlspecialchars($value, ENT_QUOTES);
        $this->input[$key] = trim($value);
        return $this->input;
    }
}

HTML:
array(4) {
  [0]=>
  array(1) {
    ["email"]=>
    string(4) "test"
  }
  [1]=>
  array(2) {
    ["email"]=>
    string(4) "test"
    ["password"]=>
    string(4) "testpw"
  }
  [2]=>
  array(2) {
    ["email"]=>
    string(4) "test"
    ["password"]=>
    string(4) "testpw"
  }
  [3]=>
  array(2) {
    ["email"]=>
    string(4) "test"
    ["password"]=>
    string(4) "testpw"
  }
}

Enthalten sollte natürlich nur einmal email -> test, password -> testpw, und nicht 4 einträge.
 
Zuletzt bearbeitet:
wie rufst du das denn auf ?

und ohnehin stimmt doch da schon was nicht, der sagt der die länge vom wert von passwort ist 4, aber wenn ich nicht ganz blöd bin besteht 'testpw' aus 6 zeichen.

lass dir doch mal bei jeder iteration ausgeben was er an die funktion übergibt und was diese anschließend zurück gibt.

ein anderer "fehler"

du gibts immer den ganzen array zurück bei cleanValue.

Das heißt dein cleand[] array bekommt bei jeder iteration auch alle zuvor geparsten werte zurück.

EInmal post ausgeben lassen, sieht so aus als würde die werte 2 mal übertragen

P.S.
würde es mysql_real_escape string, einmal angewandt auf alle $value nicht auch tun?
 
Zuletzt bearbeitet:
auch wenn mir nicht ganz klar ist wieso der 4 mal iteriert.....
aber solange es nun geht.
 
Warum überhaupt säubern? Du solltest die Werte so wie sie übergeben wurden, übernehmen. Dann eben nur sicherstellen, dass keine SQL-Injection möglich ist (Prepeared Statements) oder eben keine XSS-Lücke entsteht (htmlspecialchars). Aber sicher nicht einfach erstmal alles wegfiltern. Wenn ich ein Kommentar in diesen Thread posten will und der enthält HTML, dann möchte ich auch, dass der HTML-Markup da angezeigt wird und nicht einfach verschwindet (strip_tags).

Vor allem ist das kein Schutz, denn du musst trotzdem vor SQL-Injections schützen oder jede Ausgabe escapen, wenn strip_tags mal versagt. Von dem ich in der Vergangenheit mehr als genug Exploits gesehen habe.
 
ohne zu wissen wozu das benötigt wirst lehnst du dich da aber ein wenig weit aus dem Fenster. Könnte druchaus seine gründe haben ALLES wegzufiltern.....

sowas z.b. ist deer grund wieso ich das forum gewechselt habe und nur noch sporadisch vorbei schaue, hier wird immer gleich drauf gehaun, jeder glaub die weisheit mit Löffeln gefressen zu haben haut ein kommentar nach dem anderen raus der mit dem eigentlichen Thema schon nichts mehr zu tun hat.

das es alles nur liebe nette ratschläge sind ist auch kaum vorstellbar bei den tönen die hier angeschlagen werden, die sind i.d.r. ziemlich bewertend und abwertend, so als müsste man alles von haus aus wissen - was dieses Forum dann allerdings überflüssig machen würde....
 
Zuletzt bearbeitet:
Mercsen schrieb:
ohne zu wissen wozu das benötigt wirst lehnst du dich da aber ein wenig weit aus dem Fenster. Könnte druchaus seine gründe haben ALLES wegzufiltern.....
ähhh.....nein!
Wenn jemand etwas eingibt, dann gibt er es ein, fertig! Wenn ich dir eine Nachricht schicken möchte, deren Titel HTML-Code enthält, dann ist das so. Und warum solltest du jedes HTML-Sonderzeichen schon escaped in die DB speichern? Wenn ich etwas speichere und wieder lade, erwarte ich auch, dass das gleiche rauskommt. Nicht dass nachher ein Script mir die ganze Formatierung und alles verhauen hat, weil ich jemandem Schreiben wollte wie er X in HTML macht.
Wenn ein Int in der DB kein HTML sein soll, ist das klar. Das muss aber validiert werden. Einfach mal pro-Forma alles zu escapen mit einigen möglichen Escaping-Operationen (SQL-Injection + XSS) soll ganz klar eine Schutzfunktion darstellen, das ist es aber nicht, und geht vollkommen an dem gesetzten Ziel hinaus.
 
@ice-breaker: html soll einfach nicht genutzt werden. es gibt einen bbcode-ersatz.
mysql_real_escape_string() wird hier nicht eingesetzt, weil nicht jedes feld davon nutze trägt. mysql_real_escape_string() wird vor dem speichern/abfragen in/an die db genutzt.
gibt es sonst noch möglichkeiten um die sicherheit zu erhöhen?
 
Aber wenn ich HTML eingebe (wie auch hier im Forum), dann möchte ich, dass es als Text angezeigt wird. Der Bbcode ist dann dafür da, wenn ich speziell etwas formatieren will. Und nicht einfach den Text weglöschen (strip_tags).

Du willst die Sicherheit erhöhen? Lass den "Mist" da weg. Und mach ein htmlspecialchars beim Ausgeben des Datensatzes und ein mysql_real_escape_string beim Speichern der Information. DAS ist das richtige Vorgehen. Du schützt dich damit gegen SQL-Injections und XSS, trotzdem bleibt der ganze Inhalt erhalten usw.
 
@icebreaker
dein ansatz ist schon richtig, aber richtigen code abzuspeichern halte ich persönlich für unvorteilhaft, daher gibt es ja den bbcode ;)
 
Zuletzt bearbeitet:
Wieso sollte das unvorteilhaft sein? Mir fallen spontan 3 Gründe ein, wieso man HTML-Code in ein Eingabefeld tippen sollte und dieser dann in ne DB wandert oder anderweitig weiterverarbeitet wird.
1.) Foren- und Blogposts, in denen man über ein Stück intelligenten Markups spricht. Angenommen, ich würde mich hier über das <time> - Element auslassen wollen, dann soll da gefälligst auch <time> gehen.
2.) Ein CMS, das selbstgeschriebenes HTML als Contentelemente erlaubt.
3.) JS Fiddle & Co

User-Eingaben werden auf Gültigkeit geprüft und von echtem Schadcode bereinigt. Mehr sollte man nie machen, bevor man ihn in die DB packt.
 
Zurück
Oben