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
Monday, September 17, 2007
Monday, September 10, 2007
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!
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.
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.
Friday, June 8, 2007
MSDN presentatie over Ajax & security
Deze week had men mij gevraagd van Microsoft België om een presentatie te geven op een MSDN (Microsoft Developer Network) over ASP.NET AJAX en de security problemen.
Dit is natuurlijk een interessante uitdaging. Er valt heel veel over te vertellen en er kan ook veel fout gaan.
Maar het is natuurlijk niet evident om concepten als Javascript Hijacking en Cross-site-request-forgery uit te leggen als de mensen nog problemen hebben met zoiets als cross-site-scripting.
Als ik een presentatie geef dan heb ik altijd de gewoonte om het publiek een paar vragen te stellen. Dus als ik vroeg "wie heeft al gehoord van cross-site-scripting" dan stak de volledige cinema-zaal zijn hand op, maar als ik dan vroeg "wie begrijpt het concept" dan zag ik met moeite een paar vingers. En het is begrijpelijk! Cross-site-scripting is moeilijk te vertalen in iets eenvoudigs en zeker niet als onderdeel van een presentatie van 2 uur. Maar het concept is nodig om de andere kwetsbaarheden te kunnen uitleggen.
Voor mensen die geïnteresseerd zijn om meer te weten, ik geef een hands-on cursus "Improving your web applications security" eind juni. Meer informatie en inschrijven via deze PDF: http://www.zionsecurity.com/uploads/media/Improving_your_web_applications_security.pdf
Dit is natuurlijk een interessante uitdaging. Er valt heel veel over te vertellen en er kan ook veel fout gaan.
Maar het is natuurlijk niet evident om concepten als Javascript Hijacking en Cross-site-request-forgery uit te leggen als de mensen nog problemen hebben met zoiets als cross-site-scripting.
Als ik een presentatie geef dan heb ik altijd de gewoonte om het publiek een paar vragen te stellen. Dus als ik vroeg "wie heeft al gehoord van cross-site-scripting" dan stak de volledige cinema-zaal zijn hand op, maar als ik dan vroeg "wie begrijpt het concept" dan zag ik met moeite een paar vingers. En het is begrijpelijk! Cross-site-scripting is moeilijk te vertalen in iets eenvoudigs en zeker niet als onderdeel van een presentatie van 2 uur. Maar het concept is nodig om de andere kwetsbaarheden te kunnen uitleggen.
Voor mensen die geïnteresseerd zijn om meer te weten, ik geef een hands-on cursus "Improving your web applications security" eind juni. Meer informatie en inschrijven via deze PDF: http://www.zionsecurity.com/uploads/media/Improving_your_web_applications_security.pdf
Friday, May 11, 2007
Digitale radio en bandbreedte
Vorige week een rare situatie meegemaakt. Mijn collega kreeg bij een klant een rapport van de ISP, waaruit bleek dat sinds een paar weken sommige dagen men een download van 3 tot 4 GB had, zelfs in het weekend. Natuurlijk zijn we als security mensen direct wantrouwig en er waren een paar mogelijke oorzaken:
- PC die een peer-to-peer programma had staan om zaken zoals MP3s en DVDs af te halen
- PC die geïnfecteerd was met een virus
- Iemand die op het netwerk geconnecteerd was (bijv. via wireless) die geen toelating had
- ...
Hoe pak je dit nu aan? Gelukkig hadden we de firewall juist veranderd naar Check Point UTM-1. Voordeel van dergelijke firewall is de logging. En die hadden we dus voldoende.
Een uurtje logs bekijken gaf al heel snel de oplossing. Er waren geen rare poorten die werden gebruikt, buiten DNS, SMTP en HTTP verkeer. Maar op HTTP was er wel veel connecties van een bepaalde PC. En de URL was altijd dezelfde. Dus snel de URL opzoeken en dit bleek www.digitaleradio.be te zijn. Aha!
Dit is een streaming audio site, waar je dus gewoon naar digitale radio kunt luisteren. Maar wel aan een snelheid van 96 kilobyte per seconde. Dus dit betekent 96*60 = 5760 kilobyte per minuut of 5760*60= 345600 kilobyte per uur. Dus per uur een 345600/1024= 337,5 MB download. Dus een werkdag van 8 uur levert al snel een 3 tot 4 GB op. Voor 1 geconnecteerde PC!!!
En waarom dit in het weekend voorviel was snel uitgeklaard. Er werd in het weekend soms doorgewerkt.
Problemen met netwerk adaptors op XP
Begin deze week een heel rare situatie meegemaakt. Ik had een programma, LinkScanner geïnstalleerd dat URLs screent op exploits. Blijkbaar had dit programma de volledige windows netwerk socket aangepast. Omdat ik in de firewall logs rare HTTP traffiek zag naar een ADSL adres in Israel (!), besloot ik om het programma te verwijderen om te kijken of de traffiek stopte. Aangezien ik altijd met 5 zaken tegelijk bezig ben, had ik tijdens de uninstall ook een VPN connectie opgestart met Check Point SecureClient. Plots stopte de SecureClient met een bizarre foutmelding: SecureClient failed to start. Please re-install.
Een reboot loste het probleem niet op. Ik kreeg een pop-up dat een service van SecureClient niet kon opstarten.
Dan maar de laatste nieuwe versie installeren.
Reboot.
Zelfde errors.
Geen VPN.
Paniek.
En dan kreeg ik een inval. Ik had vroeger al eens een gelijkaardig probleem geconstateerd bij een PC van een klant. De LSPs (iets te maken met registry keys en netwerk adaptors/sockets) waren corrupt. Ik heb dan een gratis tool gedownload, LSP-Fix en dit laten draaien. Hij vond direct een paar zaken die te maken hadden met de uninstall van LinkScanner. De registry keys verwezen nog naar de DLL die ondertussen is verwijderd door de uninstall. Gelukkig kan LSP-Fix dit verhelpen. En inderdaad, een reboot en de VPN client werkt zoals het moet. LSP-Fix kan je hier vinden: http://www.cexx.org/lspfix.htm
Een reboot loste het probleem niet op. Ik kreeg een pop-up dat een service van SecureClient niet kon opstarten.
Dan maar de laatste nieuwe versie installeren.
Reboot.
Zelfde errors.
Geen VPN.
Paniek.
En dan kreeg ik een inval. Ik had vroeger al eens een gelijkaardig probleem geconstateerd bij een PC van een klant. De LSPs (iets te maken met registry keys en netwerk adaptors/sockets) waren corrupt. Ik heb dan een gratis tool gedownload, LSP-Fix en dit laten draaien. Hij vond direct een paar zaken die te maken hadden met de uninstall van LinkScanner. De registry keys verwezen nog naar de DLL die ondertussen is verwijderd door de uninstall. Gelukkig kan LSP-Fix dit verhelpen. En inderdaad, een reboot en de VPN client werkt zoals het moet. LSP-Fix kan je hier vinden: http://www.cexx.org/lspfix.htm
Monday, April 23, 2007
Cross-site-scripting in Blogger?
De lezers zullen zich nu wel afvragen waarom ze een Javascript pop-up zien met daarin de boodschap XSS. Blijkbaar is de cross-site-scripting attack die ik aanhaalde als voorbeeld in de blog over web application firewalls uitvoerbaar. U leest het goed. Als blogger kan ik dus Javascript uitvoeren die vanuit een 'trusted' omgeving wordt uitgevoerd. In vaktermen noemen we dit een persistent XSS want die wordt opgeslaan in de blog zelf.
Ik heb direct contact genomen met Google, maar blijkbaar moet ik heel veel moeite doen om ze te overtuigen dat dit effectief een security issue is. Ongelooflijk!
Dus er komt zeker een vervolg...
Ik heb direct contact genomen met Google, maar blijkbaar moet ik heel veel moeite doen om ze te overtuigen dat dit effectief een security issue is. Ongelooflijk!
Dus er komt zeker een vervolg...
Tuesday, April 17, 2007
Waarom een web application firewall?
Ik was eerst van plan om een artikel te schrijven over de beveiliging van open-source content management systems maar ik zal eerst een kader scheppen :-)
Vandaar dit bericht!
Voor de mensen die dit lezen en die zeggen: web application firewall?! Een mooi Nederlands woord bestaat er niet buiten webstek vuurmuur...
Een web application firewall laat toe om inkomend en uitgaand HTTP verkeer te controleren op inhoud. Waarom? Om aanvallen te detecteren en af te blokken. Aanvallen? Inderdaad: alle web sites worden dagelijks aangevallen door virussen, automatische scanners en hackers. Die zoeken kwetsbaarheden in de applicatie om te misbruiken en verder toegang te krijgen tot de achterliggende databank, informatie of netwerk. Meer informatie op www.owasp.org.
Ik heb al honderden programmeurs verbaasd doen kijken met volgende vraag: "Kan je in jouw logfiles zien dat jouw applicatie wordt aangevallen, nu en hoe?" Ik heb nog nooit, ik herhaal nooit, een positief antwoord gekregen. Applicaties zijn niet gemaakt om aanvallen te detecteren, af te blokken en een alarm te geven. Waarom? Dit is geen functionele requirement, dus niet geïmplementeerd. Maar dit moet wel zo zijn!
Vandaar dat een web application firewall (waf) nodig is. En er is zelfs een open-source versie: ModSecurity (www.modsecurity.org). ModSecurity is een plugin voor Apache die inkomend en uitgaand HTTP verkeer controleert met regels. Die regels definiëren wat er niet mag aanwezig zijn in parameters bijvoorbeeld of 1 0R 1=1
Het mooie aan een waf is dat dit geen verandering aan de applicatie vereist. Je plaats dit op een netwerkniveau voor de bestaande web applicaties en met behulp van mod_proxy kan je al die sites publishen.
ModSecurity is compileerbaar op heel veel platformen. Ik heb dit overlaatst gecompileerd op een SuSe voor PowerPC bovenop IBM iSeries en dit werkt perfect! Zelfs heel performant!
En dit zou niet open-source zijn als er geen "Core Rules" bestaan die veel aanvallen detecteren, maar niet afblokken. Er is zelf een Console, niet open-source wel gratis voor 3 sensors die je op de kan gebruiken om op de hoogte te blijven van transacties en aanvallen.
Als jullie bijkomende vragen hebben, laat maar een comment na en ik zal trachten een antwoord te geven. Indien nodig, contacteer ik wel de maker van ModSecurity, Ivan Ristic.
Vandaar dit bericht!
Voor de mensen die dit lezen en die zeggen: web application firewall?! Een mooi Nederlands woord bestaat er niet buiten webstek vuurmuur...
Een web application firewall laat toe om inkomend en uitgaand HTTP verkeer te controleren op inhoud. Waarom? Om aanvallen te detecteren en af te blokken. Aanvallen? Inderdaad: alle web sites worden dagelijks aangevallen door virussen, automatische scanners en hackers. Die zoeken kwetsbaarheden in de applicatie om te misbruiken en verder toegang te krijgen tot de achterliggende databank, informatie of netwerk. Meer informatie op www.owasp.org.
Ik heb al honderden programmeurs verbaasd doen kijken met volgende vraag: "Kan je in jouw logfiles zien dat jouw applicatie wordt aangevallen, nu en hoe?" Ik heb nog nooit, ik herhaal nooit, een positief antwoord gekregen. Applicaties zijn niet gemaakt om aanvallen te detecteren, af te blokken en een alarm te geven. Waarom? Dit is geen functionele requirement, dus niet geïmplementeerd. Maar dit moet wel zo zijn!
Vandaar dat een web application firewall (waf) nodig is. En er is zelfs een open-source versie: ModSecurity (www.modsecurity.org). ModSecurity is een plugin voor Apache die inkomend en uitgaand HTTP verkeer controleert met regels. Die regels definiëren wat er niet mag aanwezig zijn in parameters bijvoorbeeld of 1 0R 1=1
Het mooie aan een waf is dat dit geen verandering aan de applicatie vereist. Je plaats dit op een netwerkniveau voor de bestaande web applicaties en met behulp van mod_proxy kan je al die sites publishen.
ModSecurity is compileerbaar op heel veel platformen. Ik heb dit overlaatst gecompileerd op een SuSe voor PowerPC bovenop IBM iSeries en dit werkt perfect! Zelfs heel performant!
En dit zou niet open-source zijn als er geen "Core Rules" bestaan die veel aanvallen detecteren, maar niet afblokken. Er is zelf een Console, niet open-source wel gratis voor 3 sensors die je op de kan gebruiken om op de hoogte te blijven van transacties en aanvallen.
Als jullie bijkomende vragen hebben, laat maar een comment na en ik zal trachten een antwoord te geven. Indien nodig, contacteer ik wel de maker van ModSecurity, Ivan Ristic.
Tuesday, March 27, 2007
Hoe de elektronische identiteitskaart gebruiken in IIS 6.0
Na een paar dagen zoeken en niets vinden, uiteindelijk toch de oplossing gevonden!
De beste en enige manier om HTTPS te configureren voor de elektronische identiteitskaart in een paar eenvoudige stappen:
De beste en enige manier om HTTPS te configureren voor de elektronische identiteitskaart in een paar eenvoudige stappen:
- Installeer een server certificaat in IIS
- Download het belgiumrca.cer certificaat van http://certs.eid.belgium.be en importeer dit in de Local Machine - Trusted Root Certificate Authorities
- Maak een Certificate Trust List in IIS met het Belgium Root CA certificaat
Meer is het niet.
Wat je zeker niet mag doen: het Citizen CA certificaat importeren! Blijkbaar zijn deze niet uniek. Als je een e-ID hebt uitgereikt door een andere Citizen CA dan kan je niet inloggen.
De error die je dan krijgt is "The certificiate is ill-formed or is not trusted by the web server".
Een Nederlandstalige blog over security
Ik heb besloten om een blog op te starten in het Nederlands waarbij ik mijn visie, ervaring en verdere opmerkingen kan bundelen die over security gaan. Waarom in het Nederlands? Wel, ik vind dat er te weinig informatie op Internet staat die zich specifiek richt op Nederlandstalige collega's in de IT wereld.
Ik hoop dus dat ik hiermee bepaalde vragen of problemen kan helpen oplossen en ondertussen jullie op de hoogte kan houden ivm de laatste nieuwe trends, ontwikkelingen en aanvallen.
Ik hoop dus dat ik hiermee bepaalde vragen of problemen kan helpen oplossen en ondertussen jullie op de hoogte kan houden ivm de laatste nieuwe trends, ontwikkelingen en aanvallen.
Subscribe to:
Posts (Atom)