dinsdag 28 juli 2009

OWASP

Nee, dit gaat niet over een in cirkeltjes rondzoemende wesp uit Silicon Valley, maar over the Open Web Application Security Project. Met het mission statement van http://www.owasp.org/ schiet je al wat meer op bij het begrijpen van deze obscure afkorting. Daar lezen we in een Wiki-achtige layout namelijk:

“[OWASP] is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks.”

Het meest bekend is OWASP van de “Top 10”, een lijst met de tien belangrijkste kwetsbaarheden in (o.a. Java Enterprise Edition) web-applicaties. Deze lijst is behoorlijk pragmatisch tot stand gekomen, wat een goed gevoel geeft. Het gaat niet om zuiver theoretische chasing-a-once-in-a-million-cases, maar om heel concrete zaken die (te) regelmatig fout gaan bij de beveiliging (en dus ontwerp en ontwikkeling) van een webapplicatie. OWASP maakt elke paar jaar een nieuwe versie van de Top 10, uiteraard steeds pas wanneer de omstandigheden voldoende veranderd zijn. De huidige versie is die van 2007, en ten opzichte van 2004 (de vorige versie) zijn er wat items van de lijst verdwenen (o.a. buffer overflows), en wat andere toegevoegd.

Aandacht voor zaken op de OWASP Top 10 tijdens het hele ontwerp- en ontwikkelproces zorgt voor betere, veiligere, en, uiteindelijk, goedkopere webapplicaties, in elk geval qua total-cost-of-ownership. Soms is een OWASP-check min of meer verplicht, bijvoorbeeld om een PCI-DSS “audit” door te komen. De kans op grootschalig misbruik van je applicatie is dan wellicht niet zo groot (tenzij je Amazon, Ebay, Rabobank of PayPal heet natuurlijk), maar *als* het mis gaat zijn de gevolgen ook voor kleinere sites niet makkelijk te overzien.

De Top 10, versie 2007 (tromgeroffel! Uiteraard schaamteloos onder Creative Commons geript van de Wiki van het nogal trage OWASP.org zelf):
A1 - Cross Site Scripting (XSS)
XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

A2 - Injection Flaws
Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

A3 - Malicious File Execution
Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

A4 - Insecure Direct Object Reference
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

A5 - Cross Site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.

A6 - Information Leakage and Improper Error Handling
Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.

A7 - Broken Authentication and Session Management
Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.

A8 - Insecure Cryptographic Storage
Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

A9 - Insecure Communications
Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

A10 - Failure to Restrict URL Access
Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

Genoeg aandachtspunten dus!

dinsdag 7 juli 2009

Google haalt software uit beta



Het is ongelooflijk, maar Gmail is eindelijk niet meer in beta. Naast Gmail, die vijf jaar in beta heeft gestaan, zijn ook Google Docs (2006), Calendar (2007) en GTalk (2005) uit beta gehaald.

vrijdag 3 juli 2009

Mobiele variant van de Monitor Applicatie

De afgelopen maanden heeft Roel geploeterd om voor ISAAC een applicatie te maken die de monitor tool van LaSer kan weergeven op een mobiel device, waaronder een blackberry. Dit moest hij voor elkaar krijgen zonder enige voorkennis over Java, JBoss, Eclipse en browsermogelijkheden van mobiele apparaten... een hele opgave dus.

Maar, afgelopen week is hij geslaagd en heeft hij de eerste versie van de 'mini monitor' klaar. Het is een hele basic HTML versie die precies doet wat de gebruiker wil: in één oogopslag zien of er iets mis is, en zo ja wat er mis is en waardoor het komt. Zo kan de gebruiker direct actie ondernemen als hij even zijn blackberry checkt.

Tijdens zijn afstuderen kwamen er wel enkele interessante zaken naar voren, bijvoorbeeld de beperktheid van de browserfunctionaliteit van veel mobiele devices. Ze hebben allemaal vaak andere standaarden en ondersteunen niet allemaal hetzelfde (IE6-7-8, firefox, opera... all over again). Er is dus helaas geen eenvoudige manier om een website mobiel-proof te maken. Daar zullen we nog even mee moeten wachten totdat de mobiele devices de 'standaard browsers' gaan draaien of meer gaan ondersteunen.

Ook bleek dat java niet zo eenvoudig is als het lijkt, in elk geval voor mensen die meer ervaring hebben met script-talen. Dat heeft Roel met de harde hand ondervonden, maar hij is er uiteindelijk toch wel enigszins uitgekomen (met een beetje hulp). En hij was erg enthousiast over de Expression Language, en daarmee scoor je natuurlijk ook punten bij mij ;)

Website optimalisatie

foto door: Dave & Karin
Moderne websites zitten tjokvol afbeeldingen en "rich" onderdelen (javascript libraries als JQuery of Dojo) en hoewel bijna iedereen tegenwoordig ultrasnelle internet verbindingen heeft is het aan te raden om je website te optimaliseren. Door dit te doen laadt de pagina sneller en is de user-experience dus beter. Een goed begin om iets over website optimalisatie te leren is door het boek "High Performance Websites" te lezen. Hierin staat in detail uitgelegd waar je op moet letten bij het maken van een website. Hieronder vind je een overzicht van de grootste snelheidswinsten die je kunt behalen.

- Het aantal HTTP requests beperken
- Javascript en CSS verkleinen
- De site gzippen
- CSS sprites gebruiken

Hiernaast zijn er nog veel meer mogelijkheden om snelheid te winnen, zoals het plaatsen van css files bovenaan in de webpagina en javascripts juist onderin, het vermijden van CSS expressies en redirects voorkomen. Maar we beperken ons nu tot de bovenstaande technieken omdat deze de grootste winsten boeken.
Het aantal requests beperken kan een behoorlijke winst opleveren. Stel dat je site zes javascript files inlaad. Hiervoor zijn dus ook zes requests nodig. Deze requests zitten op elkaar te wachten en dit kan dus voor een behoorlijke vertraging zorgen. Het aantal request kun je beperken door de zes javascript files te bundelen tot een enkele file. Dit zorgt ervoor dat de scripts niet op elkaar hoeven te wachten en met 1 request ingeladen kunnen worden. Naast de javascript bestanden kun je ook kijken naar de stylesheets die worden ingeladen en afbeeldingen. Afbeeldingen kun je ook bundelen tot een enkele afbeelding met behulp van CSS sprites. Een CSS sprite is eigenlijk een grote afbeelding met alle afbeeldingen op de site naast elkaar. Door in je CSS aan te geven waar je afbeelding begint, kun je de enkele afbeelding voor alle afbeeldingen op de site hergebruiken en hoeft er dus maar 1 afbeelding ingeladen te worden.

Naast het verminderen van het aantal requests die gedaan worden kan ook het verminderen van de hoeveelheid data een snelheidswinst opleveren. De hoeveelheid data die je verzend kun je verminderen door, bijvoorbeeld, javascript en css bestanden te "minify-en". Je haalt dan alle overtollige tekens uit de bestanden (zoals enters, spaties, opmerkingen) waardoor de files stukken kleiner worden. Daarnaast kun je de hoeveelheid data verminderen door de site te g-zippen. gzip is een protocol die door de meeste browsers wordt ondersteund en de hoeveelheid data met 70 tot 80 procent kleiner kan maken.