Topic: This message was too old and has been purged (Read 747 times)
This message was too old and has been purged
Na ja, ich hätte jetzt gesagt, dass man halt ein Interface UserDataProvider (oder so) schreibt, und dann eine Klasse für die Oracle-DB, welches dieses Interface implementiert. Dann könnte man ein weiteres Interface für MySQL usw schreiben. Ich seh jetzt gerade nicht, wie man damit grosse Sicherheitslücken aufreissen würde. Aber wenn jemand die Java-Klassen überschreiben kann, dann nützt Dir die Sicherheit in der DB auch nix mehr. Dann er ggf. gleich den Code recompilieren und die DB-Abfrage einfach rausnehmen und durch return true; (o.ä.) ersetzen.
This message was too old and has been purged
Bitte abstrahier doch von der Oracle-DB. Ich benutze sowas z.B. gar nicht, könnte so ne Funktion aber evlt. auch gut brauchen.
This message was too old and has been purged
Ich möchte nicht, dass die Daten aus der Userdatenbank geholt werden können, wenn nicht vorher CUSTOM_AUTH erfolgreich durchgeführt wurde. Habt ihr Ideen, wie die beste Vorgehensweise wäre?
Mach doch eine Stored Proc aus deiner Function, die im Erfolgsfall den kompletten Datensatz zurückgibt. Damit hast du auch einen Performancegewinn. Macht keinen Sinn, erst die Authentifizierung zu prüfen und dann erst die Daten abzufragen, wenn sowieso beides direkt hintereinander gemacht wird. Dann lieber alles in einem Schritt.
Du musst die Rechte des Webusers so setzen, dass er keine SELECTs auf die Tabelle machen kann, sondern nur EXEC
Ausserdem: wie merkt man sich, dass CUSTOM_AUTH korrekt ausgeführt wurde?
Dazu bräuchtest du eine weitere Tabelle, wo du bei jedem Auth die Session mit Timestamp und/oder Expiration-Time speicherst. Wenn du noch weitere Tabellen schützen willst, machst du dafür auch jeweils eine Stored Proc, wo du die Session ID übergeben musst, damit die Gültigkeit geprüft werden kann.
In dieser konkreten Frage geht es darum, [...] wie ich das so umsetzen kann, dass es bombensicher ist 
Praktisch gar nicht. Statt zu glauben, dass man irgendwas bombensicher machen kann, sollte man sich imho von dem Gedanken verabschieden und sich stärker auf Intrusion Detection konzentrieren.
Was natürlich nicht heißt, dass man nicht versuchen sollte, alles vorher schon möglichst sicher zu machen
Aber ab einem gewissen Grad der Sicherheit, ist der Hirnschmalz dann wohl in Intrusion Detection besser aufgehoben.
Am besten sind zwei Schemata:
a) ein Webuser namens DIRTY
b) ein Securityuser namens SICHERHEIT
Das Schema SICHERHEIT enthält die USER-Tabelle mitsamt den Securityprocedures.
DIRTY erhält nur die Executerechte auf diese Securityprocedures,
jedoch keinerlei Objektprivilegien(wie SELECT, UPDATE) auf Tabellen in SICHERHEIT
Zwei Hinweise noch:
1) Schreib "select 1 into l_count from USERS where USERNAME = p_username;" oder so
count(*) ist laufzeitmäßig zu teuer
2) Passwörter sollten immer verschlüsselt in der DB gespeichert sein, nie im Klartext
3) Für Fortgeschrittene - es gibt die Möglichkeit der Verschlüsselung von DB-Inhalten
(siehe http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/tde/index.html)
Hier kann man dann schön mit Wallets jonglieren.
a) ein Webuser namens DIRTY
b) ein Securityuser namens SICHERHEIT
Das Schema SICHERHEIT enthält die USER-Tabelle mitsamt den Securityprocedures.
DIRTY erhält nur die Executerechte auf diese Securityprocedures,
jedoch keinerlei Objektprivilegien(wie SELECT, UPDATE) auf Tabellen in SICHERHEIT
Zwei Hinweise noch:
1) Schreib "select 1 into l_count from USERS where USERNAME = p_username;" oder so
count(*) ist laufzeitmäßig zu teuer
2) Passwörter sollten immer verschlüsselt in der DB gespeichert sein, nie im Klartext
3) Für Fortgeschrittene - es gibt die Möglichkeit der Verschlüsselung von DB-Inhalten
(siehe http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/tde/index.html)
Hier kann man dann schön mit Wallets jonglieren.
This message was too old and has been purged
Jump to: