[PHP-Data-Protection] Für SQLI, XSS [PHP-Data-Protection]

  • Hallo Liebe Towner,

    Ich habe eine Klasse in PHP geschrieben, die eure POST oder GET, vor XSS und SQLI schützt.
    Die Klasse ist sehr small gehalten, sollte eigentlich sehr einfach sein sowas zu machen.

    Die PHP-Klasse:

    Test-Form:

    Geschrieben habe ich es, weil mich Leute andauernd nach einem ,,Lückenfreien Habblet-Ordner Fragen''.
    Im Laufe des Tages werde ich sie noch verbesseren.
    Eine Form hab ich ebbenfalls mitgeliefert damit ihr sie testen könnt.

    Liebe Grüsse GermanKB.

    8 Mal editiert, zuletzt von germankb (28. Januar 2014 um 11:00)

  • Funktioniert! Leider aber nicht mit einem mehrdimensionalen POST-Request !!!
    Einfach einen rekursiven Aufruf bei mehrdimensionalem POST-Array starten, dann müsste es gehen.

    Und warum error_reporting(0) ? Da sollten eigentlich keine Fehler auftreten ...

    so far
    Yannici

  • Funktioniert! Leider aber nicht mit einem mehrdimensionalen POST-Request !!!
    Einfach einen rekursiven Aufruf bei mehrdimensionalem POST-Array starten, dann müsste es gehen.

    Und warum error_reporting(0) ? Da sollten eigentlich keine Fehler auftreten ...

    so far
    Yannici


    Habs geupdatet hoffe so geht es.

    Liebe Grüsse Stee.

  • Na, was ist jetzt besser? Sinnlos dafür eine Klasse zu schreiben wenn das auch so geht.. Und jetzt bitte keine Ausreden wie: Ja, wenn man nur HTML escapen möchte? etc.

  • Ist doch egal ob er dafür eine eigene Klasse schreibt?
    Es funktioniert, und das ist der Sinn.

    B2T:
    Gut gemacht, wird einigen helfen :)

    -DerNeue


    Es ist ganz und garnicht egal ob man für so etwas eine Klasse schreibt oder nicht weil es einfach nur sinnlos ist. Das von Kurdt aka schiaßler ist um einiges besser. Wäre das selbe wenn ich ein Programm schreibe wo 100000 Zeilen hat aber es mit 10000 schreiben könnte oder weniger. Welches würde wohl eher genutzt werden?

  • Ist das iExit Attribut eine Referenz darauf, dass iExit sein CMS mit einem Script schützt, welches jeden POST/GET Wert auf Zeichen welche man bei bspw. SQL Injections verwendet prüft?
    Wenn ja, ich musste kurz lachen.

    Ein Problem bei dem Script ist, dass eine MySQL Connection vorhanden sein muss um
    mysql_real_escape_string($value)
    aufzurufen. Eine Klasse ist für soetwas auch relativ unnötig, und ich halte den "iExit"-Weg um Benutzereingaben zu filtern für sehr schlecht.

    3 Mal editiert, zuletzt von Johnix (29. Januar 2014 um 14:17)

  • Eine Klasse dafür.. naja. Könnte man auch in eine Art Common Klasse stecken. Es wäre sinnvoller zuerst HTML-Code zu escapen und dann die weiteren SQL-Escape Charakter. Sonst hast du danach bei der Ausgabe eventuell lauter Backslashes vor den Anführungszeichen stehen.

  • Warum regen sich alle auf das es in einer Klasse steckt?

    Ist es nicht viel schlimmer, dass einfach alle Felder aus $_GET und $_POST gefiltert werden, obwohl es vielleicht nicht bei allen nötig ist?

    Die normalen MySQL funktionen werden in PHP 6 sowieso entfernt und sollen durch MySQLi und PDO ersetzt werden. Also solltet ihr lieber mal zusehen dass ihr prepared statements benutzt.

  • Die normalen MySQL funktionen werden in PHP 6 sowieso entfernt und sollen durch MySQLi und PDO ersetzt werden. Also solltet ihr lieber mal zusehen, dass ihr prepared statements benutzt.


    Ich persönliche finde zwar Prepared Statements auch schöner, aber es gibt trotzdem noch MySQLi::real_escape_string und PDO::quote.

    Cheers
    Steve Winfield

  • an für so etwas eine Klasse schreibt oder nicht weil es einfach nur sinnlos ist. Das von Kurdt aka schiaßler ist um einiges besser. Wäre das selbe wenn ich ein Programm schreibe wo 100000 Zeilen hat aber es mit 10000 schreiben könnte oder weniger. Welches würde wohl eher genutzt werden?

    Nicht nur das: Jede Klasse heißt mehr Rechenaufwand. Wenn man das alles in eine Klasse passt, welche dann erstmal definiert werden und dann noch angesprochen werden muss, bevor die eigentliche Klasse erstmal zum Zug kommt, ist es doch klar, dass dies wichtige CPU Zeit frisst.

    Ausserdem finde ich es ziemlich unnötig, sofort die Daten mit htmlspecialchars zu escapen, obwohl man NUR Daten in eine Datenbank einträgt, von denen man nichtmal weiß, ob sie irgendwann mal wieder in Form von HTML ausgegeben werden, oder nicht gleich z.B. als INT in der Datenbank landen, wo eh keine Sonderzeichen zulässig sind.

    Wenn man keine Prepared statements verwendet, kann man auch (zumindest bei PDO, verwende den MySQL bzw MySQLi Treiber nicht) "$sql->quote($sting);" verwenden.


    Auf gut Deutschland: Verschwendete Lebens- und CPU-Zeit.


    :!: FileXs #Lieblingsmod. :!:
    ... still making kids cry since 2015.

  • Eine Klasse dafür.. naja. Könnte man auch in eine Art Common Klasse stecken. Es wäre sinnvoller zuerst HTML-Code zu escapen und dann die weiteren SQL-Escape Charakter. Sonst hast du danach bei der Ausgabe eventuell lauter Backslashes vor den Anführungszeichen stehen.

    #word @ html-escape -> mysql-escape

  • Ja, die Klasse ist unnötig.
    Allerdings als Funktion, wie germankb es hat, ist es schon sinnvoll. Warum? Denkt mal an das mehrdimensionale $_POST-array, was bei
    Kurdt's Lösung nicht berücksichtigt wurde. Die Funktion ProtectMode in der Klasse hat also schon seinen Sinn! Als Klasse etwas zu groß ausgemalt, aber
    als Funktion wirklich sinnvoll. Der rekursive Aufruf der Funktion (was ich germankb ergänzt habe) deckt auch ein mehrdimensionales $_POST-Array ab.
    Nicht zu vergleichen mit Prepared Statements, was allem in allem die Beste Variante wäre, um die Lücken zu schließen.

    Klar, wenn man sich sicher ist, dass man nirgendwo mehrdimensionale Arrays im $_POST verwendet, dann wäre Kurdt's Variante die deutlich Bessere.

    so far
    Yannici

    Einmal editiert, zuletzt von Yannici. (1. Februar 2014 um 14:04)

  • Ja, die Klasse ist unnötig.
    Allerdings als Funktion, wie germankb es hat, ist es schon sinnvoll. Warum? Denkt mal an das mehrdimensionale $_POST-array, was bei
    Kurdt's Lösung nicht berücksichtigt wurde. Die Funktion ProtectMode in der Klasse hat also schon seinen Sinn! Als Klasse etwas zu groß ausgemalt, aber
    als Funktion wirklich sinnvoll. Der rekursive Aufruf der Funktion (was ich germankb ergänzt habe) deckt auch ein mehrdimensionales $_POST-Array ab.
    Nicht zu vergleichen mit Prepared Statements, was allem in allem die Beste Variante wäre, um die Lücken zu schließen.

    Klar, wenn man sich sicher ist, dass man nirgendwo mehrdimensionale Arrays im $_POST verwendet, dann wäre Kurdt's Variante die deutlich Bessere.

    so far
    Yannici


    PHP
    foreach($_POST as $a  => $b) {
    	$_POST[$a] = mysql_real_escape_string($b);
    	}

    Spart immernoch genug Leistung, wenn man z.B. keine HTML Zeichen escapen muss. Ausserdem kann man das alles zu einer Zeile Code zusammen rücken.


    :!: FileXs #Lieblingsmod. :!:
    ... still making kids cry since 2015.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!