| 

.NET C# Java Javascript Exception

Security, bitte um Eure Empfehlung

Dies ist das Archiv des ehemaligen Forums zum Thema Groovy, Grails, Griffon und Bean Scripting Framework, welches unter groovy-forum.de existierte. Die neue Adresse des Groovy-Forums ist: http://codekicker.de/fragen/themen/groovy.


Security, bitte um Eure Empfehlung

rawi - 18.06.2009 10:39
Hallo

über Security habe ich in The_Definitive_Guide_to_Grails_Second_Edition (über Grails Filters und JSecurity) sowie in Grails_in_Action (über Spring Security) gelesen.

Nach dem ersten Eindruck habe ich mehr von Grails-Filters und SpringSecurity verstanden. Jsecurity schien mir komplizierter.

Ich würde gerne ein Projekt anfangen, wo Sicherheit wichtig ist, und neige gleichzeitig zu Grails-Filters, da ich dort am meisten verstanden habe, _warum_ etwas passiert oder nicht.

1. Wäre die Lösung mit Grails-Filters... OK für einen Anfänger?
(Ich habe verstanden, im Hintergrund benutzen auch die anderen Security-Frameworks die selben Filter...)

2. Falls JA, verliere ich irgend etwas Wichtiges (z.B. im Vergleich zu SpringSecurity)?
Versperre ich mir damit Zukunftsmöglichkeiten?

3. Oder würdet Ihr mir zu etwas ganz Anderem raten?
(z.B. ganz die Finger davon lassen und das Leben genießen? :-)

Schönen Dank im Voraus und Grüße von
rawi


Re: Security, bitte um Eure Empfehlung

krey - 19.06.2009 08:26
Zitat
x
Letztlich kommt es (neben RAM) immer drauf an, wie sensibel die Daten sind und welchen Vorteil es hat, die Daten in der Session zu speichern. Wenn der Benutzer daher nicht immer wieder das gleiche bei einer Suche auswählen muss, ist das ein Vorteil und ok. Wenn nur die Programmierer zu faul ist, die Daten wieder von wo anders zu holen, dann ist das kein so guter Grund.
Ob die Daten im RAM, LDAP, Dateisystem oder auf Aruba liegen interessiert keinen. Wer eine Session hijacked, kommt eh an alle Daten an die der Benutzer mit der Session an sich kommen würde.
*Wie im Thread wohl auch schon richtig erkannt wurde.


Re: Security, bitte um Eure Empfehlung

rawi - 19.06.2009 11:43
Hallo Freunde!

Ich bedanke mich herzlichst für die vielen Beiträgen und Hilfestellungen. Es tut mir leid, falls das Ganze für Manche von Euch nervig wird; mir hilft es eine ganze Menge, da ich keinen habe, mit dem ich mich überhaupt über solche Sachen austauschen kann.

Die Meinungen neigen sich langsam in Richtung eines zusätzlichen Security-Frameworks...
Wobei ich diesmal mit Akzent auf "zusätzlichen" philosophieren will:

So wie von mir bisher aus Büchern verstanden, bietet schon Grails mit den Filtern ein Framework dazu. Ich habe grade am Beispiel JSecurity noch mal gelesen: nach installation und Konfiguration von JSecurity, steht es. dass JSecurity grundsätzlich alles durchlassen würde, es sei denn ich benutze die selben Grails-Filters um SELBST den Zugang einzuschränken oder zu kontrollieren...
Nach der ganzen Quellerei mit einer BlackBox an Modulen (lernen), die mir grundsätzlich ein Grüst für User, Roles und Permissions geben, sowie die Möglichkeit sie abzufragen, also danach... fängt die selbe Frickelei mit den Filtern, die ich sowieso gehabt hätte auch bei den eigenen User und Permissions und eigener Funktion zur Abfrage.

User, Role, isLogged() etc. geben grundsätzlich in allen Szenarien einen Boolean zurück.
Wenn ich selbst mit dem Boolenan immer noch einen Fehler bei der definition der (Grails)Filtern mache, ist so, als hätte ich keine JSecurity.
Ist das so?
Dann würden sich diese Zusatzpackete erst lohnen, wenn ich mal gegen seltenere authentifizierungsMaschinerien anlaufe, LDAP, OpenID o.Ä?
Die Filter muss ich weiterhin selber mischen. Ob ich nach einer Permission abfrage oder JSecurity (mit einer noch zu lernenden Syntax) ist egal. Zurück kommt ein Boolenan.

Gefährlicher als _durch_Boolean_Filter_Authorisierung_durchzubrechen_ ist dann schon CrossSiteScripting und SessionKlauen. Ihr habt mehrfach darauf hingedeutet. 2 Aussagen sind mir hauptsächlich im Kopf geblieben:
Diese Sicherheit muss "die Anwendung" gewärleisten oder "das Framework".

OK, das ist schon ernster. Wenn ich durch die besondere Ausgabe (encodeAsHTML()) dafür sorgen muss, ist OK zu wissen. Dann ist es nur eine Sache des Fleißes, alle scaffolded-en GSPs zu nehmen und entsprechend zu ändern.
Wenn es eine Sache des Frameworkes ist, sorgen die Security-Frameworks alleine IRGENDWIE darum?
Oder machen sie nur die Authentifizierung und Authorisierung!?

Ich habe gerade (in einer paralellen Diskussion) Schwierigkeiten mit .encodeAsHTML(), das mir bei einem Test nicht Funktioniert hat.
Die Enttäuschung ist um so größer, da ich in einem Buch gelesen habe, dass Grails selbst dafür sorgt, soweit man die eigenen Grails-Tags verwendet. Nun, meine Ergebnisse sind inkonsistent, weiß nicht warum. Idenfalls bei der Ausgabe wurde ein Script-chen trotz .encodeAsHTML() ausgeführt.

Ich habe ein Gefühl von "deja lu" :-). Gibt's dafür nicht ein Grails-Schalter im Sinne: "Escape alles was rausgeht"?
Es wäre viel vernünftiger, als von mir zu erwarten, jeden Wert als escapeAsHTML() zu schreiben. DAS sollte ein Framework machen!

Wenn diese Dinger nicht richtig Funktionieren, dann kann eine Grails-Application eigentlich nicht gesichert werden? Oder?

Danke, schöne Grüße
rawi


Stelle deine Groovy-Frage jetzt!


Diese Seite zeigt den Thread "Security, bitte um Eure Empfehlung" der ehemaligen Webseite groovy-forum.de, welche durch einen Serverunfall zerstört wurde. codekicker.de hat viele Konversationen über die beliebte Programmiersprache Groovy und zugehörige Frameworks wie das Grails-Framework retten können.

Hast Du eine Frage zum Thema Groovy, Grails oder allgemein Java? Viele ehemalige groovy-forum.de Mitglieder beantworten dir auf codekicker.de deine Frage! Stelle jetzt eine Frage!

Viele weitere Diskussionen zu Grails und Groovy befinden sich auf der Threadübersicht des alten groovy-forum.de.