MySQLi-Abfrage

[ImmerOn]

Hi,

was soll das denn? Du stellst hier irgendwelche Andeutungen in den Raum und verunsicherst mich hier total aber kannst dann nichtmal Stellung dazu beziehen. Ich dachte hier in diesem Forum wird einem geholfen...
Was ist denn daran so schlimm, zu schreiben, was du genau meinst?
Wenn du schon solche Andeutungen machst, solltest du auch drauf eingehen, weil sowas hilft hier keinem weiter und es ist halt nicht jeder ein so guter Programmierer wie du, deswegen werden die Fragen hier doch gestellt...

[ImmerOn]

Hallo,

nochmal zum aktuellen Stand, da ja mermshaus hier irgwelche Andeutungen gemacht hat, das meine Scripte nicht sicher wären (mach lieber in kurzen Abständen Backups...).
Ich habe jetzt mal sämtliche PHP-security-scans über meine Scripte laufen lassen. Diese Scans achten vor allem auf SQL-Injection / XSS / Remote Code Execution / Dateisystem Attacken.
Alle Scans ergaben 0 Sicherheitslücken... Zusätzlich habe ich mich auch nochmal schlau gemacht und bin mir eigentlich 100pro sicher, dass meine Scripte auf die gängigen Hackatacken imun sind.
Die letzte Stufe wäre jetzt noch, einen Experten dazu zu befragen, was ich demnächst auch machen werde.

Aber allein den Scans zu urteilen und allen Infos was so im Netz zu PHP / MySQL-Sicherheit steht, sind meine Scripte sicher.
Also warum verunsicherst du (mermshaus) mich hier total und gehst dann nicht mal drauf ein, deine Andeutung mit irgwelchen Argumenten zu festigen?

Also das habe ich echt noch nicht erlebt, dass einem in einem PHP Forum nicht weitergeholfen wird, sondern man eher noch verunsichert wird und man dann die 3-fache Arbeit hat und auch noch total verunsichert ist...

Naja soviel dazu.

Liebe Grüße.

[ApoY2k]

Da kannst du Scripte drüber jagen wie du willst, ein Query wie

"select x from y where z = $blub" 

wird niemals gegen mysql injections sicher sein, egal wie viel du vorher checkst und prüfst und sonst was machst.

wenn du solche statements verwendest, disqualifiziert dich das einfach aus jeder diskussion über sicherheit. es geht ums prinzip. man verwendet diese art statements nicht, weil sie unsicher sind. punkt. keine diskussion.

das ist so als würdest du behaupten, du müsstest dich nicht anschnallen, weil du immer maximal 2 km/h fährst und immer genau links und rechts guckst. scheiß drauf. es ist unsicher. lass es.

[ImmerOn]

Hi,

was genau ist jetzt daran unsicher, wenn ich die Variable $blub in deinem Beispiel vor der Abfrage definiere.
Also mein PHP-Script dann so ausschaut:
$blub = 2;
[COLOR=#000000][COLOR=#CC0000]"select x from y where z = '$blub'";
[/COLOR][/COLOR]
Kann man wohl als Benutzer Variablen fäschen, die kurz vor der Ausgabe bzw. Verwendung definiert werden? Die Variable stammt ja nicht aus einer Benutzereingabe oder sonstwas, sondern wird vom Server selbst vorher definiert, wie es halt in dem oberen Beispiel jetzt zu sehen ist...

Liebe Grüße.

ps:
Ich kanns mir beim besten Willen nicht vorstellen, dass ein Benutzer die Variable im oberen Beispiel verändern kann, selbst wenn er einen Wert für die Variable $blub an das PHP-Script senden würde, würde diese ja trotzdem kurz vor der MySQL-Abfrage neu belegt werden und zwar mit dem Wert "2", also in dem Beispiel. Erklärts mir bitte, wenn ich hier was auser acht lasse, aber ich komm einfach nicht drauf, was daran eine Sicherheitslücke sein kann.

Edit:
Falls es trotzdem eine Sicherheitslücke wäre, wäre diese dann wie folgt zu beheben?:

$blub = 2;
"select x from y where z = '".mysqli_real_escape_string($blub)."'"; 

Edit2:
So ich habe mir das ganze nun von einem Experten erkären lassen und wie ich schon vermutet hatte, liegst du "ApoY2k" falsch, das stellt in keiner Weise eine Sicherheitslücke da, da in dieser Variable keine Benutzereingaben oder sonstiges vorkommen, sondern diese in meinem PHP-Script fest definiert ist. War mir von anfang an klar, allerdings rätsel ich immer noch, was nun mermshaus mit seiner Andeutung wollte... der Experte hat übrigens das gesamte Script gesehen und das ist Fehlerfrei, bzw. ohne Sicherheitslücken... soviel dazu
achja und "ApoY2k":
Da disqualifizierst du dich eher aus jeder Diskussion über Sicherheit, weil eine (vor der Abfrage) fest definierte Variable nicht verfälscht werden kann... Also hatte ich doch recht... entweder hast du nicht den ganzen Thread gelesen, oder irgendwas falsch verstanden, oder eben doch nicht so viel Ahnung... Manchmal frag ich mich echt, wär hier überhaupt der Anfänger ist...

[ApoY2k]

Warum willst du um alles in der Welt einen schlechten Programmierstil rechtfertigen? Selbst wenn es keine Sicherheitslücke ist, ist es zumindest noch ein schlechter Stil. Völlig losgelöst von der Tatsache, ob es nun Injection-gefährdet ist oder nicht, bleibt es einfach schlampig.

Variablen in SQL-Statements werden über Platzhalter integriert und nicht einfach so reingeschrieben, das wird dir jeder, der halbwegs etwas vom Thema versteht auch sagen.

Wenn du ums Verrecken deinen Stil durchziehen willst, mach es wenigstens so:

"select x from y where z = '".$blub."'" 

Das ist dann zwar immernoch nicht gut, aber besser als vorher.

Dein Beispiel ist auch Humbug, wenn du die Variable vorher direkt als 2 definierst kannst du die 2 auch direkt so in das Statement schreiben... Die Variable wird garantiert irgendwie verarbeitet werden, und wenn dabei sonst was schiefgeht kannst du es einfach nicht vorhersagen.

Das ganze nennt man defensiv programmieren, google es mal. Wenn etwas schiefgehen kann, wird es das auch, und darauf muss man seine Programme vorbereiten. Ein nicht escaptes Statement wie deines kann, per Definition, schiefgehen. Und damit ist es von vornerein kein guter Stil und unsicher, es überhaupt zu benutzen.

Alleine die Möglichkeit, dass damit etwas schief gehen KÖNNTE ist Grund genug, es überhaupt nicht erst zu tun, sondern es so zu tun wie es schon hunderte Programmierer vor dir und vor mir getan haben. Du, ich und dein Experte sind nicht schlauer als die gesammelte PHP Entwickler und Programmierergemeinde zusammen.

[ImmerOn]

Hi,

also 1. wollte ich nicht wissen, ob es ein "schlampiger Programmierstil" ist, sondern ob dies eine Sicherheitslücke darstellt... Und eine Sicherheitslücke stellt es zu 100% nicht da, also war dein 1. Beitrag in dem behauptet hast, es wäre eine Sicherheitslücke, falsch...
Und in dieser "Beispielabfrage" werden keine Prepared-Statements verwendet, also wie soll ich dann den Wert mit einem Platzhalter füllen?

Der Beispielwert $blub kommt übrigens über ein Prepared-Statement aus der Datenbank...
Hier mal eine genaue Erklärung, wie meine Suchfunktion aufgebaut ist:

Als erstes gibt ein Benutzer in ein Formular den Nutzernamen ein.
Das Formular wird dann über den "suchen-Button" an das PHP-Script gesendet.
Dort wird als erstes über ein Prepared-Statement (also 100% sicher gegen SLQ-Injection) der User per "SELECT"-Abfrage ausgewählt, der mit der Formulareingabe übereinstimmt.
Falls der Benutzer nun irgwas schädliches in das Formular geschrieben hätte, also keinen echten Usernamen, dann würde meine SELECT-Abfrage (Prepared-Statement) kein Ergebnis liefern. Deswegen habe ich eine Abfrage eingebaut, falls die MySQL-Abfrage kein Ergebnis liefert, wird mein PHP-Script beendet.
Falls das Ergebnis == 1, werden die Werte aus der SELECT-Abfrage in Variablen gebunden, darunter dann eben auch $blub.

So wurde $blub mit einem Wert aus der Datenbank belegt, falls der Benutzer im Formular einen echten Usernamen eingegeben hat.
Und falls es kein echter Benutzername war, wird $blub überhaupt nicht belegt, weil das PHP-Script schon viel früher beendet wird

Also so ist das zu 100% sicher, obs jetzt ein optimaler Programmierstil ist, danach wurde nicht gefragt... es ist zwar sehr nett, wenn ihr mich darauf hinweißt, dass es schlampig programmiert ist und ich die Variable trotzdem escapen sollte, aber ihr habt ja fest darauf bestanden, dass es eine Sicherheitslücke wäre und deswegen war ich verunsichert, weil es eben keine ist...
Also das nächste Mal lieber gleich richtig sagen, dass es keine Sicherheitslücke ist, aber es ist schlampig programmiert.
So schwer ist das ja nicht und das hätte mir einigen Ärger und Mühen erspart.

Liebe Grüße.

ps:
Du meinst ja immernoch, das etwas schief gehen könnte... Da bin ich anderer Meinung, begründe mal bitte deine Meinung, wie da etwas schief gehen könnte...

[ezkimo]

Hi,

also 1. wollte ich nicht wissen, ob es ein "schlampiger Programmierstil" ist, sondern ob dies eine Sicherheitslücke darstellt... Und eine Sicherheitslücke stellt es zu 100% nicht da, also war dein 1. Beitrag in dem behauptet hast, es wäre eine Sicherheitslücke, falsch...
Und in dieser "Beispielabfrage" werden keine Prepared-Statements verwendet, also wie soll ich dann den Wert mit einem Platzhalter füllen?

Was genau hast Du denn jetzt an Apo 's Statement zum defensiven Programmierstil nicht verstanden? Grundsätzlich birgt Dein Script, zumindest soweit, wie Du es in diesem Thread dargestellt hast, ein Problem, welches im Zweifelsfall eben zur Katstrophe führen wird.

Als erstes gibt ein Benutzer in ein Formular den Nutzernamen ein.
Das Formular wird dann über den "suchen-Button" an das PHP-Script gesendet.
Dort wird als erstes über ein Prepared-Statement (also 100% sicher gegen SLQ-Injection) der User per "SELECT"-Abfrage ausgewählt, der mit der Formulareingabe übereinstimmt.
Falls der Benutzer nun irgwas schädliches in das Formular geschrieben hätte, also keinen echten Usernamen, dann würde meine SELECT-Abfrage (Prepared-Statement) kein Ergebnis liefern. Deswegen habe ich eine Abfrage eingebaut, falls die MySQL-Abfrage kein Ergebnis liefert, wird mein PHP-Script beendet.
Falls das Ergebnis == 1, werden die Werte aus der SELECT-Abfrage in Variablen gebunden, darunter dann eben auch $blub.

Das hast Du jetzt bereits mehrfach erklärt. Nur gibt es Dein mitgeteilter Codeschnipsel eben nicht her. Was wir nicht sehen, ist eben nicht da. Deswegen wird hier auch auf eklatante Sicherheitsprobleme hingewiesen. Du wolltest Hilfe und hier wird Dir anhand Deiner mitgeteilten Informationen bestmögliche Hilfe geboten. Wenn Dir diese Hilfe zu unpräzise sein sollte, müsstest Du Dich wahrscheinlich detaillierter mitteilen. Es wäre wahrscheinlich sehr viel einfacher gewesen, wenn Du Deine Frage und den Code, den Du im ersten Posting mitgeteilt hast, etwas ausführlicher formuliert hättest.

ps:
Du meinst ja immernoch, das etwas schief gehen könnte... Da bin ich anderer Meinung, begründe mal bitte deine Meinung, wie da etwas schief gehen könnte...

Das meint nicht nur Apo, sondern ist dies, wie schon beschrieben, ein Grundsatz. Wenn Du anderer Meinung bist, ist das eben so. Letztendlich bleibt nichts weiter als ein breites Schmunzeln über, weil Du wesentliche Grundsätze einfach über Bord schmeisst, als wären sie nur gutgemeinte Ratschläge von jemandem, den Du sowieso nicht ernst nimmst. In gewissen Kreisen nennt man so ein Verhalten dann auch beratungsresistent. Da darfst Du Dich dann auch nicht wundern, wenn diejenigen, die Dir eigentlich helfen wollten, hier einfach abspringen. Hat ja sowieso keinen Sinn.

[ImmerOn]

Hi,

ich nehme Ratschläge gerne an, solange diese für mich auch logisch erscheinen.

Aber jeder hier schreibt einfach mal, es wäre eine Sicherheitslücke / Risiko / Problem, aber kann nicht ein einziges Beispiel nennen, warum das eine Sicherheitslücke darstellen soll.

Und das was ich in meinem letzten Post geschrieben habe, sollte völlig ausreichen um erkennen zu können, das dort keine Sicherheitslücke vorhanden ist, solange man Ahnung von PHP hat. Das ist jetzt nicht böse gemeint, aber es regt einfach nur auf, wenn hier irgendwer schreibt, es sei eine Sicherheitslücke oder ein Risiko oder sonst was, aber dieses nicht belegt...
Solche Behauptungen bringen keinen weiter, wenn mal jmd. ein konkretes beispiel bringen würde oder seine Aussage irgendwie begründen / wiederlegen kann, dann wäre das Thema für mich gegessen.
Aber im moment ist nur wiederlegt, dass es ein unsauberer Programmierstil ist, aber in keinem Fall eine Sicherheitslücke.
Wenn ihr übrigens mit Sicherheitslücke / Risiko usw. "SQL-Injection" meint, dann bin ich ja beruhigt, denn da weiß ich selbst, dass an der beschriebene Stelle eine solche nicht durchgeführt werden kann.

Also bitte einfach mal mit einem Beispiel belegen / begründen, ansonsten sind diese Behauptungen haltlos und man meint eher, der der diese Behauptung aufstellt, hätte keine Ahnung von PHP weil er diese nicht begründen / belegen kann.

Übrigens sagt ja Apo auch in seinem letzten Post, dass es keine Sicherheitslücke ist.

Liebe Grüße und bitte keine Behauptungen mehr, sondern Begründungen... die Behauptungen helfen wirklich niemandem weiter.

EDIT:
@Vorposter:
Was genau willst du denn noch mehr von meinem Script wissen?
Hier nochmal zusammengefasst:
-Formularwert wird übergeben (kann gefährlich sein)
-Formularwert wird in MySQLi-Abfrage (prepared statements) verwendet, also egal was im Formularwert steht, die Abfrage ist zu 100% sicher gegen SQL-Injection (wenn dir das nicht klar ist, dann weißt du anscheinend nicht, wie die Prepared Statements funktionieren...)
-Über diese MySQLi-Abfrage wird geprüft, ob ein Nutzername in meiner Datenbank mit der Formulareingabe übereinstimmt, also "SELECT x FROM y WHERE x = ?"; und das "?" wird dann eben später mit der Formulareingabe belegt, also ganz normale MySQLi-Abfrage mit Prepared Statements...
-falls nun dieser Nutzername wirklich existiert, wird dieser in eine Variable gebunden (im Prepared Statement), also kommt der Wert für meine nächste Abfrage direkt aus der Datenbank (dort können sich keine bösartigen Codeschnipsel oder ähnliches befinden)
-falls der Nutzername nicht existiert, wird an dieser Stelle das PHP Script abgebrochen
-dann kommt eben eine wie oben gezeigte Abfrage, in der nun der Nutzername aus der Datenbank meiner letzten Abfrage oben verwendet wird.
Das heißt also: Dieser Wert kann NUR ein echter Nutzername sein, ansonsten kommt das PHP-Script nichtmal zu der letzten Abfrage. Wie man einen Nutzernamen nun für SLQ-Injection verwenden kann, ist denke ich jedem hier ein Rätsel, weil ja genau, sowas geht NICHT.

[ezkimo]

Worum ging 's jetzt eigentlich noch mal? Möchtest Du eine Lösung für Dein eigentliches Problem oder einfach nur hören, dass Du, mit den Informationen, die Du nachträglich geliefert hast, wahrscheinlich Recht hast, um Dein Ego aufzupolieren? Letzteres würde das leidige Thema dann einfach nur abschließen.

[ApoY2k]

also kommt der Wert für meine nächste Abfrage direkt aus der Datenbank (dort können sich keine bösartigen Codeschnipsel oder ähnliches befinden)

Und wie stellst du das sicher? Auch ein Benutzername wie L'oréal-Liebhaber-69 ist ein korrekter und valider Benutzername, den du eigentlich nicht ausschließen darfst. Also scheidet parsen nach ' aus.

Wie stellst du sicher, dass keine schädlichen Benutzernamen, Signaturen, E-Mail-Adressen oder sonstiges in die Datenbank kommen?

Wenn du dein Skript so benutzen willst, musst du das 100% failsafe implementieren, ansonsten kann es, selbst wenn der Wert aus der Datenbank kommt, krachen.

--------

Es geht bei SQL-Injection nicht nur um Eingaben von Benutzern durch das Frontend. Es geht allgemein um unerwartete Befehle, die den Kontext des Queries verändern.

Du arbeitest aber so, als könntest du die Werte erwarten, das du aber eigentlich nicht kannst. Ich erwähne das Stichwort erneut in der Hoffnung, du liest dich in das Thema ein: Defensives Programmieren.

Ich fasse es mal zusammen:

• Traue keinem. Nicht deinen Usern, nicht deiner Datenbank und nicht deinem Skript
• Wenn irgendetwas, egal wie unwahrscheinlich, abwegig oder dämlich, schief gegen kann, wird es irgendwann schiefgehen
• Sichere dein Skript gegen jegliche von außen kommenden Eingaben ab. Das schließt Daten aus einer externen Datenbank mit ein
• Deine MySQL-Datenbank ist extern, weil die Daten nicht innerhalb des Skriptes erzeugt werden, sondern von einem außerhalb des Skriptes liegenden Programm kommen
• Per Definition sind diese Daten damit a priori unsicher, und so sollten sie auch behandelt werden

[ImmerOn]

Hi,

@Apo:
Die Nutzernamen in meinem System können nur aus kleinen und großen Buchstaben bestehen.

Und ich danke dir für den Hinweiß auf den unsauberen Programmierstil und auch auf den Hinweiß des defensiven Programmierens.
Trotzdem wollte ich eben wissen, ob mein Script mit diesem unsauberen Programmierstil eine Sicherheitslücke darstellt. Ändern werde ich es so oder so, weil du ja schon sagtest, der Programmierstil wäre unsauber und auch wegen deinem Hinweiß auf defensive Programmierung.
Also nochmal zur defensiven Progammierung:
Wenn ich die Variable so "mysqli_real_escape_string($...)" in die Abfrage einsetze, ist das dann auch ein sauberer Programmierstil und defensiv programmiert?
Oder würde es aufs selbe rauskommen, wenn ich den Formular-Wert einfach am Anfang meines PHP-Scriptes auf Zeichen überprüfe, sodass dieser Wert also nur kleine und große Buchstaben enthalten darf und wenn das nicht der Fall ist, wird das Script abgebrochen?
Also für mich wäre das dasselbe in grün Aber würde gerne wissen, obs auch wirklich so ist.

Und @ezkimo:
Der User "mermshaus" hat eine Andeutung gemacht, das in meinem Script Sicherheitslücken vorhanden wären und genau das wollte ich begründet haben. Also ich will hier in keinster Weise mein Ego aufpolieren oder sonst was, sondern wollte NUR wissen, ob das nun eine Sicherheitslücke darstellt oder nicht. Ob ich Recht aber oder nicht, ist mir völlig egal... ich bin ein PHP-Anfänge und würde halt gerne wissen, warum etwas eine Sicherheitslücke ist, wenn schon behauptet wird, es wäre eine vorhanden.
Und wenn du hier auch noch schreibst es wäre eine Sicherheitslücke, ja was soll ich denn dann denken? Ich als PHP-Anfänger weiß vllt nicht unbedingt, was es für Sicherheitslücken gibt, deswegen Frage ich ja nach. Aber anscheinend bist du dann der größere Anfänger, wenn du immer noch davon ausgehst, hier eine Sicherheitslücke zu sehen.

Liebe Grüße.

[ApoY2k]

Es gibt noch etwas, was mit einem solchen Ansatz problematisch ist; du gehst davon aus, dass sich dein System nie ändern wird.

Das mag für einige Grenzfälle zutreffen, jedoch sind wahrscheinlich die meisten Programme in irgendeiner Form für ein längeres Leben ausgelegt.

Du kannst nicht vorhersehen, was in einem oder drei oder 10 Jahren mit deinem Programm sein wird. Vielleicht müssen irgendwann aus welchen abstrusen Gründen auch immer, plötzlich doch "exotische" Nicknamen unterstützt werden.

Alleine, weil diese Möglichkeit besteht (und du kannst nicht sagen, das würde sie nicht, denn theoretisch tut sie das), ist Grund genug, es von vornerein zu bedenken und dementsprechend zu handeln.

---------------

Der Vorteil, den dir Standardfunktionen wie real_escape und prepared Statement mit Parametern bringen, wirst du nicht selbst nachbilden können.

Warum solltest du auch, außer zu Lernzwecken? Es hat schonmal jemand gemacht! Du musst das Rad nicht neu erfinden, es gibt es bereits.

Aus diesem Grund rate ich dringen davon ab, irgendeine Art krudes Sicherheitssystem selbst zu stricken in der naiven Annahme, das wäre besser als bereits bestehende, getestete und in der Praxis bewährte Methoden.

Du baust doch auch kein eigenes Schloss an deinen Safe, nur weil du der Meinung bist, es wäre zuviel Aufwand.

-------------

Dein Skript wird mit jeder Bibliothek und Funktion, die sich tausendfach bewährt hat, sicherer, besser und für andere verständlicher.

Das ist ein Programmiergrundsatz, der nicht zwingend nur auf PHP zutrifft, sondern auf jede Programmiersprache der Welt.

[ImmerOn]

Hi,

ok danke für die Infos, hast mir sehr weitergeholfen.
Das Thema wäre dann für mich erledigt

Liebe Grüße.