Danke für den ausführlichen Vortrag zu maven. Allerdings bleibt für mich noch ein Punkt offen, für den ich bislang keine vernünftige Lösung gefunden habe.

Bei komplexen Produkten besteht der Build immer aus einer Mischung aus Artefakten, die Code liefern und einer produkt- bzw. kundenspezifischen Konfiguration.

Besonders deutlich wird das z.B. bei J2EE-Komponenten, die in mehreren Produkten eingesetzt werden. Hier unterscheiden sich die Komponenten oft nur in der Konfiguration, die aus XML-Deskriptoren bezogen werden.

Wie kann ich mit Maven diese Aspekte vernünftig behandeln? Der manuelle Weg wäre ja, das Archiv der Komponente auszupacken, den Deskriptor auf das Produkt anzupassen und danach wieder einzupacken und sie als produktspezifische Variante zu verwenden.

von Anfang an: Wenn jemand eine SQL-Injection findet, sind mal die kompletten Daten der DB komprimittiert. Wird kein saltedpasswords verwendet, also nur md5(), so kommt der Angreifer zu 100% ins Backend (egal welches Passwort verwendet wurde). Hier liegt die Problematik, alles andere ist nur noch simpel.

Natürlich kann sich der Angreifer dann eine Extension installieren (sofern die Rechte stimmen), HTML-Files uploaden (auch damit kann man schon genügend anstellen), denn es geht ja nicht in 1. Linie darum viel Schaden anzurichten sondern darum dass man lange unentdeckt bleibt. Der Angreifer könnte auch via TS anderen Content ausliefern. Daher bleib ich bei der Meinung, ein Admin kann alles machen ;)

@ Saltedpasswords: Nun das salt ist *pro* Installation unterschiedlich, man müsste also pro Installation eine rainbow-Table haben da ja das gleiche Passwort pro Installation auch anders aussieht, zahlt sihc nicht aus.

Jedem Entwickler, Integrator, … ist der Security Guide ans Herz gelegt: http://typo3.org/documentation/document-library/extension-manuals/doc_guide_security/current/ und hier gibts auch ein Kapitel ” Detect, Analyze and Repair a Hacked Site”