Een waakhond voor webapplicaties

De kans om gehackt te worden als bedrijf lijkt toe te nemen. Het aantal veiligheidsincidenten en lekken dat gemeld wordt in het nieuws neemt zeker toe. Wat doe je als jouw webapplicaties gevoelig zijn voor aanvallen en er geen tijd en geld is om alle programmacode aan te passen?

De geschiedenis van webapplicaties

De eerste zinvolle internet webapplicaties zijn vanaf 1995 ontwikkeld toen Netscape javascript in de eerste browsers ging ondersteunen. De ontwikkeling versnelde vanaf 1999 toen Java Servlets geïntroduceerd werd. Vanaf die tijd is er veel code (Java, PHP, C#..) ontwikkeld voor webapplicaties. Bedrijven met voldoende animo, budget en zichtbaarheid zullen wellicht in staat zijn geweest om de steeds grotere lijst van veiligheidsmaatregelen te volgen. Daarbij zijn grote delen van de code aangepast omdat de hedendaagse veiligheidseisen veel omvattender zijn dan men ooit vooraf had kunnen bedenken.

OWASP TOP 10

Een aardig voorbeeld van de hedendaagse veiligheidseisen voor webapplicaties is de OWASP TOP 10. Dit is een lijst met veiligheidsmaatregelen waar ten minste aan gedacht moet worden bij het ontwikkelen van webapplicaties. Er wordt bijvoorbeeld gewaarschuwd om altijd alle input te controleren. Dit omdat anders de webapplicatie gevoelig kan zijn voor een cross side scripting aanval. OWASP gaat verder en adviseert om ook aan andere zaken te denken zoals het systeem waarop je webapplicatie draait (security misconfiguration). Een voorbeeld van security misconfiguration is dat je een applicatie server installeert en het default account niet aanpast waardoor vrijwel de hele wereld kan inloggen op jouw applicatie server omdat dit account in de installation guide met username en password genoemd is en vindbaar is voor iedereen.

Noodzakelijk kwaad

In de meeste gevallen zullen wat oudere webapplicaties of zelfs hele platformen geen rekening gehouden hebben met de moderne veiligheidsmaatregelen uit de OWASP TOP 10. Ook wijzigt deze lijst om de zoveel jaar om op die manier alle wijze lessen uit de praktijk te benutten. Helaas komt het voor dat men deze wijze lessen negeert. Bedrijven zijn soms druk genoeg met het functioneel onderhouden van hun webapplicaties. Uiteraard lopen bedrijven hier niet mee te koop zolang er niemand naar vraagt. Enkele bedrijven zijn zich mogelijk niet eens bewust van alle risico's en merken pas wat dat er wat aan de hand is als het mis gaat.

Kosten en baten

Bedrijven kijken meestal naar het directe voordeel wat er te behalen is bij het ontwikkelen van webapplicaties. Dit heeft als gevolg dat er alleen maar tijd en geld is om nieuwe functies toe te voegen, bijvoorbeeld om nieuwe social networking (google, facebook, twitter) functies in te bouwen. De kosten voor security onderhoud kunnen overigens snel oplopen. Een gemiddelde webapplicatie bestaat al snel uit 100.000 tot 500.000 regels code waar dan 30% van moet worden aangepakt om de inputvalidatie regels in te bouwen. En niet alleen het aanpassen van die code kost tijd en geld, ook zal de webapplicatie na het aanpassen een volledige regressietest moeten doorlopen om te valideren of alles nog goed werkt. Het realiseren van de veiligheidsmaatregelen levert een bedrijf functioneel ook niets direct op. Immers het gedrag van de applicatie wordt niet aangepast en er komen geen nieuwe functies bij. Het is dan ook begrijpelijk dat bedrijven dit probleem eigen liever links laten liggen en er ook een beetje op gokken dat een hacker hun IP range en TCP/IP poorten overslaat. Ze willen eigenlijk er wel wat aan doen maar dan liefst tegen minimale kosten en tijd.

Applicatie Waakhond

Gelukkig heeft de industrie dit probleem ook herkend. Een van de oplossingen die men ontwikkeld heeft is de Web Application Firewall of kortweg WAF. De WAF wordt tussen de bestaande firewall en de applicatie server gezet en ziet daarmee al het ingaande en uitgaande HTTP(S) verkeer. Door middel van patroonherkenning is de WAF in staat om bepaalde aanvallen te herkennen. Een voorbeeld is de herkenning van SQL statements in de URL als parameter, of als POST data (ook wel bekend als SQL injection). De WAF kan dan de aanval automatisch tegenhouden of kan alleen een melding maken van de poging via een alert. Er is altijd een kans dat de WAF een patroon herkent wat juist geen aanval is. Bijvoorbeeld zodra SELECT en INSERT als woorden in de input toegestaan zijn. In dat geval heeft men het over een false positive. Uitgebreidere WAF apparatuur heeft meestal de mogelijkheid om te leren welke patronen zijn toegestaan binnen de webapplicatie. Zo kan een WAF alle vormen van URLS bijhouden die bij de webapplicatie horen bij "normaal" gebruik. Zodra daar dan een uitzondering op komt kan de WAF ingrijpen. In deze leerfase is het ook mogelijk om uitzonderingen toe te staan zoals het woord INSERT toelaten bij een specifieke URL omdat bekend is dat die constructie dan geen aanval is voor de betreffende webapplicatie.

Web Application Firewalls

Web Application Firewalls zijn tegenwoordig beschikbaar in vele smaken en variaties. We tonen hier een aantal uit het open source (gratis) en professionele (betaalde) domein. Dit zijn ze uit het open source domein, geheel gratis maar soms wel beperkt qua functies en handigheid in het beheer.

• Apache - mod security
• AQTRONIX WebKnight
• ESAPI WAF
• WebCastellum
• Binarysec
• OpenWAF

En dit zijn wat mogelijke leveranciers van betaalde oplossing. Meestal wordt de oplossing als appliance (software + hardware) verkocht. Veelal zit het voordeel in het (soms dure) onderhoud contract waarbij automatisch alle nieuwe patronen en regels worden toegevoegd. Daarnaast garandeert de leverancier vaak OWASP TOP 10 compliance.

• Barracuda
• Citrix Netscaler
• Cisco
• F5
• FortiNet - FortiWeb
• Radware
• Rapid7
• Zeus Application Firewall

Tot slot

Informatieveiligheid lijkt steeds belangrijker te worden terwijl er geen tijd en geld beschikbaar is om oudere (legacy) webapplicaties te herschrijven. De industrie heeft hier aardig op ingespeeld en een nieuw type firewall (WAF) ontwikkeld die in het HTTP(S) verkeer kan meekijken. De WAF grijpt dan in zodra een aanval herkend wordt. Een WAF kun je via het open source domein downloaden, of je kunt een apparaat (appliance) van een gewenste leverancier aanschaffen. De keuze in welke vorm en omvang je een WAF gaat toepassen hangt sterk af van het budget dat een organisatie beschikbaar stelt aan informatieveiligheid. Een WAF kan een uitkomst zijn als er veel code is ontwikkeld waarbij weinig rekening is gehouden met alle informatie veiligheidsmaatregelen. Het is dan wel zaak de WAF goed in te richten, te testen en te beheren. Ook is het verstandig om na te gaan denken over de toekomstige webapplicaties en bijvoorbeeld de OWASP TOP 10 als een uitgangspunt te nemen omdat een WAF zeker ook geen 100% garantie kan geven dat altijd alle aanvalspatronen tijdig herkend worden.