Is Acegi een J2EE security framework?

Ik ben voor OWASP druk bezig met het OWASP Java Project waar ik probeer om de OWASP Top 10 2007 te herschrijven naar Java. Natuurlijk heb ik nu een paar bemerkingen die ik wil delen.

Spring maakt gebruik van Acegi en dus noemt Acegi nu Spring Security. Veel informatie is er niet te vinden, maar Acegi is eigenlijk een authorisatie-filter die toegang geeft tot URLs of niet. Acegi kijkt dus of je een geauthenticeerde sessie hebt en of je de toelating hebt om een bepaalde URL te openen. Hmmmm.... De ervaring leert mij dat ontwikkelaars en beheerders niet de gewoonte hebben om 2 verschillende applicaties en URLs te gebruiken voor hetzelfde doel. Dit betekent dat meestal een gebruiker en een beheerder inloggen op dezelfde applicatie en site. Dus dan wordt het moeilijk om granulaire authorisatie regels te definiëren. Hiermee moet men dus van in het begin rekening houden.

Maar wat ik mis in een dergelijk "security framework" is een rudimentaire beveiliging tegen typische aanvallen.
Voor mij moet een security framework (J2EE, PHP of .NET of ...) tot volgende zaken bevatten:
- authenticatie, liefst met sterke authenticatie
- authorisatie, op URL en objectniveau en eenvoudig te configureren en niet programmeren
- input validatie geïntegreerd met een deftige audit logging
- output encoding
- audit trail
- positieve security
- encapsulation van identiteit en propagation van identiteit

Ik ben nog altijd op zoek naar een J2EE applicatie die 3 van bovenstaande punten bevat!

Commentaar is meer dan welkom

De laatste maanden toch een paar interessante projecten uitgevoerd (idd, geen vakantie dit jaar), waarbij een paar zaken waarvan ik dacht dat die quasi niet meer mogelijk zijn toch nog alive-and-kicking zijn.

Ten eerste: standaard gebruikersnamen en wachtwoorden. Ongelooflijk hoe eenvoudig je hiermee binnengeraakt op routers, FTP servers, ... en dan nog met admin rechten

Ten tweede: te veel vertrouwen in de gebruiker/bezoeker van de applicatie. Een gebruiker die te veel kan en mag is een slechte zaak vanuit een security standpunt. Dus waarom zijn de applicaties dan ook zo niet geschreven? Omdat het niet op papier staat.... Dan komen we terug op abuse cases en dergelijke

Ten derde: geen documentatie

Ten vierde: geen reactie! Niemand die het heeft opgemerkt dat er een probleem is en een hacker (ik dus :)) toegang had

Dus er is nog veel werk aan de winkel!

OWASP WebGoat en WebScarab

Vorig week mocht ik op vraag van Seba een uur een sessie geven over WebGoat en WebScarab op de OWASP security dag. Er was een goede opkomst en een mix van programmeurs en security mensen.
Wat me vooral is bijgebleven is dat je toch wel heel technisch moet zijn om zelf uit te zoeken hoe WebGoat en WebScarab werken. Ik denk dat veel te maken heeft met het gebrek aan documentatie en de niet-intuïtieve gebruikersinterface van de twee tools. Aangezien ik er al 5 jaar mee speel is het voor mij natuurlijk wel heel gemakkelijk om die te gebruiken.
Het goede nieuws is dat als mensen wisten hoe alles te configureren is, ze toch wel goed kunnen volgen.
Het nog betere nieuws is dat de OWASP WebGoat Solution Guide af is. Dus dit wil zeggen dat er binnenkort een knop "Solution" te vinden is in elke WebGoat les zodat mensen die willen bijleren over web security beter hun weg vinden.