Daher frage ich noch mal ganz direkt: Kann nicht eine einzige buggy Extension das gesamte System kompromittieren? Wenn ich also z.B. eine Extension für einen Kunden entwickeln sollte und dort vielleicht die an die DB übergebenen Parameter nicht überprüfe, dann wäre ggf. eine SQL-Insertion möglich und wenn sich diese auf die tabelle be_users bezieht, dann ist das gesamte System ausgehebelt worden.
Scheint mir ein prinzipielles problem zu sein, so dass man auf jeden Fall jede Extension, egal ob im repository oder selbst geschrieben gründlich checken sollte...
Da ist schon was dran. Aber so eine SQL-Injection muß man auch erstmal hinkriegen, dazu gehört, wie gesagt, schon eine Menge kriminelle Energie. Im Grunde muß man jede Extension auf solche Löcher hin querlesen. Und die Coder dafür sensibilisieren, damit schon beim coden sowas vermieden wird. Aber es bringt nix den Teufel an die Wand zu malen, und Panik zu verbreiten.
T.
Tetramatrix schriebDa ist schon was dran. Aber so eine SQL-Injection muß man auch erstmal hinkriegen, dazu gehört, wie gesagt, schon eine Menge kriminelle Energie. Im Grunde muß man jede Extension auf solche Löcher hin querlesen. Und die Coder dafür sensibilisieren, damit schon beim coden sowas vermieden wird.
Das war ziemlich genau, was ich meinte. Allerdings würde ich den Aufwand für eine SQL-Injection nicht zu hoch hängen, das kann ggf. sehr einfach gehen. Zum Glück ist jedoch bei PHP mittlerweile die Option GPC_MAGIC_QUOTES standardmässig aktiviert, so dass ungeprüfte GET- und POST-Parameter nicht mehr so schnell zum Problem werden...
Tetramatrix schriebAber es bringt nix den Teufel an die Wand zu malen, und Panik zu verbreiten.
Don't panic
... steht schon auf einem der berühmtesten Bücher überhaupt #giggle#
CU
maxhb
Tetramatrix schriebDa ist schon was dran. Aber so eine SQL-Injection muß man auch erstmal hinkriegen, dazu gehört, wie gesagt, schon eine Menge kriminelle Energie.
na aber jetzt mal ehrlich.......
alle die was versierter sind und wissen wo sie ansetzen müssen, kriegens hin........und dafür braucht man nicht mal kriminelle energie, sondern einfach nur blanke neugierde...
cu
thorsten
...Jungs !
Jetzt mal ehrlich !!
Lasst die Kirche mal im Dorf.....
Über Sicherheit innerhalb einer Applikation zu reden deren Sourcen offen liegen ist -- nehmt es mir nicht übel -- der grösste Schwachsinn überhaupt !!
An dieser Stelle zu behaupten T3 sei sicher ist so ziemlich der grö?te Blödsinn den ich in letzter Zeit gelesen habe...
Was ist noch alles sicher ??
Postnuke?
Also....man kann es nem Script Kiddie zwar schwer machen....aaaaaaber nem Hacker ringt das ein mehr oder weniger müdes lächeln ab.
Security Team hin oder her !!
cu
Dosul
#giggle# 8-) #giggle#
jungens hört auf den mann, der weiss wovon er redet 😉
ausserdem is das ja wohl mehr als die wahrheit!
cu
thorsten
@dosul: Jaaaa, sicher, und Du bist der Kaiser von China. 😉.
Tetramatrix schrieb@dosul: Jaaaa, sicher, und Du bist der Kaiser von China. 😉.
Nein.....aber sag mir doch mal wo DU nen T3 laufen
hast ?
edit:
LOL....
Wer ist hier der Kaiser von China ?
Chi Hoang ??
Sach mal......
http://www.chihoang.de
Is datt deine ?
...und kein T3 ????
Schade eigentlich...*ggg*
SCNR
Dosul
Vielleicht sollten wir diesen Thread einfach verbrennen, langsam wirds alberner als der kultige Freitagkurzvorfeierabendflamewar auf heise.de und das ist genau, wo ich jetzt reinschauen werde 😉
CU
maxhb
maxhb schriebVielleicht sollten wir diesen Thread einfach verbrennen, langsam wirds alberner als der kultige Freitagkurzvorfeierabendflamewar auf heise.de und das ist genau, wo ich jetzt reinschauen werde 😉
CU
maxhb
Jepp....agreed #giggle#
Aber der meinung war ich schon von Anfang an 😉
cu
Dosul
maxhb schriebVielleicht sollten wir diesen Thread einfach verbrennen, langsam wirds alberner als der kultige Freitagkurzvorfeierabendflamewar auf heise.de
ja und hätten wir hier moderatoren #giggle# wäre der thread schon lange dicht :o
#8078
cu
thorsten
maxhb schriebVielleicht sollten wir diesen Thread einfach verbrennen, langsam wirds alberner als ...
Schade - und ich dachte schon Typo3 wäre ein ernst zu nehmendes CMS! 😢
Ciao - Tom
tomybyte schriebmaxhb schriebVielleicht sollten wir diesen Thread einfach verbrennen, langsam wirds alberner als ...
Schade - und ich dachte schon Typo3 wäre ein ernst zu nehmendes CMS! 😢
Ciao - Tom
oh mann...
du hast wohl hier nicht gut gelesen, oder????
es geht sich nicht nur um typo3, sondern um jedes system!!!!!!!!!!!!!!
wurde wohl schon etwas weiter oben gesagt....
lass dir gesagt sein, jedes system ist angreifbar!
typo3 ist ernst zu nehmen....................
nur halt ist im internet eben nichts sicher!
cu
thorsten
tomybyte schriebSchade - und ich dachte schon Typo3 wäre ein ernst zu nehmendes CMS! 😢
Kopf hoch Tom!
Die Sicherheit von Typo3 ist vermutlich nicht 100%ig, jedoch höchst wahrscheinlich deutlich besser als die der meisten anderen auf PHP basierten Applikationen. Und das schöne ist, dass die Sicherheitslücken mit jedem Tag weniger werden - immerhin arbeitet auf der einen Seite ein ganzes team an der Abschottung von PHP und auf der anderen Seite gibt's da Kollegen wie Tetramatrix, die zusätzlich noch die Problemstellen im PHP-Code lokalisieren und ausmerzen.
Davon abgesehen sollte man nicht glauben, dass es im Internet nur so vor bösen Buben wimmelt, die darauf aus sind, die Website eines Hobby-Philatelisten zu knacken - obwohl sowas passieren könnte(! siehe Kommentar zu Script-Kiddies weiter oben).
Realistischreweise wird das jedoch nur äusserst selten passieren und dann ist die furchtbare Konsequenz ... Ja was ist denn eigentlich die Konsequenz? Man muss sein sorgfältig erstelltes Systembackup wieder einspielen und weiter gehts....
CU
maxhb
Man könnte doch die Sicherheitsrelevanten Daten von der DB abkapseln und z.B. in eine XML DB reinschreiben, die ihrerseits verschlüsselt ist.
Z.B.: typo -> kleine c App, dass die XML Dateien entschlüsselt und die benötigten Daten zurückschickt bzw. verschlüsselt und in der Datei speichert.
qp schriebMan könnte doch die Sicherheitsrelevanten Daten von der DB abkapseln und z.B. in eine XML DB reinschreiben, die ihrerseits verschlüsselt ist.
Z.B.: typo -> kleine c App, dass die XML Dateien entschlüsselt und die benötigten Daten zurückschickt bzw. verschlüsselt und in der Datei speichert.
Dann musst Du aber wieder die C-Datei schützen, denn vermutlich ist darin ja der Schlüsel zum entschlüsseln der XML-DB enthalten...
Man kann sich drehen und wenden wie man will, Sicherheitslücken können immer bestehen. Allerdings ist die Sicherheit eines Apache mit PHP und MySQL nicht zu unterschätzen. Die Systeme sind schon sehr erprobt und bei einer Vielzahl von gehackten Sites lag es dann eh wieder am Betreiber, der mal wieder nicht die neuesten Patches eingespielt hat oder schlicht miserable Passworte verwendet.
Die Idee mit der Kapselung der Datenbank finde ich allerdings nicht schlecht, vielleicht wäre es ein guter Ansatz, die Schnittstelle zur Datenbank so schmal wie möglich zu gestalten. Folgendes könnte ich mir vorstellen:
1. Es existiert nur ein lokaler Benutzer für die MySQL-DB, dieser verwendet natürlich ein wirklich gutes Passwort...
2. zugriff auf die DB erfolgt immer über eine zentrale Typo3-Funktion
3. In dieser Funktion wird folgendes überprüft:
a) Ist eine bestimmte Konstante gesetzt und enthält einen geheimen, für jede Site unterschiedlichen Wert (Installationsparameter)
b) Lautet der Referrer bzw. die IP-Adresse der zugreifenden Seite localhost
CU
maxhb
Nun, der Aufwand steigt enorm, wenn man so einen "db proxy" nimmt. Aber ist natürlich nicht umbedingt notwendig.
Die Idee ist einfach (künftigen) Schwachstellen in PHP vorzubeugen und Injections auf die abekoppelte user DB zu vermeiden.
maxhb schrieb Die Systeme sind schon sehr erprobt und bei einer Vielzahl von gehackten Sites lag es dann eh wieder am Betreiber, der mal wieder nicht die neuesten Patches eingespielt hat oder schlicht miserable Passworte verwendet.
That´s what it is. Bevor sich ein Hacker die Mühe macht T3 zu hacken wird er erstmal nen aktuellen Nessus-Scan laufen lassen. Womit sich bei mind. 40-50% aller Server das Thema T3 hacken erledigt hat...