Präventiv: Dummy-User mit ID = 1

[k00ni]

Da viele SQL-Injections darauf abzielen, sich Useraccounts zu holen, die Adminrechte haben, wäre es doch sinnvoll, statt den Admin als ersten User, lieber einen unpriviligierten User zu nehmen.
Ich kenne SQL-Injections der Form:
 

\' OR 1=1 #

 
 
Diese bewirken bei erfolgreicher Ausführung, dass der erste User der Usertabelle ausgewählt wird. Dies wäre bei 100 % der pSys-Installationen der Administrator. Hier würde jetzt der Dummy-User ins Spiel kommen. Der Angreifer bekommt zwar sein SQL-Injection durch, aber ist dann nur User und nicht Admin.

Da viele SQL-Injections darauf abzielen, sich Useraccounts zu holen, die Adminrechte haben, wäre es doch sinnvoll, statt den Admin als ersten User, lieber einen unpriviligierten User zu nehmen.[/quote]
Das stimmt nicht. Die meisten SQL-Injections dürften darauf abzielen, Befehle in der Datenbank auszuführen. Das Rechtesystem des PSys hat aber keinen Effekt auf das Rechtesystem in der Datenbank, da sämtliche Zugriffe über einen Datenbankaccount abgehandelt werden.

Diese bewirken bei erfolgreicher Ausführung, dass der erste User der Usertabelle ausgewählt wird.[/quote]
Das ist nicht korrekt.

Dies wäre bei 100 % der pSys-Installationen der Administrator.[/quote]
Stimmt auch nicht.

Der Angreifer bekommt zwar sein SQL-Injection durch, aber ist dann nur User und nicht Admin.[/quote]
Wie ich bereits schrieb: Die meisten SQL-Injection-Angriffe wollen Code in der Datenbank ausführen. Dazu sind keine Rechte im Forum notwendig, sondern nur Datenbankrechte.
Dein Vorschlag ist reine Symptombehandlung. Eine echte Kur wäre es, wenn Datenbankabfragen gegen eine Whitelist validiert und bei nicht bestehen die Ausführung abgebrochen und entsprechende Nachrichten geloggt würden.

[k00ni]

Das ist nicht korrekt.[/quote]
Das stimmt schon. Schaue nochmal in meinen Text, da war von einer speziellen SQL-Injection die Rede.

Ich kenne SQL-Injections der Form: 

\' OR 1=1 #

 
 
Diese bewirken bei erfolgreicher Ausführung das der erste User der Usertabelle ausgewählt wird.
[/quote]
Die Frage ist hier nicht von mir das komplette System umzustellen. Da gäbe es sicher sehr viele Möglichkeiten. Sondern einfach die derzeitige Situation etwas zu verbessern.
Ok, dass es SQL-Injection für die direkte Ausführung von Code in der Datenbank gibt, daran habe ich ersten Moment nicht gedacht, sondern war eher auf das pSys + die Userverwaltung bedacht.
Mein Vorschlag war ja eher erstmal dazu gedacht, so etwas anzuregen. Und wie schon im Titel steht, es ist eine Präventivmaßnahme, die solche von mir angesprochenen Injections stoppt. Vielleicht aber auch nicht. Das wäre die Frage.
Andererseits könnten dann die Angreifer direkt den User mit ID = 2 angreifen. Das würde den Dummy-User nutzlos machen.
Das man hier im pSys mehr in diesem Bereich machen könnte, ist schon oft angesprochen wurden und ich wäre auch der Meinung viele Dinge anders zu machen. Aber als miniwinzigen Fortschritt könnte man einen User mit ID = 1 anlegen und wäre somit vor diesen Angriffen besser geschützt (nicht immun).

[Powie]

K00ni:
 

OR 3=3

 
 
würde genauso funktionieren.  /uploads/emoticons/icon_e_wink.gif.c059000ae48ff64afa53be0962c021f2.gif\" alt=\":wink:\" />  [/uploads/emoticons/icon_e_surprised.gif.a005678239f11b45b64b526b2c82e9a1.gif\" alt=\":o\" />]  [/uploads/emoticons/icon_e_surprised.gif.a005678239f11b45b64b526b2c82e9a1.gif\" alt=\":o\" />]  [/uploads/emoticons/icon_e_surprised.gif.a005678239f11b45b64b526b2c82e9a1.gif\" alt=\":o\" />]
Wenn du nach ID sortierst wäre die ID = 1 zwar die erste Zeile, und bei einer neuen Tabelle würde die auch als erste geleifert werden, unsortiert aber könnte da rein zufällig jede beliebige Zeile ausgegeben werden. Aber was Statler versucht zu erklären ist, das der Angriff nicht darauf abziehlt diese eine spezielle Zeile aus der DB zu bekommen, sondern \"eigene\" SQL\'s einzuschleussen um Daten zu ändern / auszuspähen.

[Powie]

Blöder Vergleich: Ein Einbrecher bricht auch nicht ein um dir die Türen und Fenster kaputt zu machen, sondern um Gegenstände aus der Wohnung zu entwenden, auch wenn dabei diese zuerst kaputt gehen und der Schaden vielleicht höher ist der der entwendeten Dinge.  :gaga:

[k00ni]

Wenn du nach ID sortierst wäre die ID = 1 zwar die erste Zeile, und bei einer neuen Tabelle würde die auch als erste geleifert werden, unsortiert aber könnte da rein zufällig jede beliebige Zeile ausgegeben werden.[/quote]
Der eigentliche Ansatz war beim Login. Dort wird ja die Username / Passwort - Kombination überprüft. Dort gibt es aber keine Sortierung, oder? Ich denke nicht und deshalb dürfte MySQL die Datensätze ASC mäßig sortieren. Dies bedeutet, dass der erste User, dann der zweite ...
Dieses Beispiel war nur auf einen kleinen Fall beschränkt. Diesen habe ich bei einigen Sicherheits-Tipps-Seiten, wie http://www.strassenprogrammierer.de/sql-injection-injektion-angriff_tipp_543.html\" rel=\"external nofollow\">dieser gesehen. Nur wird dort versucht, die Datenbank zu löschen.

Aber was Statler versucht zu erklären ist[/quote]
Jo, es gibt viele Gründe für solche Angriffe. Ob nun als Administrator fungieren (und damit vielleicht im Backend eigene Dateien hochladen) oder Daten in der DB ändern/löschen/einfügen oder gleich das ganze System abschiessen, vieles ist möglich. Das streite ich ja auch nicht ab. Es war hier auch nur von einer Möglichkeit die Rede, die einen kleinen Angriffsfall aushebeln \"könnte\".
Wie dem auch sei, das Thema wäre gegessen. Bleibt nun die Frage, ob sich im Bezug auf die Datenbanksicherheit in Zukunft Änderungen ergeben werden?

[Powie]

Bleibt nun die Frage, ob sich im Bezug auf die Datenbanksicherheit in Zukunft Änderungen ergeben werden?[/quote]
Komische Frage, viele Tage nachdem dir bekannt wurde das nun eine DB Klasse vorhanden ist die dies unter anderem verbessern wird  /uploads/emoticons/icon_e_wink.gif.c059000ae48ff64afa53be0962c021f2.gif\" alt=\":wink:\" />  [/uploads/emoticons/icon_e_surprised.gif.a005678239f11b45b64b526b2c82e9a1.gif\" alt=\":o\" />]  [/uploads/emoticons/icon_e_surprised.gif.a005678239f11b45b64b526b2c82e9a1.gif\" alt=\":o\" />] .
Aber im Endeffekt, Funktionen um sich gegen SQLInjection abzusichern gibt es schon immer, ich habe diese nicht immer so angewendet wie notwendig, aber gerade im aktuellen Rework wird an vielen Stellen dies extrem verbessert. Ob man dies dann mit den Standardfunktionen oder einer Klasse macht, das ist da fast zweitrangig. Ich bin der Meinung das man nie 100% sicher sein wird, da man ja auch auf die benutzten Third-Party Module vertrauen muss, bzw. auf mySQL, php, ja sogar den Server selbst. Es nutzt mir nichts meine Applikation auf Tod und Teufel abzusichern, auf der anderen Seite aber dann durch ein unsicheres Passwort jemanden in meinen Server reinzulassen.
Zumidnest haben wir mit OpenSource, bzw. unkompilierter Software bei der der Quelltext lesbar bleibt, den Vorteil das wir nicht alleine die schwachstellen im Quelltext finden können sondern viele andere Leute auch. Es nutzt nichts dort 100 mal drüber zu schauen, man erkennt die Schwachstellen nur aus dem eigenen Blickwinkel. Probleme und Löcher aus anderen Sichtweisen sehen andere Leute, leider nicht immer mit den besten Absichten /uploads/emoticons/icon_e_smile.gif.4a0acefcb917340d2c82e5239c009e6e.gif\" alt=\":)\" />

Das stimmt schon. Schaue nochmal in meinen Text, da war von einer speziellen SQL-Injection die Rede. [/quote]
Nein. Du hast geschrieben, dass viele SQL-Injections [sql-Injection-Angriffe] dazu dienen, User-Accounts zu stehlen. Dies habe ich verneint.

Da viele SQL-Injections darauf abzielen, sich Useraccounts zu holen, die Adminrechte haben, wäre es doch sinnvoll, statt den Admin als ersten User, lieber einen unpriviligierten User zu nehmen.[/quote]
Der Gedankenfehler hierbei ist, dass es völlig gleichgültig ist, ob der \"erste\" User (es gibt keinen festen ersten User, da die Sortierung von der Anfrage an die Datenbank abhängt), da injizierte Befehle nicht davon abhängen, welche Daten selektiert werden.

Die Frage ist hier nicht von mir das komplette System umzustellen. Da gäbe es sicher sehr viele Möglichkeiten. Sondern einfach die derzeitige Situation etwas zu verbessern. [/quote]
Wenn mein Auto schrott ist, hilft es eben nicht, die Reifen zu wechseln. Gut gemeint ist eben nicht gut getan.

Ok, dass es SQL-Injection für die direkte Ausführung von Code in der Datenbank gibt, daran habe ich ersten Moment nicht gedacht, sondern war eher auf das pSys + die Userverwaltung bedacht.Mein Vorschlag war ja eher erstmal dazu gedacht, so etwas anzuregen. Und wie schon im Titel steht, es ist eine Präventivmaßnahme, die solche von mir angesprochenen Injections stoppt. Vielleicht aber auch nicht. Das wäre die Frage.
[/quote]
Mir erscheint es eher, dass du überhaupt nicht verstanden hast, wie die von dir beschriebene Lücke genau funktioniert. Der von dir genannte Befehls-Postfix selektiert keinen User, sondern stellt einfach nur eine erfüllte Bedingung für die Selektion aller User da und nicht nur eine erfüllte Bedingung für alle User. Das hier dann zufällig der Administrator ausgewählt wird, hängt davon ab, in welcher Weise das Record Set sortiert wird.

Andererseits könnten dann die Angreifer direkt den User mit ID = 2 angreifen. Das würde den Dummy-User nutzlos machen. [/quote]
Nicht nur das. Ein ausreichend motivierter Angreifer wird direkt auf User mit Administratoren-Rechte joinen. Es ist einfach völlig egal, welche User-ID Administratoren-Rechte besitzt.

Dieses Beispiel war nur auf einen kleinen Fall beschränkt. Diesen habe ich bei einigen Sicherheits-Tipps-Seiten, wie dieser gesehen. Nur wird dort versucht, die Datenbank zu löschen.[/quote]
Lustigerweise funktioniert der dort angewendete Versuch nur dann, wenn das Opfer mysqli() im Allgemeinen und (mysqli_)multi_query im Besonderen verwendet.

Jo, es gibt viele Gründe für solche Angriffe. Ob nun als Administrator fungieren (und damit vielleicht im Backend eigene Dateien hochladen) oder Daten in der DB ändern/löschen/einfügen oder gleich das ganze System abschiessen, vieles ist möglich.[/quote]
Dazu brauchst Du im PSys ja nicht mal direkten Zugriff auf die Datenbank. Das geht auch so.

Ich bin der Meinung das man nie 100% sicher sein wird, da man ja auch auf die benutzten Third-Party Module vertrauen muss, bzw. auf mySQL, php, ja sogar den Server selbst.[/quote]
Dies hört sich für mich sehr nach einer Ausrede an. Es stimmt zwar, dass man sich nicht auf nicht-selbstgeschriebene Teile verlassen kann, jedoch sollte man sich eben auf die Eigenkreationen verlassen können. Da wäre ein wenig Sensibilität statt Defätismus durchaus angebracht.

[Powie]

Dies hört sich für mich sehr nach einer Ausrede an.[/quote]
Das hat  nichts mit Ausrede zu tun, das ist ein  /uploads/emoticons/icon_e_wink.gif.c059000ae48ff64afa53be0962c021f2.gif\" alt=\":wink:\" />  für Leute die 100% Sicherheit offerieren, welche durch die zuletzt genannten Gründe meist nicht herstellbar ist.
Probleme beim pSys sind mir sehr wohl bekannt und werden gerade aktuell beim Rework gefunden und behoben. Meist ist es die ungenügende Filterung von Daten die in mySQL Queries einfliessen. Dafür brauche ich auch keine Ausrede  /uploads/emoticons/icon_e_smile.gif.f7ec63a2b1c3d90a9415e40455642502.gif\" alt=\":-)\" />

Probleme beim pSys sind mir sehr wohl bekannt und werden gerade aktuell beim Rework gefunden und behoben. Meist ist es die ungenügende Filterung von Daten die in mySQL Queries einfliessen. Dafür brauche ich auch keine Ausrede[/quote]
Schön. Wolltest Du nicht mal CVS-Accounts verteilen?

[tschinski]

Hachja, ich darf hier mal anmerken, dass der werte Powie damals sämtliche Übergabevariablen ohne Escapen direkt an die DB weitergeleitet hat, ein Verfahren, dass nem Kumpel von mir und mir selber einige Nächte gekostet hat, um es wenigstens einigermaßen sicher zu bekommen.

Hachja, ich darf hier mal anmerken, dass der werte Powie damals sämtliche Übergabevariablen ohne Escapen direkt an die DB weitergeleitet hat, ein Verfahren, dass nem Kumpel von mir und mir selber einige Nächte gekostet hat, um es wenigstens einigermaßen sicher zu bekommen.[/quote]
Das und noch viel mehr macht der Powie gelegentlich sogar heute noch. An dem Tag, an dem PHP6 veröffentlicht und breit installiert wird - wo es keine magic_quotes_* mehr geben wird - werden all die Betreiber von PSys (und den restlichen Skripten von Powie) mächtig auf die Schnauze fallen.
Ich bunker schon mal Popcorn.