"Ihr" habt gesagt, dass "eure" Datenbanken sicher sind.
Es würde mich interessieren, wie ihr das macht.
Ich stehe mit dem Thema immer noch auf Kriegsfuß und zweifle, ob meine Abwehrstrategien erfolgreich sind.
"Ihr" habt gesagt, dass "eure" Datenbanken sicher sind.
Es würde mich interessieren, wie ihr das macht.
Ich stehe mit dem Thema immer noch auf Kriegsfuß und zweifle, ob meine Abwehrstrategien erfolgreich sind.
Hallo Jana!
Da du das Thema im PHP Forum gepostet hast,
denke ich du sprichst mit "Datenbanken" auf MySQL an,
und das ganz speziell im Zusammenhang mit PHP.
Falls dies nicht der Fall ist, würde ich das Thema ins Datenbank Forum verschieben, korrigiere mich also falls ich mich irre.
Generell ist es immer wichtig die neuste Version laufen zu haben (bei MySQL ist ja gerade wieder ein Sicherheitsloch geflickt worden), und die Benutzer vernünftig mit Berechtigungen auszustatten, sowie die Datenbank bei nicht unnötig nach aussen zu öffnen, also den Zugriff nur über localhost zu gestatten.
Um deine Abwehrstrategien zu beurteilen wüsste ich erst mal gerne, um welche es sich handelt!
Gaert
PS: Ich hab nicht behauptet, dass meine Datenbanken sicher sind!
Hallo,
Unsereins kann sich nur eine MYSQL Datenbank und PHP leisten.
Auf die MYSQL Version habe ich keinen Einfluß, die bestimmt der Provider und auf meinem eigenen Linux-Server habe ich das Problem mit irgendwelchen Hacker sowieso nicht. Das man die Verbindung zur Datenbank nur mit lokalhost herstellt ist verständlicherweise üblich.
Ich bin schon gefragt worden, ob ich nicht Datenbanken programmieren kann, in denen Kundendaten (Name, Telefon ...) gespeichert sind.
Die Leute wollten dann, daß ich die Passwörter mit Cookies auf dem Rechner der Kunden speichere, damit diese ja keine Arbeit haben. Außerdem sollte jeder Kunde Zugriff auf seine sämtlichen Daten haben. Das war mir zu gefährlich. Ich fing an mich mit der Sicherheit von Datenbanken zu beschäftigen.
1. Zunächst speichere ich keine Passwörter, Namen und kritische Daten außerhalb der Datenbank. (Cookies etc.)
2. Ich wähle bei personenbezogenen (kritischen) Daten keine Tabellen- oder Spaltennamen die auf den Inhalt schließen lassen, wie "Passwort".
3. Ich mache aus einem String einen String settype($pic, "string"); etc. damit mir keine falschen Datentypen untergejubelt werden.
4. Die Datenbank wird erst im letzen Moment aufgemacht.
5. Mit $pic= str_replace("\'", "''", $pic); ersetze ich die Werte durch sich selbst, sodaß durch einen Absturz des Rechners kein Schaden angerichtet werden kann, weil die Abfangzeit zu kurz wird.
6. Durch $pic=strip_tags($pic); entgehe ich Steuerzeichen, die wie trojanische Pferde wirken können und mit deren Hilfe Passwörter ausgelesen werden. Falls das nicht geht, verwende ich $pic=eregi_replace("[\<]+","*", $pic); um einzelne Steuerzeichen zu eleiminieren.
7. Daten gebe ich nicht direkt in die Datenbank ein, sondern etwas umständlich:
$sqlab = sprintf("insert stauden(idstauden) values('%s');", addslashes $idstauden));
Das ist etwas sicherer.
8. Kritische Daten werden vor der Übertragung verschlüsselt.
Für weitere Anregungen wäre ich echt dankbar.
Hallo!
OK...
Nachdem du deine Ansätze jetzt ein wenig besser erläutert hast, möchte ich deine Ansätze aus meiner sicht gerne mal etwas näher bewerten...
Zu 1:
Korrekt...
Zu 2:
Ich verstehe nicht, warum du deine Spaltennamen nicht nach dem benennst, was sie sind. Ein gutes Datenbankdesign ist eines, das auf kryptische Tabellen und Feldnamen verzichtet damit die Struktur leicht lesbar ist. Falls irgendjemand einmal Zugriff auf deine Datenbank erhalten sollte kann mit SHOW TABLE STATUS eh deinen kompletten Tabellenbaum abrufen und sich die entsprechenden Daten rauspicken... Mir ist der Sinn von Punkt 1 also nichr recht klar!
Zu 3:
Ich könnte verstehen wenn du z.B. settype dazu verwendest um sicherzustellen, dass du einen Integer Wert hat -> settype($pic, "integer") ...
settype($pic, "string") ist meiner Meinung nach vollkommen unnötig, da PHP ja bekanntermaßen eh jede Variable als String verwenden kann, auch Zahlen...
Zu 4:
Manche Leute würden behaupten, dass es vollkommen egal ist an welcher stelle des Skripts eine Verbindung zur Datenbank aufgebaut wird... Hier würde ich gerne eine genauere Begründung hören. Ich öffne meine Datenbankverbindung bereits immer am Anfang meiner Skripte.
Zu 5:
Ich schreibe es nochmal in Code Tags, damit es lesbarer wird...
Bitte erkläre das nochmal!Code:str_replace("'", "''", $pic);
Sorry, aber was das soll verstehe ich überhaupt nicht (auch diese Rechnerabsturz / Abfang Geschichte)!
Zu 6.
Hättest du ein Beispiel für ein solches "Trojanisches Pferd"?
Mir ist nicht klar, was HTML Tags in einem SQL Query für Schäden anrichten sollten!?
Was z.B. Schaden anrichten könnte wäre z.B. wenn jemand für einen Benutzernamen folgendes wählt (bitte nicht ausbprobieren *g*):
Für diese Zwecke gibt es allerdings den Befehl mysql_escape_string()Code:MrUser"; DROP DATABASE mysql
Zusätzlich sollten vielleicht noch % und _ Zeichen Escaped werden!
Zu 7.
Ich wüsste nicht was daran sicherer sein sollte, ausser dass es schlecht lesbar ist!
Zu 8.
Ich denke du meinst damit Kritische Daten werden in der Datenbank verschlüsselt abgelegt.
Denn wenn eine connection über localhost läuft ist es IMHO nicht möglich Daten beim Transport in die Datenbank abzufangen!
Generell Gilt: Passwörter IMMER md5 verschlüsselt ablegen... So ist es nichtmal dem Administrator möglich Passwörter der Kunden zu lesen!
__________
Ein paar kleine Anregungen hab ich in Punkt 6 schon gemacht.
Wäre schön, wenn wir weiter über die Punkte diskutieren können... vielleicht schalten sich auch noch ein paar andere Leute mit Meinungen ein.
Gaert
2.Siehe: http://php3.de/manual/de/security.database.php
Der Angreifer könnte mit der SET Klausel herumspielen. In diesem Fall muss eine Schemainformation vorhanden sein, um die Abfrage erfolgreich manipulieren zu können. Diese kann durch Untersuchen der Variablennamen im Formular, oder simpel mittels brute force gesammelt werden. Es gibt nicht so viele Namenskonventionen für Felder, welche Passwörter oder Benutzernamen speichern.
Man braucht ja nicht auf aussagekräfige Namen wie "Passwort" verzichten, sondern man schaltet einfach eine Zahl oder einen Buchstaben vor.(z.B. "5Passwort")
3. Stimmt "string" war ein schlechtes Beispiel.
4. Keine Begründung. Reine Gefühlssache wegen Absturzgeschichten;
denn da passieren die seltsamsten Dinge. Hab ich selber schon gesehen.
5. Die Idee hab ich von amerikanischen Datenbank-Gurus. Sie sagen nur:
$pic= str_replace...... is one.
Auf mehrmaliges Nachfragen erhielt ich etwas mitleidig die Antwort, daß es zum Abfangen von Einbrüchen bei Datenbankabstürzen dient.
Mehr weiß ich leider nicht.
6. In allen Foren wird verhindert, daß javascript-code und php-code ungefiltert in die Datenbank gelangen kann. Deswegen schmeiß ich ihn auch raus.
Stimmt "drop database" hab ich vergessen.
7.http://php3.de/manual/de/security.database.php
Beispiel 5-5
8. Genau das wollte ich sagen.
1. Nochmals Jap
2. Verstehe ich nicht, find ich auch unnötig. Wenn jemand soweit ist, das er mit der SET funktion rumspielt kriegt er auch die Felder raus. Wie gesagt - nen einfach SHOW STATUS reicht. (wenn man soweit ist, deine Queries ändern zu können, ist es ein leichtes ein SHOW ... Befehl anzuhängen.
3. Verstehe schon worauf du hinauswillst, aber ne Typprüffung mit is_numeric o.ä. würd denk ich reichen - da nen Type Cast meist mehr Rechenzeit verwendet.
4. Was für Sachen denn? Auf nem stabilen Server sollte die Datenbank nicht einfach so abstürzen. Auch wenn man dort richtig Power drauf gibt (also so 200 - 300 Abfragen pro Seite)...
5. Wenn die DB abgestürzt ist, macht ein DB basierendes Skript logischerweise Überhaupt nichts mehr. Da ist es dann egal ob du die Rechenzeit zum selber kopieren verschwendet hast oder nicht.
6. Es wird in der Datenbank schon gespeichert, es wird bloß net ausgegeben. Deutlicher. Der strip_tags kram wird vor der Ausgabe gemacht. Da ein Administrator den HTML Code ja auch mal aktiviert haben möchte. (Es ist ja eine Option die auch aktiviert werden kann)
7. Auch hier wird implizit nen Type Cast durchgeführt. Prüft man die Variable vorher (oder erstellt man diese sogar selber) ist das völlig unnötig.
8. Bei Passwörtern sollte das so sein - bei Namen etc brauch man einen Algorhitmus der umkehrbar ist, aber zumindest ist kenn keinen der schnell genug ist (auch wenn ich mir schon ne RC4 Verschlüsselung programmiert hab, aber die ist elendig langsam)
Seine Rätselhaftigkeit wird nur durch seine Macht übertroffen!
@Mehlvogel:
Zu 3:
Wenn man einen String bekommt, man aber eine Zahl haben will, dann ist ein typecast sicherlich der bessere weg... falls der Wert nämlich eh schon eine Zahl ist wird auch kein Typecasting durchgeführt, folglich wird auch keine Rechenzeit verschwendet.
Ansonsten kann ich nur zustimmen.
@Jana:
Zu 5:
Kann es sein dass deine Amerikanischen Freunde Oracle Freaks sind?
Ich kann mich da dunkel an eine ähnliche aussage von einem meiner Profs erinnern (also ' durch '' (zwei einfache Hochkommas) ersetzen). Ich weiß allerdings nicht mehr aus welchem Kontext heraus das erwähnt wurde. Ich bezweifle auch, dass dies bei MySQL irgendwelche auswirkungen auf das Handling von abstürzen haben sollte (die eigentlich gar nicht vorkommen sollten).
Berechtigungen
Zitieren
Lesezeichen