• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

[PHP|(My)SQL] Wissensdatenbank aufbauen inkl. "auffrischen" / Sicherheit?

alea

Neu angemeldet

Registriert
19 März 2016
Beiträge
105
Hallo Leute!

Ich wollte mich die nächsten Wochen mal wieder etwas mit HTML, CSS, PHP und (My)SQL beschäftigen (das ist das was ich noch von früher kenne :)). Der Hintergrund dabei ist, dass ich mir das wieder aneignen/auffrischen möchte und dann diese Fähigkeit auch dafür nutzen möchte, mir eine Wissensdatenbank mit Abfrage vom Wissen aufzubauen - inkl einer Verwaltung von Artikel (also ein eigener, kleiner Blog). Garantiert gibt es so etwas, aber dann "lerne" ich nichts dabei...

Ich komme mit Code klar und verstehe in dem Bereich so einiges, habe aber ein Problem, womit ich nicht wirklich klar komme:
Wie schaffe ich es, mir ein sicheres Login aufzubauen? Wenn ich das ganze aufziehe, dann sollte es "sicher" sein und keine Möglichkeit sollte gegeben sein, das jemand fremdes sich einloggen kann, einen Code ausführen kann, etc. So tief sitze ich nun nicht in der Materie. Was kann ich da machen?

Wieso das Ganze?
Das Unternehmen, für welches ich tätig bin, erweitert seine Standorte und ich möchte
1) die Fach-Vokabeln quer durch alle Sprachen, die ich beherrsche, jederzeit "abfragen" können,
2) möchte ich eine Art "Fragen / Antworten" - Möglichkeit mir selbst anbieten. Querbeet aus der DB, damit ich das Fachwissen stets aktuell halten kann und
3) dachte ich auch daran, gewisse Werte wöchentlich zu speichern, um so eine Entwicklung zu erkennen, etc.

Mit dem ganzen drumherum komme ich irgendwie klar. Ich habe mir meine Gedanken gemacht, bin auch gerade dabei, mir eine DB zu erstellen (auf dem Papier vorerst) und ich weiß auch, wie ich mir das ganze "designe".

Was mir aber sorgen macht, ist einmal die Sicherheit. Wie kann ich sichergehen, dass das Login auch wirklich sicher ist? Gibt es dafür gute Tutorials? Grundlagen? Worauf muss ich achten???

Eine andere Frage entstand mit der Aufgabe, mir selbst eine Art Vokabel-Abfrage und auch eine Art Frage&Antwort-Quiz zu erstellen (Fachbegriffe, etc. auf dem Weg zur Arbeit zu lernen). Mir fällt gerade keine Idee ein, wie ich das umsetzen kann.
Aber da denke ich wohl gerade zu komplex, oder?


Das sind die Punkte, die mich noch etwas verunsichern - alles außer der Login-Frage, werde ich sicherlich lösen können und erhoffe mir deshalb vor allem bei der Frage eine gute Antwort. Ich habe gerade angefangen, mich damit zu beschäftigen, verzeiht also, wenn ich noch nicht jeden einzelne Link gesehen habe. Außerdem denke ich, dass hier eine Empfehlung wertvoller ist, als die Googlesuche...Ich kann nicht erkennen, ob ein Tutorial sicher und qualitativ gut ist...Ihr hingegen schon eher ;)

Ich hoffe - die Anfrage erschlägt euch nicht.

Grüße
-alea-
 

werner

Suchtspielmacher (ehm.)

Registriert
20 Juli 2014
Beiträge
743
Ort
Mannheim
Ja, dazu gibt einiges an Tutorials, da auf PHP-Ebene gar nicht soo viel zu beachten ist. Natürlich sollte der Server, auf dem das System läuft, gesichert sein. Wenn du einen Server im Intranet nimmst, sollte dieser nur intern zu erreichen sein.

MySQL Injections sind eigentlich nur möglich, wenn du prozeduale Methoden von mysqli nimmst, die kannst du dann aber escapen.
Für deine Seite solltest du auch ein Registerierungspanel bauen, denn das Passwort Hashing ist meiner Meinung das komplizierteste daran, und das ist dann viel zu viel Aufwand, jeden User nochmal manuell zu konfigurieren.

Früher hat man nur ein Passwort bspw. via md5 gehasht, und das dann in der DB gespeichert. Inzwischen generiert man für jeden User einen eigenen Salt, der mit dem Passwort zusammen in der DB gespeichert wird.
Das sieht auf den ersten Blick nicht schlecht aus: http://forums.devshed.com/php-faqs-...cure-login-system-using-php-mysql-891201.html
Das noch dazu: http://blackbe.lt/php-secure-sessions/

Du kannst ja erstmal programmieren, soweit du kannst, und dann nochmal konkret nachfragen. Leider weiß ich auch nicht, wie sicher/gut du mit PHP und MySQL(-Design) bist, deswegen kann ich jetzt keine konkreteren Tipps geben.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.560
Fern davon ab, auf Blackbe.lt wird ein Salt selbst aus Zufallzahlen generiert, kann man machen, muß und sollte man aber nicht, wenn man sich nicht 100% sicher ist was von statten geht:

Die Hilfe zu PHP "crypt" sollte da auch weiter helfen, auch wenn es sich komplizierter liest:
http://php.net/manual/en/function.crypt.php

bzw. gleich besser noch das hier verwenden:
http://php.net/manual/en/function.password-hash.php

Auch kann mittels "password_hash" ein Salt automatisch generiert werden, das würde ich an dieser Stelle auch tun, entgegen der Meinung im dem Artikel den werner gespostet hat.
Ich würde jedenfalls keinen Grund sehen die Funktion durch manuellen Code nachzuempfinden da du bei falscher Handhabung Gefahr laufen kannst, das Salting eines Passwortes falsch oder schlecht anzuwenden.
 
Zuletzt bearbeitet:

alea

Neu angemeldet

Registriert
19 März 2016
Beiträge
105
  • Thread Starter Thread Starter
  • #4
Okay, vielen Dank erst einmal für die Info.
Das ist dann "einfacher" als ich erst einmal annahm.
Wenn ich das Direkt per PHP machen kann, dann sollte ich dann eigentlich auch klappen. :)
 

Shodan

runs on biochips

Registriert
14 Juli 2013
Beiträge
661
Ort
Citadel Station
Wie schaffe ich es, mir ein sicheres Login aufzubauen?
In Layern

Als erstes gilt es eine Methode der Authentifikation zu wählen.
Der bekannteste und für dich wahrscheinlich sinnvolle Ansatz ist "Name+Passwort".
Wählst du diese, hast zwei neue Probleme
1) Sichern der Datenübertragung zwischen Client und Server
2) Sichern der Datenspeicherung auf dem Server
Für 1 ist klar TLS einzusetzen. Aber wir arbeiten mit Layern, also reicht uns die Sicherheit auf Transportschicht nicht und wir bauen noch eine Sicherung auf Applikationssschicht ein und lassen den Client die Login-Daten bevor er sie an den Server sendet mit dessen Public Key verschlüsseln.
Zu 2 wurde ja schon ein Keywords genannt: Hash und Salt. Gehen wir da etwas in die Tiefe: Gehasht wird, damit der Server die Passwörter nicht im Klartext speichert, für die Fall, dass uns jemand die DB klaut. Wir wollen serverseitig dazu ein benutzerabhängiges Salt haben, also für jeden Benutzer ein individuelles Hash speichern (siehe Rainbowtable). Passende PHP Funktion wurde ja schon genannt.
Das reicht uns aber natürlich nicht: Der Server hat das Passwort immer noch für kurze Zeit im Klartext, auch wenn es nicht in der DB landet. Und der Server braucht das PW nie im Klartext. Also bauen wir ein anwendungsspezifisches Salt ein: Bevor der Client also das Passwort verschlüsselt und sendet, nutzt er den für die ganze Anwendung gleich bleibende Salt um es zu hashen. Aus Perspektive des Servers ist der vom Client gesendete String das "Passwort". Er muss nie wissen, dass das orginal-Passwort "Sesamstraße" war, mit "OEN6g2BYz3rycZrFmm2S5BrCW3Wf" ist er zufrieden.

Damit ist der Benutzer nun einmal authentifiziert. Wahrscheinlich möchtest du, dass er eingeloggt bleibt, also benötigst du eine Session. Dabei ist wichtig, dass bei einem Wechsel des Sicherheitslevels, z.B. durch Login, die Session-ID regeneriert wird, sonst hast du eine Session Fixation Schwachstelle.
Die Session-ID wird idR. einem Cookie gespeichert, wir haben also zwischenzeitlich unserer Authentifizierungsmethode gewechselt: Statt dass der Benutzter etwas weiß (das Passwort) muss er nun etwas haben (den Cookie). Entsprechend gilt es diesen zu sichern. Dazu sollte das secure-Flag gesetzt sein, damit der Client es ausschließlich über TLS versendet. Auch das http-only Flag sollte gesetzt sein: Auf den Session-Cookie braucht JavaScript keinen Zugriff. Weiterhin ist es sinnvoll, wenn der Cookie als "Session-Cookie" angelegt wird, der Client es also löscht, sobald der Browser geschlossen wird. Serverseitig wird die Session mit einem niedrigen Timeout versehen. Sagen wir 20 Minuten ohne Benutzeraktivität = Logout. Für all das brauchst du nur ein paar php.ini Settings, aber hier geht es darum zu verstehen warum.
Schließlich bieten wir einen Logout Button an. Dieser weißt den Client an den Cookie zu löschen und vernichtet die serverseitige Session. Warum 20 Minuten warten, wenn der User jetzt sagt, dass er jetzt weg ist.

Eine paar kleinere Themen noch, ohne Anspruch auf Vollständigkeit:
Verhindere Clickjacking: Deine Anwendung sollte sich dagegen wehren, zum Beispiel in dem der Client sich nicht in einem Frame ausführen lässt (eine Zeile JavaScript) und der Server den HTTP Header "X-Frame-Options: DENY" mitsendet.

Verhindere CSRF: Kann dein User im Sicherheitsbereich der Anwendung Aktionen durchführen, so sollten diese gegen CSRF geschützt sein. Beispiel für CSRF ist der "Account Löschen"-Link: Klickt ein eingeloggter Benutzer diesen an, dann ist sein Account weg.

Jede Ausgabe ist zu escapen. Schreibst du Daten in die Datenbank, escape sie für die Datenbank. Schreibst du Daten in den HTML-Kontext, escape sie für HTML. Schreibst du Daten in den JavaScript-Kontext, escape sie für JavaScript. Escape Daten jedoch nicht für den HTML-Kontext, wenn du sie in die Datenbank schreibst. Eine der häufigsten Fehler, den ich in der Webentwicklung bisher gesehen habe, ist der Irrglaube man könnte Daten einmal beim Entgegennehmen für alle Kontexte bereinigen. Daten sind unmittelbar vor der Übergabe in einen anderen Kontext für genau diesen Kontext zu escapen.

Benutze prepared statements für die Datenbankinteraktion und gib dem Datenbank-User, den die Anwendung benutzt, nur genau die Rechte, die er braucht. Wenn deine Anwendung keine Tabellen anlegen oder entfernen können muss, verlass dich nicht darauf, dass dein Code das nicht tut. Lass das DBMS das verhindern. Layers ;-)

Validate und Sanitize Input. Definiere, dass der Name keine HTML-Tags enthalten darf und verarbeite eine solche Eingabe gar nicht erst weiter. Kommt durch diese Schicht doch etwas durch, verhindert das Escaping hoffentlich, dass es Wirkung zeigt. Layers!

Leake keine Informationen. Der Benutzer erfährt, dass die eingegebenen Daten nicht korrekt sind. Sag ihm nicht, dass der Benutzer existiert aber das Passwort nicht passt (sieht man auch immer wieder). Sag ihm aber, dass dieser Login JavaScript und Cookies braucht, wenn er diese nicht unterstützt. (Abgrenzung technischer Fehler <-> Falsche Eingabe)

Never roll your own crypto. Ich hatte oben von einer Verschlüsselung auf Applikationsschicht und clientseitigem hashing gesprochen. JavaScript bringt da wenig von Haus aus mit. Schreib so etwas nie selbst, sondern benutze Libraries, die peer reviewed wurden.

Die "Passwort vergessen" Funktion. Die einfachste Variante ist: Klick hier und wir senden dir ein neues Passwort per E-Mail. Damit haben wir eine alternative Authentifizierungsmethode eingebracht: Um sich einzuloggen muss der Benutzer also entweder das Passwort kennen oder Zugriff auf den hinterlegten E-Mail-Account haben. Als Alternative Authentifizierungsmethoden kann man aber auch andere Ideen umsetzen. Zum Beispiel kann man fordern, dass User die ein neues Passwort haben wollen, beim Admin auftauchen und die Unternehmenshymne singen sollen. Jemand der das per Social Engineering hin bekommt darf auch Zugriff auf die Wissensdatenbank haben, vielleicht schriebt er ja was neues rein :-)
 

alea

Neu angemeldet

Registriert
19 März 2016
Beiträge
105
  • Thread Starter Thread Starter
  • #6
Wow, danke. Das muss ich erst einmal verarbeiten. Ich bin da gerade echt etwas "überwältigt" und habe zwar noch etwas Zeit, da ich mich damit zwischen X-Mas und Sylvester beschäftigen wollte, aber ich wollte trotzdem mal fragen, ob du da noch möglicherweise ein gutes Turtorial kennst, damit ich das besser verstehen kann, was Du mir hier niedergeschrieben hast.

Vielen Dank für Deine Mühe.

Grüße
-alea-
 

alea

Neu angemeldet

Registriert
19 März 2016
Beiträge
105
  • Thread Starter Thread Starter
  • #8
Guten Abend,

mein Script entwickelt sich - langsamer als gedacht, aber das ist nun mal immer so. Arbeit und Familie gehen vor.
Ich bin nun soweit, dass mein Daten editierbar sind, etc. Was ich nicht auf die Reihe (noch!) bekomme, ist das Login-Script.

Könnt ihr mir etwas möglicherweise empfehlen, was aktuell ist, dass nur ich mich einloggen kann und das ganze bearbeiten kann?
Gibt es fertige, brauchbare minimal Lösungen, die man später erst umtauschen würde?

Wenn ich noch warten würde, bis ich das Login "sicher" hinbekomme werde, dann werde ich das Script erst im Dezember nutzen können und das ist nicht ganz das, was ich mir da vorgestellt habe... dann lieber parallel :)


Vielen Dank.

- alea -
 

Shodan

runs on biochips

Registriert
14 Juli 2013
Beiträge
661
Ort
Citadel Station
Einen guten Abend auch dir,

Könnt ihr mir etwas möglicherweise empfehlen, was aktuell ist, dass nur ich mich einloggen kann und das ganze bearbeiten kann?
Gibt es fertige, brauchbare minimal Lösungen, die man später erst umtauschen würde?

Nutzt du Apache?


Da viel zu leicht zu übersehen:
It is important to be aware, however, that Basic authentication sends the password from the client to the server unencrypted.

Also TLS nicht vergessen.
 
Zuletzt bearbeitet:

alea

Neu angemeldet

Registriert
19 März 2016
Beiträge
105
  • Thread Starter Thread Starter
  • #10
Okay, das werde ich mir sehr gerne durchlesen :)
Wichtig wäre mir, dass ich z.B. über mein Tablet, mein Smartphone oder den (Firmen)Laptop.
Wenn mit htaccess sozusagen das Script und die DB-Einträge geschützt sind, ist es wirklich ein cooler Tipp! Danke!


Grüße
Christoph
 

Shodan

runs on biochips

Registriert
14 Juli 2013
Beiträge
661
Ort
Citadel Station
Apache schützt natürlich nur die durch Apache ausgelieferten Dateien und nicht die Datenbank.

Diese sollte aber sowieso nicht von außen erreichbar sein, sondern nur auf Anfragen von localhost antworten.
Willst du mit einem SQL Client direkt auf der Datenbank arbeiten, dann benutze dafür einen SSH Tunnel.
Prinzipiell gilt: ein (sql-)server, der nicht von außen erreichbar ist, kann auch nicht von außen angegriffen werden.
Wenn du häufiger wie "sehr selten" direkt an die DB willst, dann richte dir einen Benutzer ohne Shell ein, mit dem du den SSH Tunnel aufbaust. Warum mehr haben, wie benötigt.
Erst wenn du mit Replication arbeitest wird es sinnvoll einem anderen Host als localhost Zugriff auf die DB zu geben. Replication geht zwar auch über einen SSH Tunnel, aber das ist irgendwo Quatsch. Lieber TLS mit gegenseitiger Authentifizierung.
Btw das alles ist natürlich ein Layer und soll auf keinen Fall dazu ermuntern dann schlechte Passwörter für die SQL Benutzer zu vergeben, oder eine Anwendung, die keine Tabellen löschen sollte einen Benutzer nutzen zu lassen, der das darf.


Fun fact: Du kannst auch Apache konfigurieren, dass nur Verbindungen von localhost auf deine Application zugreifen dürfen und dann deine http Verbindung durch SSH tunneln :D
 

alea

Neu angemeldet

Registriert
19 März 2016
Beiträge
105
  • Thread Starter Thread Starter
  • #12
Hi,

ich mal wieder...

...und, nun ja...es dauert alles länger und es ist komplexer, als ich es annahm. Leider komme ich dank der Kinder nie dazu, mich in ruhe hinzusetzen.
Ist aber auch nicht so schlimm. Also tendiere ich doch zu der Lösung, die ich wohl gleich hätte nehmen sollen.

Ich werde wohl mir eine Wordpress-Installation aufsetzen und mich nur um den Content kümmern.
Es gibt Add-Ons, welche den Inhalt auch von außen schützen und somit denke ich, dass ich damit gut leben kann.

Ich habe beschlossen dafür ein neues Thema aufzumachen, da dies doch etwas anderes sein wird.
Ich wollte mich an dieser Stelle nur noch einmal für Eure Tipps/Hilfe bedanken, auch wenn ich leider da nicht so weit bin, wie ich es mir vorgestellt habe...

Bye
- alea -
 
Oben