OS X Entwicklerforum

Mhm, du weißt aber schon das du damit gegen jegliche Regeln der Kapselun und Normalisierung "verstößt", oder? Wenn du nicht mehrere UDID's in einem Feld speicherst, hast du erstens das Layout deiner DB verbessert und zweitens, so zusagen in einem Abwasch, die auch noch die 68 Zeilen unnötigen Code gespart

Zitat von »Rosi-janni«

	Quellcode
1 2 3 4 5 6	<?php error_reporting(E_ALL); … $username = $_GET[username]; $password = $_GET[password]; $getToken = $_GET[token];

Wenn Du wirklich mit E_ALL arbeiten würdest, würde PHP Dir (zurecht) einen Haufen Warnings um die Ohren werfen. Nicht-numerische Keys von Arrays gehören in Anführungszeichen oder Hochkommata.

Zitat von »Rosi-janni«

	Quellcode
1	$ergebnis = mysql_query("SELECT * FROM accounts WHERE mail='$username'");

Bitte informier Dich dringend mal über den Begriff »SQL Injection«.

Zitat von »Rosi-janni«

	Quellcode
1 2 3 4 5 6	// Gucken ob der Token wirklich in der DB drin ist… for($x = 0; $x < count($teile); $x++) { if ($teile[$x] == $getToken){ $vorhanden = TRUE; } }

Ich glaube, Du solltest Dir mal die Funktion in_array() ansehen.

Was Dein sonstiges Vorgehen betrifft: wenn ich den Wunsch hätte, eine Liste von Werten in einem Datenbankfeld aufzubewahren und einfach Werte hinzufügen, entfernen oder auf deren Vorhandensein testen zu wollen und darüber hinaus die Werte nicht in einer SQL-Query verwendet werden müssen, würde ich nichts anderes machen als einfach ein serialisiertes Array in das Feld zu stecken.

Carsten

Zitat von »Rosi-janni«

SQL Injektion ist mir ein Begriff, dabei kann man z.B. ja über die GET URL Code in die DB einschleusen, aber wie sollte ich bei einem NSURL-Request sonst noch Daten übermitteln? GET ist das Einfachste, aber POST geht doch sicher auch, ist das denn 'sicherer'?
Da ich wirklich nur mal eine Woche mir neulich PHP angeschaut habe, weiss ich wirklich nicht genau, was ich alles beachten muss.

1. Böser Nutzer liesst Kommunikation deiner App mit.
2. Sieht dann Request wie etwa register.php?username=foo
3. Ändert das um in register.php?username='; drop table accounts;--
4. Deine PHP Anwendung führt dann (sofern magic quotes nicht an ist -- ist jetzt zu illustrationszweckene) folgendes aus
SELECT * FROM accounts WHERE mail=''; drop table accounts;--'
5. Schon hat irgendein Typ mit Langerweile Deine ganze DB gelöscht.

Zitat von »Rosi-janni«

Zum Thema Error-Report: Entweder ich habe das Teil nicht ganz verstanden, oder ich hab was vergessen. Denn Warnings gibt er keine.

Dann ergänze mal das hier zu Beginn des Skripts:

Zitat von »Rosi-janni«

SQL Injektion ist mir ein Begriff, dabei kann man z.B. ja über die GET URL Code in die DB einschleusen, aber wie sollte ich bei einem NSURL-Request sonst noch Daten übermitteln? GET ist das Einfachste, aber POST geht doch sicher auch, ist das denn 'sicherer'?

Die HTTP-Methode ist egal – die Angreifbarkeit liegt nicht in der Methode, sondern in falscher oder fehlender Vorbereitung von Strings, die Du an die Datenbank schickst. BTW geht es nicht nur ums Einschleusen, sondern auch um das Umgehen von Authentifizierung oder das Löschen oder Ändern von Daten.

Zitat von »Rosi-janni«

Da ich wirklich nur mal eine Woche mir neulich PHP angeschaut habe, weiss ich wirklich nicht genau, was ich alles beachten muss.

Dann wäre es m.E. dringendst angeraten, dass Du Dir ein Buch wie »PHP-Sicherheit« von Kunz/Esser durchzulesen, bevor Du Dich als leichte Beute von Script Kiddies exponierst.

Zitat von »Rosi-janni«

Aber warum serialisiert speichern? Ich weiss nicht wirklich, wie ich dynamisch Felder erzeugen lassen soll und wie ich sie wieder lösche, durchlaufe.
Daher war eben meine Annahme, dass es richtiger wäre, alles in ein Feld zu schreiben.

Ob es »richtig« ist, kann ich nicht beurteilen. Von dem, was Du schreibst, würde ich sagen: Dein Vorgehen ist zumindest nicht lehrbuchmäßig, weil Du nicht normalisierst, aber in Zeiten von NoSQL-Datenbanken wirst Du sicher nicht mehr schief deswegen angesehen, wenn die Normalisierung nur Bloat, aber sonst keinen Nutzen mit sich brächte.

Dein Problem lässt sich im Wesentlich, sofern ich’s richtig verstanden habe, auf diese Punkte runterbrechen:

• Du willst in einem einzelnen Datenbankfeld mehrere Werte aufbewahren
  
• Du willst effizient einen Wert hinzufügen können, sofern er noch nicht da ist.
  
• Du willst testen können, ob ein Wert enthalten ist.
  
• Du willst einen Wert aus der Menge entfernen.
  

Der naheliegendste Ansatz in PHP bestünde darin, die Werte als Keys eines assoziativen Arrays zu verwenden (Wert zum Key jeweils 1 oder true), mit empty() zu testen, ob ein Key vorhanden ist, einen neuen Key mit Wert 1 hinzuzufügen und einen Key mit unset() zu entfernen. Wenn das Array dann gespeichert werden soll, verwendet man bevorzugt – sofern auf dem Server vorhandne – json_encode() oder serialize(); beim Auslesen natürlich das entsprechende Gegenstück.

Carsten

Zitat von »zerm«

3. Ändert das um in register.php?username='; drop table accounts;--
4. Deine PHP Anwendung führt dann (sofern magic quotes nicht an ist -- ist jetzt zu illustrationszweckene) folgendes aus
SELECT * FROM accounts WHERE mail=''; drop table accounts;--'
5. Schon hat irgendein Typ mit Langerweile Deine ganze DB gelöscht.

Das ist beim konkreten Beispielcode falsch, denn die alte mysql_*-API aus dem Beispiel kann in einem Funktionsaufruf nicht mehrere Queries ausführen.

Was natürlich für andere Datenbanken und andere Treiber nicht gilt.

Carsten

Zitat von »Rosi-janni«

Ehm die Mail und Passwort sind mit 16000bit RSA verschluesselt in der DB. Also wer da einen SQL Code in den kodierten RSA String bekommt ist schon gut.

Ich werde mal ganz deutlich: es ist scheißegal, was für kryptographische Geschütze Du auffährst, solange sie sich umgehen lassen.

Nehmen wir als Beispiel an, Du verwendest folgende Query, um einen Benutzer zu authentifizieren:Gehen wir außerdem davon aus, dass der »username« nicht gequoted aus einer Request-Variable übernommen wird und ein Angreifer als Wert der Variablen »' OR '1'='1« übergeben hat (natürlich URL-encoded). Dann ergibt sich diese resultierende Query:. Dämmert Dir was? Es werden alle Benutzer geholt, weil der WHERE-Ausdruck immer zu TRUE evaluiert. Ergo wird der Angreifer die User-ID irgendeines Users verpasst bekommen.

Klar – Verschlüsselung erschwert den Angriff, aber nicht, weil Du verschlüsselst, sondern weil beim Verschlüsseln oder Hashen das Hochkomma nicht erhalten bleibt. In dieser Hinsicht hat Verschlüsselung also den Nebeneffekt, die Variable in gewisser Weise auch zu quoten; die Verschlüsselung selbst hat aber keine Relevanz, so dass die Stärke des Algorithmus schlicht nicht interessiert.

Carsten

Zitat von »BlueM«

Das ist beim konkreten Beispielcode falsch, denn die alte mysql_*-API aus dem Beispiel kann in einem Funktionsaufruf nicht mehrere Queries ausführen.

Heh, OK. Hatte primär gehofft, dass es so leichter nachvollziehbar ist. Ich mach halt kein PHP.

Zitat von »Rosi-janni«

Mail und Passwort sind mit 16000bit RSA verschluesselt in der DB

W-T-F?
1. Warum asymmetrische Verschlüssellung? Ergibt gar kein Sinn, oder? Läd der Nutzer immer seinen Key mit hoch oder was?
2. 16kbit? 2kB? Ist das nicht ein wenig zu hardcore? Dauert das nicht Ewigkeiten in der Benutzung?

Zitat von »Rosi-janni«

Es geht nur um eine userfreundliche eindeutige Authentifizierung. Ich brauche den private Key nicht. Ich möchte damit nur zum
Ausdruck bringen, dass es rein Mathematisch ja nicht mal mehr möglich ist, dass ein 'Einbrecher' in die DB oder ich an die Userdaten komme. Die DeviceToken habe ich momentan da noch nicht bei. Mal sehen, wie sich das in der Benutzung zeigt beim DeviceToken. Natürlich dauert es beim
erstmaligen Login ein wenig, aber es geht um Sicherheit und das möchte ich auch zeigen.

Ich versteh immer noch nicht ganz, wovon Du redest. Du brauchst den Private-Key nicht? Warum dann überhaupt RSA?

Davon abgesehen: Gut, dass Du allen Nutzern vertraust. Und wenn ein legitimer Nutzer dann doch anfängt, an den Parametern zu spielen?

Zitat von »Rosi-janni«

Zur Injection: Wenn die Ubergabe von Daten so dramatisch unsicher ist, muss es ja einen anderen, sichereren, Weg geben. Sonst würde es ja niemand nutzen. Da ich aber nur einen Shell/PHP/SQL Server habe, muss ich aber mit PHP wohl arbeiten. Denn eine SSH Verbindung und das Eintragen via Shell ist dann ja genauso unsicher.
Aber ich hab noch nicht alle Antworten gelesen, bis heute Abend aber natürlich.

Ja. Prepared Statements etwa. Verwendet jeder, auch in PHP, der auch nur etwas Sicherheitsbewusstsein hat.
Ausserdem hindert Dich niemand daran, $username etc. auf Sinn zu prüfen. Etwa um prinzipiell auszuschliessen, dass es Zeichen wie '`%- enthält, die potentiell ärger machen.

Zitat von »Rosi-janni«

Okay das heisst ich muss von Hand hingehen, um sicher zu stellen, dass es kein PHP/SQL Kommando ist?
Das Problem ist wohl also, dass ich eine öffentliche URL habe?
Wenn ich diese URL schützen würde in irgendeiner Weise (wie weiss ich grade nicht), kann ich doch trotzdem wie geplant verfahren? Also ich könnte dann meinen kodierten Stuff schreiben/lesen lassen?

Es ist generell ratsame, den Nutzer erstmal als "böse" anzusehen und alle eingaben genauer zu prüfen. Das hat wenig bis gar nichts mit der URL zu tun, sondern schlicht und ergreifend damit, dass Daten die von einem potentiell bösem Nutzer kommen ungeprüft in ein SQL-Statement eingefügt werden. Ein böser Nutzer hat volle Kontrolle über diese Daten und dadurch
im schlimmsten Fall volle Kontrolle über das SQL-Statement.
Prüfsummen über der URL (wie Typo3 das macht/gemacht hat?) halte ich für hirnverbrannt oder zumindest für wenig hilfreich. Wenn Deine App die URL verschlüsselt, kann der Nutzer schauen, wie die App das macht und es einfach Nachahmen. Oder er trägt in Deiner App schon gleich ins "Nutzername"-Feld etwas ein, woran sich Dein Server verschluckt.

Zitat von »Rosi-janni«

Es geht bei meiner Anwendung von RSA in dem Fall nur um Sicherheit. Ich mache das doch nur, damit sich ein User identifizieren kann, aber auch nichts zwei Mal in der DB steht an Nutzernamen. Ich kodiere alles, aber ich will es gar nicht wieder dekodieren. Also brauche ich den Privatekey nicht und kann somit sagen, dass die Daten nicht entschlüsselbar sind. (Also natürlich könnte man, wenn man mehrere 100 Jahre Langeweile hat).

RSA ist aber komplett der falsche Ansatz. Dafür nimmt man Hashfunktionen. Am besten gesalzen und tausend mal hintereinander ausgeführt. So kann man genauso ausschliessen,
dass jemand das dekodiert. Quasi:
hash = sha1( "lalala" + sha1( "bobo" + sha1("fufu" + sha1( USERNAME + "fff") ) ) )
liess Dich da vielleicht mal ein, wenn Du soviel Wert auf Sicherheit legst.

Zitat von »Rosi-janni«

Also Fazit: Ich muss von Hand gucken, dass kein SQL/PHP Kommando mitkommt?

Von Hand gucken, ob die Nutzereingabe sinnvoll ist.
Um sich vor SQL-Injections zu schützen hatte ich Dir schon prepared statements genannt. Schnell gegoogelt ergibt das sogar ein "TuT" für PHP:
http://www.tutorials.de/php-tutorials/27…statements.html
Aber keine Garantie, ob da nicht auch Quatsch drin steht, aber zumindest schonmal ein Ansatzpunkt

Prepared Statements haben auch noch den tollen Vorteil, dass man jedweges Sonderzeichen im Usernamen benutzen kann. Also ich könnte mich auch Claus"DerTolleHeld"'zu'Bönnhoff nennen und das SQL Statement würde noch funktionieren.

Gruß

Claus

Zitat von »zerm«

Um sich vor SQL-Injections zu schützen hatte ich Dir schon prepared statements genannt.

Ist natürlich prinzipiell korrekt, aber im Fall der in der Frage verwendeten Anno-Dazumal-MySQL-API nicht zielführend, weil die nicht weiß, was Prepared Statements sind.
Aber man kann natürlich auch selbst explizit quoten – bei der alten API mit mysql_real_escape_string(), bei z.B. PDO mit PDO::quote().

Carsten