MySQL Verbindung ohne PHP API

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Klar, der Programmierer kann es in dem hier angesprochenen Fall der SQL-Injection auch ganz einfach falsch machen: Er baut das Statement als String zusammen. Das ist das einfachste Szenario. Und es ist hier auch gerade das allerwahrscheinlichste Szenario. So kompliziert musst du es gar nicht machen.

    Das ändert aber freilich nichts daran, dass du SQL-Injection mit jedem halbwegs brauchbaren Framework ganz einfach ausschließen kannst.Da ein "händischer" Zugriff deutlich mehr Code beansprucht, halte ich hier die Fehlerwahrscheinlichkeit für sehr gering. Da gibt es Dümmeres aus Bequemlichkeit. Hier wäre es ja eher Dummheit aus Fleiß.

    Wie dem auch sei: Händische Überprüfung richtig zu machen, dann aber die seitens de Frameworks zu "vergessen" scheint mir ganz und gar unwahrscheinlich. Eher schon verlässt sich jemand auf die selbst gestrickte händische Überprüfung, die fehlerhaft ist.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
  • Amin Negm-Awad schrieb:

    Das ändert aber freilich nichts daran, dass du SQL-Injection mit jedem halbwegs brauchbaren Framework ganz einfach ausschließen kannst.Da ein "händischer" Zugriff deutlich mehr Code beansprucht, halte ich hier die Fehlerwahrscheinlichkeit für sehr gering. Da gibt es Dümmeres aus Bequemlichkeit. Hier wäre es ja eher Dummheit aus Fleiß.


    Du hast noch Ideale, Du glücklicher Mensch. ;) Klick.
  • Ich hatte nicht gesagt, dass SQL-Injection nicht existent ist.

    Ich hatte gesagt, dass sich die Fehlerrate nicht senken lässt, indem man das selbst handhabt, sondern mutmaßlich sogar steigern lässt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
  • kmr schrieb:

    Was aber nicht davon entbindet, Datenmodell, Datenablage und Rechtevergabe sinnvoll zu gestalten. Denn beim am Freitag um 18 Uhr dringend auf Kundenwunsch einzubauenden Update 38a wird der findige Programmierer "mal eben®" um das Framework herum auf die DB zugreifen und dem Herrn Lulzsec damit vollen Zugriff auf die gesamte DB geben. Und wenn es dann aufgrund sinnvoll vergebener Rechte und starker Passwörter nur die Tabelle mit den Sessions trifft, ist das nicht ganz so blöd wie der Vollzugriff auf unverschlüsselte abgelegte Passwörter aller Benutzer, deren Kontodaten und die Liste der gekauften FSK-Filme. Defense in depth und so, wissenschon. Was mich wieder zu dem hier bringt.


    Öh ja,

    ein Automechaniker muss Radmuttern anziehen können, ein Webentwickler sollte in der Lage sein eine Webanwendung zu entwickeln. Wenn er halt die Passwörter im Klartext ablegt und sich nicht um SQL Injections oder was auch immer kümmert, hat er von seinem Job eben nicht die geringste Ahnung.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.
  • Amin Negm-Awad schrieb:


    Ich hatte gesagt, dass sich die Fehlerrate nicht senken lässt, indem man das selbst handhabt, sondern mutmaßlich sogar steigern lässt.


    Bezog sich auch nur auf "halte ich hier die Fehlerwahrscheinlichkeit für sehr gering". Oder, um es mit Roy Batty zu sagen: "I've seen things you people wouldn't believe." :)
  • Manfred Kreß schrieb:


    ein Automechaniker muss Radmuttern anziehen können, ein Webentwickler sollte in der Lage sein eine Webanwendung zu entwickeln. Wenn er halt die Passwörter im Klartext ablegt und sich nicht um SQL Injections oder was auch immer kümmert, hat er von seinem Job eben nicht die geringste Ahnung.


    Da stimme ich Dir uneingeschränkt zu. Allein, was hilft's? Offenbar haben dann geschätzte 90% der Webentwickler keine Ahnung von ihrem Job.
  • kmr schrieb:

    Amin Negm-Awad schrieb:


    Ich hatte gesagt, dass sich die Fehlerrate nicht senken lässt, indem man das selbst handhabt, sondern mutmaßlich sogar steigern lässt.


    Bezog sich auch nur auf "halte ich hier die Fehlerwahrscheinlichkeit für sehr gering". Oder, um es mit Roy Batty zu sagen: "I've seen things you people wouldn't believe." :)
    Das bezog sich darauf, dass man durch Einsatz eines entsprechenden Frameworks die Fehler, die man mit händischer Überprüfung noch ausschließt, sehr gering sind.

    In dem Standardfall der SQL-Injection dürfte ein solche Framework ja gar nicht erst benutzt worden sein. Ich kann mir nicht vorstellen, dass *bei* Einsatz eines Frameworks, welches Prepared-Statements kennt, es eine nennenswerte Fehlerrate gibt, die sich dann eben durch händischen Code noch weiter senken ließe. Die tatsächlich vorgefundenen Fehler dürften ihre Ursache allermeistes darin zu finden sein, dass gar nicht erst so ein Framework bzw. die unterstützten Prepared-Statements verwendet wurden.

    Jetzt wirst du (und hast du schon) erwidern, dass man etwas sicheres auch sicherer machen kann. Das stimmt. Nur scheint mir da die Arbeitszeit an anderer Stelle besser eingesetzt, wenn man mal von der Endlichkeit verfügbarer Ressourcen ausgeht. Oder anders: Deine Statistik belegt zwar, dass es viele SQL-Injections gibt, sie belegt aber nicht, dass man eben diese durch Einsatz zusätzlicher händischer Prüfung neben Verwendung von Prepared-Statements vermieden worden wären. Dazu ist sie halt zu unspezifisch.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
  • Amin Negm-Awad schrieb:


    Jetzt wirst du (und hast du schon) erwidern, dass man etwas sicheres auch sicherer machen kann. Das stimmt. Nur scheint mir da die Arbeitszeit an anderer Stelle besser eingesetzt, wenn man mal von der Endlichkeit verfügbarer Ressourcen ausgeht. Oder anders: Deine Statistik belegt zwar, dass es viele SQL-Injections gibt, sie belegt aber nicht, dass man eben diese durch Einsatz zusätzlicher händischer Prüfung neben Verwendung von Prepared-Statements vermieden worden wären. Dazu ist sie halt zu unspezifisch.


    Neenee, da hast Du mich falsch verstanden. Was ich sagen wollte: So gut wie alle Webapps, die ich mir angucke, sind mit Frameworks gebaut, die simple Implementierungsfehler wie SQL Injection wirksam unterbinden können. Die Gründe, warum ich dann bei solchen Webapps trotzdem Fehler wie SQL Injection (oder XSS) finde, sind alle prozessualer Natur:
    • falsche Verwendung des Frameworks allgemein,
    • falsche Verwendung von Maßnahmen (Stored Procedures mit implementierter SQL Injection statt Prepared Statement),
    • der Programmierpraktikant weiß gar nix von dem eingesetzten Framework und baut die neue Suche in der Portalseite mit direkter DB-Anbindung zu Fuß,
    • Agentur XY liefert ganz wichtiges, buntes Feature für den Webshop bei, das aufgrund seiner gewachsenen Struktur (seufz) nativ angebunden werden muss,
    • etc. pp.
    Aber in der Tat wird der Aufwand, etwas wirklich kaputt zu bauen, immer höher. Unterschätze aber nie den Einfallsreichtum von Programmierern und Admins, wenn es darum geht, eine sichere Technologie zu durchlöchern. Da ist keine Ausrede zu fahl und kein Aufwand zu hoch. ;)
  • Ich habe mal ein paar grundlegende Fragen zum Thema zum Thema SQL-Injection:
    • Was genau macht der Angreifer und was will er bewirken?
    • Wo fange ich diese schädlichen Angaben ab, direkt in Objective C oder in PHP?
    • Was kann man konkret dagegen tun, ich habe z.B. das hier gelesen: $username = stripslashes($username);
  • jonas.e schrieb:

    Ich habe mal ein paar grundlegende Fragen zum Thema zum Thema SQL-Injection:
    • Was genau macht der Angreifer und was will er bewirken?
    • Wo fange ich diese schädlichen Angaben ab, direkt in Objective C oder in PHP?
    • Was kann man konkret dagegen tun, ich habe z.B. das hier gelesen: $username = stripslashes($username);


    wenn es jetzt konkret um php geht dann verwende zb die "mysqli" extension anstatt der alten "mysql".
    diese unterstützt nämlich prepared statements mit denen du mysql-injections verhindern kannst.

    der angreifer will in einer SQL-abfrage seine eigenen queries ausführen mit denen er sich rechte geben kann um auf die gesamte db zuzugreifen oder oben die komplette DB löschen oder was auch immer. aber dazu gibt es wirklich sehr viel sinnvolle, kurze lektüre (muss man hier nicht nochmal alles tippen).
  • jonas.e schrieb:

    Ich habe mal ein paar grundlegende Fragen zum Thema zum Thema SQL-Injection:
    • Was genau macht der Angreifer und was will er bewirken?
    • Wo fange ich diese schädlichen Angaben ab, direkt in Objective C oder in PHP?
    • Was kann man konkret dagegen tun, ich habe z.B. das hier gelesen: $username = stripslashes($username);


    Siehe oben. Klick.
  • jonas.e schrieb:

    * Was genau macht der Angreifer und was will er bewirken?

    Nutzbare Ressourcen erobern.

    jonas.e schrieb:

    * Wo fange ich diese schädlichen Angaben ab, direkt in Objektive C oder in PHP?

    So früh und umfänglich wie möglich.

    jonas.e schrieb:

    * Was kann man konkret dagegen tun, ich habe z.B. das hier gelesen: $username = stripslashes($username);

    Sich mit Hacking Tools/Techniken beschäftigen, mit Secure Coding/Programming. Codereviews sind auch wichtig.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NSObject ()

  • jonas.e schrieb:

    Ich habe das bisher so geplant, dass ich in der App mein PHP File aufrufe und per GET einen Usernamen und ein Passwordübergebe welches dann ein eine MySQL Datenbank eingepflegt wird. Ich bin da noch ziemlicher Anfänger und würde gerne wissen, ob man das so machen könnte. Das klingt für mich etwas unsicher, …

    Ja. Das klingt nach einem Fest für Angreifer. Üblicherweise speichert man gesalzene Hasses. Und auch kein SHA-1 oder gar MD5. Besser SHA-256, bcrypt, Whirlpool, o.ä.
    * Kann Spuren von Erdnüssen enthalten.
  • Blöde ist es, dass man dadurch nicht seine DB fernwarten kann ausser mit diesem unsäglichen phpMyAdmin, welches ich echt zum kotzen finde.


    per ssh auf die Kiste

    ssh Tunnel bohren

    vpn

    vlan Wartungsnetz aufbauen

    ppp dialin über vlan verschlüsselt (vpn für Fußgänger)

    ...

    Man kann viel machen. Und ich sags gleich wieder dazu, man muss es halt richtig machen und Versagen ist keine Option.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.
  • Ich habe jetzt mal folgendes ausprobiert:

    Der Aufruf in Objective-C:

    Quellcode

    1. ​NSString *unescaped = textView.text;
    2. NSString *charactersToEscape = @"!*'();:@&=+$,/?%#[]\" ";
    3. NSCharacterSet *allowedCharacters = [[NSCharacterSet characterSetWithCharactersInString:charactersToEscape] invertedSet];
    4. NSString *encodedString = [unescaped stringByAddingPercentEncodingWithAllowedCharacters:allowedCharacters];
    5. NSString *URL = [NSString stringWithFormat:@"http://www.jonasester.de/Speichern.php?name=%@", encodedString];
    6. if (![NSData dataWithContentsOfURL:[NSURL URLWithString:URL]]) {
    7. NSLog(@"Ungültiger Name");
    8. }
    Alles anzeigen


    Und das PHP Script zum eintragen in die Datenbank:

    PHP-Quellcode

    1. <?php
    2. $DB_HostName = "hostname";
    3. $DB_Name = "dbName";
    4. $DB_User = "user";
    5. $DB_Pass = "pass";
    6. $mysqli = new mysqli($DB_HostName, $DB_User, $DB_Pass, $DB_Name);
    7. $name = $_GET["name"];
    8. $name = $mysqli->real_escape_string($name);
    9. $mysqli->query("INSERT INTO Testtabelle (Name) VALUES('$name',)")
    10. $mysqli->close();
    11. ?>
    Alles anzeigen


    Kann man das so machen?