Ergebnis 1 bis 9 von 9
  1. #1
    W32.FunLove
    Registriert seit
    17.10.2011
    Beiträge
    142

    Standard Php -> mqsli Prepared Statement

    Hi,

    ich habe seit langem nichts mehr in Php gemacht. Durch Zufall habe ich jetzt etwas über "prepared statements" gelesen.

    ... wodurch sqli praktisch unmöglich wird ...

    ich konnte es mir aber nicht erklären und auch in den Docs nichts passendes finden. Wie sicher ist es? Muss ich die Variablen nicht mehr selbst prüfen und kann $_POST['data'] direkt an die execute-function übergeben?
    Wie kann es denn schneller und sicherer sein?


    Über eine kurze Erläuterung würde ich mich freuen.

  2. #2
    DateMake Dialer Avatar von SecurityFlaw
    Registriert seit
    02.09.2016
    Beiträge
    118

    Standard AW: Php -> mqsli Prepared Statement

    Das zu lesen könnte sicher hilfreich sein: http://stackoverflow.com/questions/8...ection-attacks

  3. Folgende Benutzer haben sich für diesen Beitrag bedankt:

    lrg0 (13.04.2017)

  4. #3
    Be root - Use Linux Avatar von H4x0r007
    Registriert seit
    27.06.2007
    Beiträge
    1.878

    Standard AW: Php -> mqsli Prepared Statement

    Hi,
    du bereitest das Statement mit z.B. mit
    Code:
    $stmt = $mysqli->prepare("SELECT title, content FROM blog WHERE author=?");
    Damit steht der Code, den die Datenbank ausführen soll, bereits fest. Ich kenne die genaue Implementierung von PHP nicht, aber normalerweise wird dieser String schon an die Datenbank gegeben, die den String parst, interne Optimierungen ausführt und einen Ablaufplan generiert. Später fügst du mit
    Code:
    $stmt->bind_param('s', $_GET["author"]);
    den eigentlichen Wert ein. bind_param filtert dabei und kümmert sich um den Datentyp. Im prepared statement habe ich um die Stelle, an der der Get-Parameter eingefügt werden soll, keine Anführungszeichen geschrieben. Darum kümmert sich die bind_param-Funktion.

    Damit verhinderst du schon auf zwei Weisen SQL-Injections. 1. übergibst du den Wert aus dem Get-Parameter an die bind_param-Funktion, die das Ganze filtert. 2. steht für das Datenbanksystem der Ablauf nach dem prepare() schon fest und kann durch die Parameter ohnehin nicht mehr geändert werden.
    Bald 14 Jahre auf Free-Hack. Krass wie die Zeit vergeht...
    "Drei Dinge sind unendlich - das Universum, die menschliche Dummheit und die WinRAR-Testversion"

  5. Folgende Benutzer haben sich für diesen Beitrag bedankt:

    SecurityFlaw (14.04.2017), zzurc (20.04.2017)

  6. #4
    W32.FunLove
    Registriert seit
    17.10.2011
    Beiträge
    142

    Standard AW: Php -> mqsli Prepared Statement

    In dem Post bei Stackoverflow habe ich gelesen, dass es ein Feature der Datenbank ist und nicht von Php allein. Jetzt ist mir auch klar, wie dadurch die Sql-Injection verhindert wird.
    Ich frage mich jetzt nur, welche MySQL und welche Php ich mindest haben muss um prepared Statements zu nutzen.

  7. #5
    Be root - Use Linux Avatar von H4x0r007
    Registriert seit
    27.06.2007
    Beiträge
    1.878

    Standard AW: Php -> mqsli Prepared Statement

    Das sind ziemlich grundlegende Funktionen, die es schon ewig gibt. Laut PHP-Doku gibt's den mysqli-Wrapper schon seit PHP5. MySQL kann das auch schon seit Version 3.23.
    Bald 14 Jahre auf Free-Hack. Krass wie die Zeit vergeht...
    "Drei Dinge sind unendlich - das Universum, die menschliche Dummheit und die WinRAR-Testversion"

  8. Folgende Benutzer haben sich für diesen Beitrag bedankt:

    lrg0 (14.04.2017)

  9. #6
    Stiller Leser
    Registriert seit
    15.04.2017
    Beiträge
    3

    Standard AW: Php -> mqsli Prepared Statement

    Die PHP-Doku ist zum Thema prepared statements eigentlich völlig uninteressant im Bezug auf die Performance, da prepared Statements eine Basis-Funktionalität von MySQL sind und dementsprechend serverseitig (bezogen auf das DBMS) verarbeitet werden (im Falle von MySQLi, bei PDO sieht es schon ein Stück anders aus).

    Bestmöglich sollte der dritte Parameter im Bezug auf den Datentypen auch übergeben werden, aber bei Datentypen die im Vorfeld sowieso klar sind, würde ich eher Type casting vorziehen, einerseits bietet kein Datenbanktreiber mit dem Funktionsumfang absolute Sicherheit und zweitens, müssen Lücken nicht unbedingt nur in SQL-Statements auftreten.

  10. Folgende Benutzer haben sich für diesen Beitrag bedankt:

    SecurityFlaw (15.04.2017)

  11. #7
    Trojaner Avatar von 24ds
    Registriert seit
    13.11.2011
    Beiträge
    56

    Standard AW: Php -> mqsli Prepared Statement

    Wenn du es nicht nur sicher sondern auch noch bequem haben willst, kannst du gleich PDO oder ähnliches nutzen. Hier kannst du gleich sogar benannte Platzhalter verwenden und so noch ein Stückchen mehr Sicherheit und Stabilität herausholen.
    Ein Statement sieht dann ca. so aus: $stmt = $db_handle->prepare( "SELECT count(*) from `db`.`users` WHERE `user`=:username AND `password`=:passworthash");
    Bind über $stmt->bindParam ( ":username", $_POST['username'], PDO::[ABSICHTLICH EINGEFÜGTES LEERZEICHEN]PARAM_STR );
    usw....

    der Vorteil liegt vor allem bei umfangreicheren queries auf der Hand. Du gehst die Parameter nicht suchen.
    i.d.R. lässt sich PDO (wie auch andere Datenbanktreiber) leicht über Änderung in der php.ini aktivieren.

    p.s.: hat mich jemand vermisst?

  12. #8
    Stiller Leser
    Registriert seit
    15.04.2017
    Beiträge
    3

    Standard AW: Php -> mqsli Prepared Statement

    Zitat Zitat von 24ds Beitrag anzeigen
    Wenn du es nicht nur sicher sondern auch noch bequem haben willst, kannst du gleich PDO oder ähnliches nutzen. Hier kannst du gleich sogar benannte Platzhalter verwenden und so noch ein Stückchen mehr Sicherheit und Stabilität herausholen.
    Ein Statement sieht dann ca. so aus: $stmt = $db_handle->prepare( "SELECT count(*) from `db`.`users` WHERE `user`=:username AND `password`=:passworthash");
    Bind über $stmt->bindParam ( ":username", $_POST['username'], PDO::[ABSICHTLICH EINGEFÜGTES LEERZEICHEN]PARAM_STR );
    usw....

    der Vorteil liegt vor allem bei umfangreicheren queries auf der Hand. Du gehst die Parameter nicht suchen.
    i.d.R. lässt sich PDO (wie auch andere Datenbanktreiber) leicht über Änderung in der php.ini aktivieren.
    Ehrlich gesagt,auf gut Deutsch find ich ist die Aussage zu Stabililät und Sicherheit bezogen auf reines Halbwissen. Ja du hast Recht, PDO bietet auch vielerlei Maßnahmen zum Thema IT-Sec, aber von der Performance und der absoluten Kompatibilität zu MySQL sind wir weit von ab. Sicher, die meisten SQL Statements lassen sich damit parsen. Mittlerweile ist PDO als Datenbanktreiber sogar so weit, dass er im Prinzip zu MySQLi (im Vergleich zur Anfangszeit) kaum Unterschiede bietet. Aber der hauptsächliche Unterschied, sobald man mit MySQL/MariaDB oder etwaigen Forks arbeitet ist die Performance.

    Stabilität und Sicherheit lässt sich nicht aufgrund einer Fremdsoftware ausmachen, denn PDO (PHP Data Objects) ist nichts anderes als eine emultierte Umgebung von Prepared Statements sind, wohingegen MySQLi gegen die native Schnittstelle von MySQL für die interne Logik für Prepared Statements zurückgreift. Wohingegen PDO seine eigene Implementierung für verschiedene Datenbankengines vorsieht, nicht explizit MySQL spezifisch und damit auch gewisse Lücken bietet. Allein einfach mal den Quellcode von den zwei verschiedenen Extensions zu lesen wäre einfach mal Vorteilhaft.

  13. #9
    Trojaner Avatar von 24ds
    Registriert seit
    13.11.2011
    Beiträge
    56

    Standard AW: Php -> mqsli Prepared Statement

    Stabilität und Sicherheit lässt sich nicht aufgrund einer Fremdsoftware ausmachen
    Stimmt. Geht aber komplett am Punkt vorbei. Ich rede nicht von der Stabilität von PDO selbst. Oder der Sicherheit von PDO selbst. Abgesehen davon, dass ich mir gerade kein sinniges Angriffsszenario vorstellen kann, habe ich mir auf das Coding selbst bezogen.
    Sicherer weil man durch die Benennung der Platzhalter nicht mehr so leicht etwas verwechseln kann. Stabiler weil man sich nicht so häufig verwurstelt und das ganze deutlich hirngerechter programmieren kann.
    Geändert von H4x0r007 (24.04.2017 um 15:48 Uhr) Grund: OT entfernt

Ähnliche Themen

  1. [Szene] Hackbase Statement
    Von KleverKing im Forum Globale News / Szene News
    Antworten: 37
    Letzter Beitrag: 26.10.2011, 21:11
  2. Problem mit Prepared Statement
    Von Janiboy im Forum PHP
    Antworten: 8
    Letzter Beitrag: 15.06.2010, 19:46
  3. Hackressort.cc - Statement from f1@ni6@n
    Von f1@ni6@n im Forum Globale News / Szene News
    Antworten: 27
    Letzter Beitrag: 13.05.2009, 13:42

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •