Achtung Hacker! – Maßnahmen zum Schutz der Datenbank
Vorwort: Es gibt Hacker und es gibt Cracker, beide haben ihre Ziele und Arbeitsweisen, da den meisten aber der Begriff des Hackers vertraut ist, verwende ich ihn hier. Wenn ich es aber richtig verstanden habe sind Hacker die Guten und Cracker die Bösen, wer näheres weiß kann sich dazu in den Kommentaren äußern.
Es kann mitunter ganz schön kritisch werden wenn eine Datenbank gehackt wird und alle Daten dem Hacker zur Verfügung stehen, siehe zum Beispiel hier: Hackers Steal Russian Dating Site Database
Der Sinn zum Schutz der eigenen Datenbank ist also klar, zumal es rechtliche Folgen haben kann wenn die Daten der User nicht ausreichend geschützt sind, doch wie schützt man seine Datenbank effektiv?
Keine Mainstream-Datenbank
Hacker haben es natürlich immer leichter wenn ein System verwendet wird, welches viele Menschen im Einsatz haben, das ist bei dem Betriebssystem Windows so, aber auch bei der Datenbank MySql. Da viele Menschen diese Datenbank verwenden, ist die Chance groß das man eine Sicherheitslücke findet. < ironisches selbstlob > Ich selbst habe es mal geschafft (es war allerdings mehr durch Zufall als durch aktives “hacken”) die Logindaten der Datenbank einer Affiliate-Seite herauszufinden (Nachrichtenseite zu Affiliate, nicht Affiliate-Anbieter an sich), natürlich habe ich den Websitebetreiber darauf aufmerksam gemacht und er konnte diese Lücke beheben< /ironisches selbstlob >
Saubere Formulare – Buffer-Overflow verhindern
Ich bin mir nicht ganz sicher ob dies bei Datenbanken auch so einfach funktioniert, aber ich erkläre das Prinzip dennoch: Wenn dem Hacker ein Formularfeld angeboten wird, in welches er Daten einträgt, dann kann er dies nutzen eine sehr lange Eingabe zu tätigen. Zum Beispiel ein Feld für den Benutzernamen, welches in der Regel natürlich nie mehr als 30 Zeichen verwendet, kann so mit mehreren hundert Zeichen gefüllt werden. Wird auf programmier-technischer Ebene nicht diese Masse an Zeichen abgefangen und die Eingabe versucht in die Datenbank zu füllen, das Datenbank-Feld aber selbst nur 30 Zeichen fassen kann, dann gibt es einen Buffer-Overflow. Ein Fehler der dazu führt, oder führen kann, daß dem Hacker der Zugriff auf die Datenbank gestattet ist (man entschuldige meine Erklärung, ich selbst habe vom Hacken keine Ahnung).
Daher ist es wichtig Formulare abzusichern, siehe diesen Artikel: Programmierung eines Registrierungsformular – was muss man beachten
Massenschlacht – die BruteForce-Methode
Ein gutes und “sicheres” Passwort zu wählen hat natürlich auch immer seine Vorteile, es gibt genügend Software-Produkte die einen Angriff auf den Loginbereich einer Datenbank starten und mit mehreren tausen (hunderttausend?) “Loginversuchen” versuchen, den Loginnamen und das Passwort der Datenbank zu knacken. Auch hier zeigt sich wieder das Beispiel von weit verbreiteter Software, zum Beispiel der WordPress-Software. Der Standard-Loginname ist “admin” und ich wette das viele WordPress-User diesen Loginnamen so belassen haben, das kann fatal sein, jenachdem wie “attraktiv” ein Hacker das Ziel findet.
Werde selbst zum Hacker
Natürlich soll man nun nicht anfangen wahllos Angriffe zu starten, allerdings kann es hilfreich zu sein die Methoden und die Software der Hacker zu kennen. Wer also weiß wie Angriffe gestartet werden, der hat es einfacher sich vor diesen zu schützen. Ich denke ein wirklich guter Datenbank-Entwickler hat Kenntnisse in diesen Bereichen, oder ist dies eher Aufgabe des Administrators?
Kennt ihr euch besser in diesem Bereich aus? Ich würde mich über einen Kommentar freuen!
Verwandte Artikel
- User IP ind Datenbank speichern
- RSS Feeds als Ziel von Hackern
- Datenbank Backup via Cronjob und WordPress
- PEAR und Smarty – sauberer, sicherer Code und enorme Geschwindigkeit
- Tschuldigung darf man mal testen
4 Kommentare
Tut mir leid, die Kommentarfunktion für diesen Beitrag ist geschlossen.
Meine bisherigen Erfolge waren durch schlampige Programmierung, durch XSS und SQL-Injections und durch unverschlüsseltes Speichern wichtiger Daten welche über die Domain aufrufbar waren.
- schlampige Programmierung: heruasfinden der Systempfade, dadurch dann vermeintlich geheimer Seiten und Bereiche -> oben genannter letzter Punkt
- XSS (Cross Site Scripting): Ebenfalls schlecht programmiert und kein Abfangen von absichtlichen Fehleingaben und HTML, JS Code. Dadurch kann man leicht und schnell Cookies vom “Opfer” auslesen und das Passwort cracken.
- SQL-Injections: Wie auch bei den anderen Bereichen: schlecht programmiert. Absolut jede mögliche vom User zu übergebende Variable gut prüfen und alles was nicht benötigt wird gar nicht erst irgendwie verarbeiten oder vom User manipulieren lassen (dazu zählen auch z.B. GET Variablen)
Na ja, es gibt sehr viele nette Möglichkeiten und das ganze ist ein riesen Thema welches sich nicht in einem kleinen Artikeln widerspiegeln lässt.
Aber die Hauptsache: Jede noch so kleine Usereingabe überprüfen und das schlimmste von den Usern vermuten.
*g das hört sich hart an, aber ich denke so muss man daran gehen, wenn man eine sichere DB haben will. Werd mich mal zu XSS schlau machen, kenne das noch garnicht, vielen dank für die Hinweise!!
Hallo Christian,
danke für den Beitrag :)
Hab noch eine Frage:
– Zitat: –
Auch hier zeigt sich wieder das Beispiel von weit verbreiteter Software, zum Beispiel der WordPress-Software. Der Standard-Loginname ist “admin†und ich wette das viele WordPress-User diesen Loginnamen so belassen haben,
————
Wie ändert man denn den Standard-Login-Namen von WordPress? Bei mir ist dieser Benutzername nicht bearbeitbar, d.h. es kann gar kein anderer als ‘admin’ für den Hauptadministrator eingestellt werden.
Falls Du da anderes weißt, wäre ein Hinweis nett :)
Hallo Franziska,
das ist recht einfach über die Datenbank möglich, im Adminbereich läßt sich das leider nicht einstellen.
- verbinde dich mit der Datenbank auf der du WordPress installiert hast
- gehe in die Tabelle “wp_users”
- ändere deinen Loginnamen von “admin” in einen beliebigen anderen
Da es sich hier aber um Datenbankeingriffe handelt muss ich dich warnen: mach das nur wenn du weißt wie das geht, könnte sonst böse für deine Datenbank enden. Man muss sich auch immer fragen wie attraktiv der eigene Blog für Hacker ist, wenn man eine sehr große Website hat, kann man sich schonmal darüber Gedanken machen, in der Regel ist eine Änderung des Loginnamen aber nicht wirklich nötig.