Suche sicheres Login-Script mit Rechteverwaltung

Magical

Angesehenes Mitglied
Hallo,

ich habe jetzt schon ein bisschen gesucht..jedoch hauptsächlich ältere Beiträge (2005-2007) gefunden, was mir für das Thema Sicherheit schon veraltet sein kann.

Deswegen einfach mal hier die Frage: Kennt einer von euch ein gutes und vor allem sicheres Login-Script (vorzugsweise php & MySQL) mit Rechteverwaltung (mehrere verschiedene Gruppen mit unterschiedlichen Rechten) und Benutzer-Management?
Möglichst kostenlos - aber wenn eins sehr gut und auch noch anpassbar/leicht erweiterbar ist, wäre ich durchaus auch bereit, einen gewissen Betrag zu zahlen. Sicherheit geht vor!

Alternativ sind natürlich auch aktuelle und gut verständliche Tutorials möglich.

Bin über jegliche Tips dankbar.

Vielen Dank bereits im voraus.


 
QUOTE (Magical @ Di 24.02.2009, 21:52)Deswegen einfach mal hier die Frage: Kennt einer von euch ein gutes und vor allem sicheres Login-Script (vorzugsweise php & MySQL) mit Rechteverwaltung (mehrere verschiedene Gruppen mit unterschiedlichen Rechten) und Benutzer-Management?

Was soll das sein?

Man kann nicht auf eine bestehende Anwendung 'ein Script drüberstülpen' und damit die Sicherheit der Anwendung verbessern.

Eine Anwendung bietet entweder von sich her ein Login und eine ausdifferenzierte Berechtigung oder sie bietet nur ein Login ohne ausdifferenzierte Berechtigung. All das kann gut oder schlecht, sicher oder unsicher sein.

Und wenn die Anwendung all das an eine externe Sicherheitsinstanz delegiert (was in gewisser Weise bei den Aufrufberechtigungen innerhalb von .NET oder bei Gruppenvererbungsstrukturen innerhalb von Datenbankservern der Fall ist), dann erfordert das einen Aufwand auf der Ebene von Compiler- bzw. Betriebssystemherstellern.
 
Es geht mir hier nicht darum, irgendetwas "überzustülpen", sondern mehr um die Programmierung eines/mehrerer neuer Projekte(s), für welche ich einen sicheren Login benötige.
Normalerweise versuche ich mir die Dinge selbst anzueignen.
Allerdings habe ich beim Login meine Bedenken in Sachen Sicherheit - was würde es mir nutzen, wenn der Login zwar funktioniert aber vor Sicherheitslöchern nur so strotzt? (immerhin gibt es da ja mehrere Punkte, die man zur Absicherung beachten muss...)
Deswegen meine Frage nach einem entsprechenden Login-Script/Login-Benutzerverwaltungs-Script, welches sich aber noch entsprechend auf die eigenen Bedürfnisse modifizieren/erweitern lässt.
Sicher könnte man sich soetwas auch vollkommen neu programmieren lassen - aber woher weiß ich, dass dies dann auch sicher ist? Vielleicht nutzen andere ja bereits entsprechende Scripts (möglichst auf php & MySQL-Basis) und wissen, dass diese nach aktuellstem Stand keine Sicherheitslücken aufweisen...
 
Hallo,

Da kann ich Dir das access_user script empfehlen (PHP/mySQL):

www.finalwebsites.com/snippets.php?id=10


Es lässt sich sehr gut in die eigenen Applikationen einbauen lässt keine Wünsche offen; ich verwende
es seit längerer Zeit und bin sehr zufrieden damit.


 
QUOTE (Magical @ Mi 25.02.2009, 06:23)für welche ich einen sicheren Login benötige.


Sorry, aber Du suchst etwas, das es nicht gibt.

Eine Loginroutine prüft üblicherweise einen Nutzernamen und ein Passwort gegen eine Tabelle - klar kann man sogar da Sql-Injektionen zulassen.

Aber das hat nichts damit zu tun, ob bsp. (relativ willkürliche Beispiele)

(1) es später eine Url /seite.html?PID=5 gibt, bei der man durch die Änderung der Zahl hinten Dinge sieht, die man eigentlich nicht sehen darf (solche Lücken gab es mal bei der Nutzerverwaltung der Telekom),

(2) es irgendwo irgendwelche Lücken für Sql- oder XSS-Injektionen gibt,

(3) PHP-Code Dateipfade nachlädt, mit denen externer Code nachgeladen werden kann oder mit dem interne (nicht für die Öffentlichkeit bestimmte Dateien - etwa Konfigurationsdateien mit Passwörtern) sichtbar gemacht werden.


QUOTE (Magical @ Mi 25.02.2009, 06:23)Normalerweise versuche ich mir die Dinge selbst anzueignen.


Ich mache jetzt mal einen Schnellkursus 'Operation am offenen Herzen', ab dem nächsten Wochenende nehme ich Patienten an. Möchtest Du mein erster Patient werden? Ich bin auch viel preiswerter als die offiziellen Ärzte
tongue.gif



QUOTE (Magical @ Mi 25.02.2009, 06:23)Sicher könnte man sich soetwas auch vollkommen neu programmieren lassen - aber woher weiß ich, dass dies dann auch sicher ist? Vielleicht nutzen andere ja bereits entsprechende Scripts (möglichst auf php & MySQL-Basis) und wissen, dass diese nach aktuellstem Stand keine Sicherheitslücken aufweisen...


Weil Hinz und Kunz meint, irgendwelche 'tollen Scripte', Joomla-Addins oder ach so tolle Typo3-Komponenten in die Welt zu setzen. Schön, daß es jetzt mal Schäuble und Schalke erwischt hat.

Weil Hinz und Kunz überhaupt solche Systeme mit ständig clientseitig generiertem Sql-Code verwenden, die seit Jahren jeglichen Architekturerfordernissen für Web-Anwendungen widersprechen.
 
Jürgen hat schon Recht:

Was Du suchst, ist ein robustes Login-Script, das bei erfolgreicher Authentifizierung die entsprechenden Berechtigungen mitschleppt (oder alternativ bei jedem Seitenaufruf neu überprüft).

Ich habe so etwas für smartdentist.de geschrieben, und wenn Du mir Deine genauen Anforderungen mitteilst, kann ich schauen, ob es für Dich geeignet wäre.
 
Das Zikula-Framework wäre etwas für Dich.

Es wäre auch flexibel genug.
 
QUOTE (Jürgen Auer @ Mi 25.02.2009, 09:22)
...
Weil Hinz und Kunz meint, irgendwelche 'tollen Scripte', Joomla-Addins oder ach so tolle Typo3-Komponenten in die Welt zu setzen. Schön, daß es jetzt mal Schäuble und Schalke erwischt hat.

Weil Hinz und Kunz überhaupt solche Systeme mit ständig clientseitig generiertem Sql-Code verwenden, die seit Jahren jeglichen Architekturerfordernissen für Web-Anwendungen widersprechen.


Ich weiß nicht, wie ich meine Frage sonst formulieren sollte.
Ich habe doch bereits angegeben, dass ich selbst Bedenken wegen dem Punkt Sicherheit habe und erbat aufgrund dessen Unterstützung von erfahreneren. Und auch die haben es ja irgendwann mal gelernt.
Soweit ich mich erinnere ist auch Dein ursprünglicher Hintergrund nicht die Tabellenkalkulation - sondern Du hast es Dir entsprechend angeeignet.
Wieso sollen andere dies nicht auch Schritt für Schritt können und dabei mal um Hilfe bitten? (um eventuelle Fehler möglichst umfangreich bereits im Vorfeld zu vermeiden)
Sicher kann es immer Sicherheitslücken geben (wie man auch bei großen Unternehmen immer mal wieder feststellen kann) - diese gilt es dann natürlich auch schnellstmöglich zu schließen...deswegen möchte ich den Code durchaus auch noch verstehen (und würde nicht etwas einbauen, was ich selbst nicht nachvollziehen kann).

Es ging mir hier auch nicht nur um den Punkt preiswerter - aber im Anfangsstadium möchte man keine zigtausende für einen kleinen Baustein investieren.
Deswegen auch meine Anführung, dass ich durchaus auch bereit wäre dafür zu zahlen...aber halt keine Unsummen oder eine Programmierung des kompletten Projektes

Falls Du eine Auflistung hast, von Sicherheitsaspekten, die ein Script berücksichtigen sollte, würde ich mich sehr darüber freuen - dann wüßte ich zumindest schon worauf ich auf jeden Fall achten müßte.

P.S.: Ein paar Kenntnisse von php/MySQL und der entsprechenden Programmierung habe ich natürlich bereits schon - nur dies möchte ich gern ausbauen...
 
Ich finde, man sollte sich selbst damit intensiv beschäftigen und ein eigenes Framework entwickeln. Was nützt es dir, wenn das Loginscript sicher ist, aber an anderen Stellen Sicherheitsfehler pranken. Außerdem macht es doch Spass, Sowas zu entwickeln... :p

Am Besten alles schön Klassenbasiert....eben das Loginscript und ein sicheres GET, POST Replacement (Wrapper)...
 
QUOTE (rabattfuchser @ Mi 25.02.2009, 11:30) Ich finde, man sollte sich selbst damit intensiv beschäftigen und ein eigenes Framework entwickeln. Was nützt es dir, wenn das Loginscript sicher ist, aber an anderen Stellen Sicherheitsfehler pranken. Außerdem macht es doch Spass, Sowas zu entwickeln... :p

Am Besten alles schön Klassenbasiert....eben das Loginscript und ein sicheres GET, POST Replacement (Wrapper)...

Sicher macht es mir auch Spaß neue Dinge zu entwickeln - aber beim Login und der Nutzerverwaltung wollte ich einfach etwas vorsichtiger sein...um möglichst Sicherheitslöcher zu vermeiden

Gibt es dann vielleicht irgendwo eine Übersicht, über aktuell bekannte Sicherheitslöcher, die man direkt vermeiden sollte? (Ich bin mir sicher, dass diese sich ständig wandelt und entsprechend neue dazukommen - leider entwickeln "Hacker/Bad-guys" sich ja auch weiter und machen anderen das Leben schwer...)


Werd mir aber auch die anderen selbstverständlich anschauen :)


 
QUOTE (Magical @ Mi 25.02.2009, 11:15)Ich habe doch bereits angegeben, dass ich selbst Bedenken wegen dem Punkt Sicherheit habe und erbat aufgrund dessen Unterstützung von erfahreneren. Und auch die haben es ja irgendwann mal gelernt.
Soweit ich mich erinnere ist auch Dein ursprünglicher Hintergrund nicht die Tabellenkalkulation - sondern Du hast es Dir entsprechend angeeignet.


Gut, dann mache es genauso wie ich:

Programmiere zunächst zwei bis vier Jahre ausschließlich offline und fulltime - so, daß Du damit deinen gesamten Lebensunterhalt bestreitest. Dann hast Du genügend Erfahrungen, um ins Web zu gehen.

Das Problem dabei ist sehr einfach: Man macht genau an jenen entscheidenden Stellen Fehler, wo man denkt, man hätte keine gemacht. Und diese Fehler gibt es in keinen Büchern, auch auf keiner Webseite - weil sie schlicht und einfach anwendungsspezifisch sind. Bist Du dann mit so einer Anwendung offline, dann bemerkst Du das selbst und kannst es ausbügeln. Bist Du schon online, dann bist Du der zweite, der es bemerkt - das ist zu spät.

Im Web herrscht nun einmal Krieg - iss so. Was meinst Du, wieviele Versuche es selbst bei Server-Daten immer wieder gibt.


Bei Server-Daten hatte ich mich strategisch abgesichert:

(1) Strikte Verwendung korrekt aufgerufener gespeicherter Prozeduren, damit keine Sql-Injektionen technisch möglich. Die Verbindung vom Webserver darf nur gespeicherte Prozeduren ausführen. Selbst wenn jemand interaktiv am Webserver sitzen würde (nach einem Komplett-Hack), würde er mit jeder Select-Abfrage scheitern.

(2) Nutzung von Xsl-Transformationen für die Ausgabe, damit automatisches Maskieren von '<' usw., so daß XSS-Injektionen nicht funktionieren

Allein das liegt - bis man diese Werkzeuge ordentlich beherrscht - außerhalb der meisten PHP/mySql-Konstruktionen.

Und natürlich gab es auch da Fehler, die zu Lücken führten - nur wurden diese dann rechtzeitig bemerkt, weil das eine lange Vorlaufzeit hatte.

Die Sicherheit einer Anwendung gehört in den Kern einer Anwendung hinein - deshalb sehe ich nicht, wie das über ein externes Tool bereitgestellt werden könnte.

Wenn Du die Architektur von Server-Daten wissen willst - die ist kein Geheimnis:

Beim erfolgreichen Login wird ein Zufallsschlüssel in der internen Nutzertabelle bei diesem Nutzer hinterlegt, den schickt die Datenbank an den Webserver zurück. Dieser cacht diesen Schlüssel in den Session-Daten (aus dem Webserver geht das nie raus) und schickt ihn bei jeder Datenbank-Anforderung dieses Nutzers mit. Die gespeicherten Prozeduren verwenden diesen Schlüssel, um den Nutzer zu finden und zu prüfen, ob er die Berechtigung für die Aktion hat, welche die gespeicherte Prozedur als nächstes ausführt. Berechtigungen gibt es für den Zugriff auf Tabellen (jede Aktion einzeln), den Zugriff auf Systemobjekte, auf Abfragen, Ausgabeseiten und die Nutzerverwaltung selbst, die Berechtigung kann für selbst erstellte Zeilen, für Zeilen einer Gruppe oder für die ganze Tabelle erteilt werden. Alleine diese Logik benötigt drei eigene Systemtabellen.

Wie soll diese im Kern der Anwendung verankerte Logik über etwas Externes bereitgestellt werden?

Hinzu kommen noch jene 'Kleinigkeiten' wie eine schwache Verbindung zwischen Web- und Datenbankserver. Alleine das widerspricht den üblichen PHP/mySql-Konstruktionen fundamental, weil diese immer Select/Insert/Update/Delete - Berechtigungen des Webserver-Prozesses auf der Datenbank, auf allen Tabellen voraussetzen.

Eine Webanwendung kann man nicht nach dem Motto entwickeln: 'Wir lernen jetzt erst einmal Programmieren und pappen dann die Sicherheitsdinge anschließend drauf'. Diese Sicherheitslogik muß einen Kern bereitstellen, um den die Anwendung drumherum gebaut wird.

Und wenn Du das machst, dann wirst Du manchesmal fluchen: Etwa bei einer 'flexiblen Suche' über unterschiedliche Spalten. Mit ad-hoc - Sql-Code ist das banal - aber mache das mal als gespeicherte Prozedur, ohne dein eigenes Sicherheitskonzept aufzuweichen.

PS: So als Vergleich: Eine Webanwendung ist ein Haus, das von Fremden betreten wird. Warum darf sich nicht jeder als Architekt bezeichnen und Häuser konstruieren, die dann von Fremden betreten werden und 'dummerweise' einstürzen?
 
Wer den (mindestens) zweimaligen Datenklau bei der Jobbörse monster mitverfolgt hat, dürfte entspannt aufatmen...

-> Scheint kaum User zu tangieren.


Da sind extrem interessante Daten im Umlauf -> für Headhunter und Firmen.

Bestimmt recht lustig, wenn der Chef per E-Mail zugespielt bekommt, dass ein Mitarbeiter "anonym" einen neuen Arbeitgeber sucht. Vertrauen sinkt gegen null. Der Headhunter kann bzgl. des Mitarbeiters womöglich noch das Jahreseinkommen für die Arbeit im Folgeunternehmen runterhandeln, anstatt ihn durch höheres Einkommen zu locken; denn sein Job steht ein wenig in der Schwebe ^~^

Kannst nur hoffen, dass niemand das Know-How und einen Beweggrund hat, deine Site zu manipulieren -> dann reicht auch ein simples Loginskript.

Oder hoste mal testweise bei Evanzo -> da kommt man oft selbst nicht an die DB ran
laugh.gif
 
QUOTE (Jürgen Auer @ Mi 25.02.2009, 22:45)
...
Und wenn Du das machst, dann wirst Du manchesmal fluchen: Etwa bei einer 'flexiblen Suche' über unterschiedliche Spalten. Mit ad-hoc - Sql-Code ist das banal - aber mache das mal als gespeicherte Prozedur, ohne dein eigenes Sicherheitskonzept aufzuweichen.

PS: So als Vergleich: Eine Webanwendung ist ein Haus, das von Fremden betreten wird. Warum darf sich nicht jeder als Architekt bezeichnen und Häuser konstruieren, die dann von Fremden betreten werden und 'dummerweise' einstürzen?

stimme ich komplett zu =)

Diese PHP Techniken kannst du nachlesen im Buch:

PHP Sicherheit...
wink.gif


http://www.amazon.de/PHP-Sicherheit-PHP-My...35603832&sr=8-1
 
Vielen Dank für die Hinweise - werde mir die Dinge auf jeden Fall alle anschauen. :)

@Jauer: In dem Fall beginne ich bei dem Aufbau des Projektes mit dem Login und damit verbunden logischerweise auch mit den Sicherheitsüberlegungen - wobei meine Ansätze auch bisher schon in die erwähnten Richtungen gingen...aber ich nicht sicher war, ob damit auch wirklich alles abgedeckt ist. Ich weiß, vollkommene Sicherheit wird man nie erhalten (es sei denn man lässt es offline, was aber ja nicht Sinn und Zweck der Sache bei einem Online-projekt ist) - und auch die Usability sollte nicht allzu stark leiden. Deswegen fragt man auch manchmal nach Unterstützung oder auch Anregungen/Tutorials...um möglichst viel abzudecken...und nicht doch bekannte Schlupflöcher zu übersehen
 
Hallo Magical

lass Dich nicht ins Boxhorn jagen, ich habe dafür Verständnis dass man ja auch Mal anfangen muss.

Nimm Zikula (www.zikula.org)

Es ist ein PHP-CMS ähnlich wie Joomla oder Drupal, mit dem unterschied, dass man viel einfacher eigene Applikationen integrieren kann.
Es kann auch als Framework gebraucht werden. Es verwaltet User, Passwörter, Security, Zugriffsrechte mit einem unendlichen Rollen- und Hierarchiesystem, es hat viele Sprachpacks.

Für einen Start reicht es allemal aus, und es ist sicher - hat einen guten security Track Record über die letzten Jahre.

Eigene Apps kannst Du in der Mitte von Zikula integrieren, oder in Blocks.
Natürlich bist Du für die Sicherheit Deines eigenen Codes selbst verantwortlich.
Bei Zikula ist das so, dass Du sicher fährst, wenn Du für Deine Scripte genaue Input Validation vornimmst - den Rest deckt Zikula ab.

Der Clou dabei: du kannst in Deiner App dann API funktionen nutzen. So einfach wie z.B.
CODE echo "Dein Username ist: ".pnusergetvar('uname');

und dann wird der Username des eingeloggten Users angezeigt.

Bei Interesse kann ich auch erklären, wie das genau alles geht.
 
QUOTE (PH @ Fr 27.02.2009, 12:07)Bei Zikula ist das so, dass Du sicher fährst, wenn Du für Deine Scripte genaue Input Validation vornimmst - den Rest deckt Zikula ab.

Die Input-Validierung (Trau nie, nie, nie Benutzereingaben) ist die Lücke, über welche die meisten Hacks funktionieren.

Die entscheidende Lücke bleibt also offen.
 
QUOTE (Jürgen Auer @ Fr 27.02.2009, 16:49)
QUOTE (PH @ Fr 27.02.2009, 12:07)Bei Zikula ist das so, dass Du sicher fährst, wenn Du für Deine Scripte genaue Input Validation vornimmst - den Rest deckt Zikula ab.

Die Input-Validierung (Trau nie, nie, nie Benutzereingaben) ist die Lücke, über welche die meisten Hacks funktionieren.

Die entscheidende Lücke bleibt also offen.

Ja, aber nur für seine EIGENEN Scripte.
Da gibt es sowieso keinen anderen Weg, als eigene Scripte selber abzusichern.


Etwas, was er noch machen könnte wäre, seine Scripte mit einem Code Generator zu produzieren, der dann sämtliche Inputs validiert. So mach ich es.
Dann wäre die Lösung sicher.

Die meisten Scriptgeneratoren supporten Custom Includes am Header und Footer, so ist die Integration in Zikula sehr einfach.


Zusätzlich habe ich noch Mod_Security installiert, so dass grobe Sachen schon im Request abgefangen werden.
 
QUOTE (PH @ Fr 27.02.2009, 15:56)Ja, aber nur für seine EIGENEN Scripte.
Da gibt es sowieso keinen anderen Weg, als eigene Scripte selber abzusichern.

Natürlich gibt es den: Ausschließlich gespeicherte Prozeduren verwenden und Daten über Xsl-Transformationen ausgeben.

Habe ich oben alles beschrieben.

'Input Validierung' ist eine Krückentechnik, auf die komplett verzichtet werden kann. 'Input Validierung' kann nur dann überhaupt ein Problem werden, weil man grundsätzlich falsche Techniken für die Datenverarbeitung nutzt.

Gespeicherte Prozeduren und Sql gibt es sehr viel länger als Sql-Injektionen bekannt sind (dieses Thema tauchte erst um etwa 2000 auf): Erst die Unsitte von Ad-hoc - Code produziert das Problem.


Wenn solche Systeme auch noch weit verbreitet sind, dann wird die Notwendigkeit einer Input-Validierung behauptet - anstatt daß man eine gescheite Grundtechnik nutzt.
 
Zurück
Oben