nicht angemeldet
Nur SELECT zulassen
Hallo Forum,
ich möchte einen String prüfen.
Der String enthält eine in mysql5 einzusetzende Query.
Da es unnötig ist, irgendetwas anderes als eine SELECT-Query zuzulassen, möchte ich alles, was nicht einem reinen SELECT entspricht, auch nicht zulassen.
Reicht es dazu aus, zu prüfen, ob die ersten 6 Buchstaben "SELECT" enthalten? Was wäre aber dann mit eventuellen Subqueries, die zwar mit "SELECT" beginnen, aber danach Schaden verursachen könnten?
Wie würdet Ihr alles außer einem einfachen "SELECT" sperren?
Grüße, Richard
-
Moin!
ich möchte einen String prüfen.
Der String enthält eine in mysql5 einzusetzende Query.
Da es unnötig ist, irgendetwas anderes als eine SELECT-Query zuzulassen, möchte ich alles, was nicht einem reinen SELECT entspricht, auch nicht zulassen.
MySQL erlaubt, für einen DB-Account Zugriffsrechte zu setzen, und zwar detailliert für diverse Querys, einschränkbar auf Datenbanken, Tabellen oder Spalten.
Nutze diese Möglichkeit, sie wird dir mehr bringen, als wenn du jetzt einen SQL-Parser schreiben musst.
- Sven Rautenberg
-
Hi Sven,
MySQL erlaubt, für einen DB-Account Zugriffsrechte zu setzen, und zwar detailliert für diverse Querys, einschränkbar auf Datenbanken, Tabellen oder Spalten.
Es müsste aber möglich sein, diese Rechte per php für diese eine Query zu setzen. Ohne dabei die DB selber zu beschränken.
Das geht??
Im php-script?
Hast Du dazu mal den entsprechenden Link?
Grüße, Richard
-
MySQL erlaubt, für einen DB-Account Zugriffsrechte zu setzen, und zwar detailliert für diverse Querys, einschränkbar auf Datenbanken, Tabellen oder Spalten.
Es müsste aber möglich sein, diese Rechte per php für diese eine Query zu setzen. Ohne dabei die DB selber zu beschränken.
Du kannst einen weiteren Benutzer anlegen den genau dieses Script, welches diese Abfrage ausführt, verwendet.
Das geht??
Ja
Im php-script?
Ja
Hast Du dazu mal den entsprechenden Link?
-
Du kannst einen weiteren Benutzer anlegen den genau dieses Script, welches diese Abfrage ausführt, verwendet.
Ich glaube, das kann ich bei meinem Account bei meinem Provider nicht.
Muss ich dann doch wohl die Query selber parsen, oder?
Danke für den Link.
Richard
-
Muss ich dann doch wohl die Query selber parsen, oder?
Wie wäre es, wenn du den Provider bittest, dir einen 2. Benutzer einzurichten?
btw: wozu soll das überhaupt gut sein? Willst du Benutzereingaben in eine Abfrage einbauen und diese absichern?
-
Wie wäre es, wenn du den Provider bittest, dir einen 2. Benutzer einzurichten?
Eher nicht ;-)
btw: wozu soll das überhaupt gut sein? Willst du Benutzereingaben in eine Abfrage einbauen und diese absichern?
Übersteigertes Sicherheitsbedürfniss. Die Datei kennt keiner, der Aufruf der Datei selber ist auch scriptseitig gesichert, einen kleinen Parser für die Query habe ich zusätzlich auch geschrieben.
Im Grunde will ich selber die Query, die ich sonst bei Benutzung des Scriptes in Selbiges eintrage und per ftp überspiele, über ein Formular eintragen (der Bequemlichkeit halber).
Grüße, Richard
-
Wie wäre es, wenn du den Provider bittest, dir einen 2. Benutzer einzurichten?
Eher nicht ;-)
G'schamig?
btw: wozu soll das überhaupt gut sein? Willst du Benutzereingaben in eine Abfrage einbauen und diese absichern?
Übersteigertes Sicherheitsbedürfniss. Die Datei kennt keiner,
Das ist kein Argument - nur weil die Datei keiner kennt ist es nicht notwendigerweise sicherer, du glaubst nur, dass sie keiner kennt und nicht etwa durch Zufall (Brute Force) findet :)
Im Grunde will ich selber die Query, die ich sonst bei Benutzung des Scriptes in Selbiges eintrage und per ftp überspiele, über ein Formular eintragen (der Bequemlichkeit halber).
Warum nimmst du nicht ein fertiges Frontend? MySQL Administrator, phpMyAdmin ...
Warum schreibst du nicht ein Script, welches nur die nötigen Parameter entgegen nimmt und nicht gleich eine komplette Abfrage?
Aber was auch immer du vor hast: in solchen Fällen ist ein eingeschränkter SQL-Benutzer die einzige vernünftige Möglichkeit, sicher zu sein. Überhaupt sollte ein Produktivbenutzer immer nur die Rechte haben, die er auch tatsächlich braucht (gerne auch mehrere Davon) - z.B. kann das Backend einen anderen Benutzer haben als das Frontend oder die Session-Verwaltung des Frontends.
-
G'schamig?
Nein. Ich glaube, sowas macht Strato für einen nicht ;-) Jedenfalls nicht bei Webhosting bzw. managed Servern.
Das ist kein Argument -
Stimmt. Aber die Sicherung über das Login-System schon. Und der Parser, der alles rausschmeißt, was nach was Anderem als "SELECT" aussieht, auch. ;-)
Warum nimmst du nicht ein fertiges Frontend? MySQL Administrator, phpMyAdmin ...
Nehm ich. Aber für andere Dinge als grad das jetzt. Im Prinzip ginge alles auch über phpmyadmin, aber mein Script batcht das Ganze.
Warum schreibst du nicht ein Script, welches nur die nötigen Parameter entgegen nimmt und nicht gleich eine komplette Abfrage?
Könnte ich auch. Würde mich aber nicht davor schützen, die Eingabe zu parsen. Ich dachte, man könnte das einigermaßen effektiv durch Stringüberprüfung machen.
Aber was auch immer du vor hast: in solchen Fällen ist ein eingeschränkter SQL-Benutzer die einzige vernünftige Möglichkeit, sicher zu sein. Überhaupt sollte ein Produktivbenutzer immer nur die Rechte haben, die er auch tatsächlich braucht (gerne auch mehrere Davon) - z.B. kann das Backend einen anderen Benutzer haben als das Frontend oder die Session-Verwaltung des Frontends.
Das ist ein für mich ein gutes Argument. Mal unabhängig von dem Scriptchen, um das es hier gerade geht. Wobei, was heißt schon Scriptchen? Der maximale Schaden, den jemand darüber anrichten kann bestimmt, ob es ein Scriptchen oder ein Script ist ;-)
Schönen Gruß, Richard
-
Hi!
Nein. Ich glaube, sowas macht Strato für einen nicht ;-) Jedenfalls nicht bei Webhosting bzw. managed Servern.
Nicht? Wenn Du eh phpMyAdmin verwendest, dann probiers doch einfach aus.
--
Signaturen sind blöd!
-
-
-
-
-
-
-
-
-
Hi!
Reicht es dazu aus, zu prüfen, ob die ersten 6 Buchstaben "SELECT" enthalten? Was wäre aber dann mit eventuellen Subqueries, die zwar mit "SELECT" beginnen, aber danach Schaden verursachen könnten?
SELECT kann nur abfragen. Subquerys, auch bekannt unter dem Namen Subselect (und nicht etwas Subdelete etc.), können ebenfalls nur abfragen. Wenn du kein mysqli_multi_query() verwendest, lassen sind auch keine weiteren Statements anhängen. Aber auch mit einem SELECT, das danach beliebig gestaltet werden kann, lassen sich Daten abfragen, die du nicht preisgeben willst, wie beispielsweise deine Geschäftsgeheimnisse oder auch Systemtabellen wie die, in der die Usernamen und Passwort-Hashes stehen.
Lo!
-
SELECT kann nur abfragen. Subquerys, auch bekannt unter dem Namen Subselect (und nicht etwas Subdelete etc.), können ebenfalls nur abfragen. Wenn du kein mysqli_multi_query() verwendest, lassen sind auch keine weiteren Statements anhängen. Aber auch mit einem SELECT, das danach beliebig gestaltet werden kann, lassen sich Daten abfragen, die du nicht preisgeben willst, wie beispielsweise deine Geschäftsgeheimnisse oder auch Systemtabellen wie die, in der die Usernamen und Passwort-Hashes stehen.
Hi dedlfix,
danke für die Hinweise.
Wie prüfe ich, ob ich mysqli_multi_query() verwende?
Und: Reicht es aus, wenn ich ein array mit Wörtern erstelle, die in der Query nicht vorkommen dürfen und dort auch die Tabellennamen reinnehme, die nicht abgefragt werden dürfen?
Schönen Gruß, Richard
-
Hi!
Wie prüfe ich, ob ich mysqli_multi_query() verwende?
Du solltest es wissen. Wenn dir die Funktion nicht bekannt ist, hast du entweder Code, der nicht von dir geschrieben ist, oder du verwendest sie nicht (stattdessen mysql_query() oder mysqli_query()).
Und: Reicht es aus, wenn ich ein array mit Wörtern erstelle, die in der Query nicht vorkommen dürfen und dort auch die Tabellennamen reinnehme, die nicht abgefragt werden dürfen?
Ich erteile keine Absolution für solche Fragen, da auch ich nicht bis ins Letzte weiß, was man unter welchen Umständen (und Verkettungen solcher) ausnutzen kann. Ich kann dir nur empfehlen, dir die SELECT-Syntax genauestens anzuschauen und selbst zu entscheiden, welche Bestandteile du davon nicht ausgeführt haben möchtest. Dazu gehört auch die Liste aller Funktionen und Operatoren, die innerhalb einer SELECT-Abfrage verwendet werden können. Und außerdem gibt es noch so nette syntaktische Dinge, wie Hexadezimalzahlen, die als String angesehen werden. Gut, damit kann man zwar meines Wissens keine Tabellen- oder Feldnamen verschleiern, aber wer weiß schon, was noch alles möglich ist, ganz zu schweigen von möglichen Lücken in MySQL selbst.
Lo!
-
-