Slik sikrer du en webapplikasjon

Det er viktig å sørge for at programvaren alltid er oppdatert. Realiteten er nok dessverre at mange fremdeles venter med oppdateringene til faste tidspunkt og heller ikke har oversikt over alle programvarekomponenter som jevnlig må vedlikeholdes.

Proaktivt vedlikehold vil alltid være mer behagelig enn reaktiv brannslukking.

En typisk fallgruve er å glemme å holde webapplikasjonene oppdatert. De blir gjerne bare oppdatert når man ønsker ny funksjonalitet, eller når man opplever feil og produsenten henviser til nyere versjon for å kunne yte support eller tilby feilretting.

En grunn til at man ikke oppdaterer, kan være at man mener at akkurat denne webapplikasjonen bare brukes internt eller av et begrenset antall brukere, og at den derfor ikke er spesielt utsatt.

Andre ganger er det rett og slett ikke mulig å få oppdatert webapplikasjonen på en enkel måte. Det kan være fordi produsenten ikke lenger tilbyr oppdateringer, at man har valgt å ikke fornye vedlikeholdsavtaler eller at webapplikasjonen er egenutviklet.

Skaff deg oversikt over webapplikasjonene

Man bør jevnlig sjekke og vurdere behovet for å vedlikeholde webapplikasjonene sine. Det er muligens en enkel øvelse å få oversikt over:

•  Hvilke webapplikasjoner har dere?
• Hvilke brannmuråpninger finnes som gir nettverkstilgang til den enkelte webapplikasjonen?
• Hvilke autentiseringsmekanismer om noen, benyttes på inngangsdøren til webapplikasjonen?

Derimot er det kanskje ikke like enkelt å få dypere innsikt i hvilke delkomponenter som en webapplikasjon er bygget opp av og om disse holdes oppdatert:

• Benyttes det komponenter som følger operativsystemet, så som webtjener, rammeverk og biblioteker?
• Hvilke(t) kodespråk benyttes i applikasjonen?
• Er det benyttet 3. parts programmer, rammeverk, biblioteker eller lagt inn/lånt kode som ikke enkelt lar seg oppdatere automatisk?

Et typisk eksempel er en webapplikasjon som man installerer på en Microsoft Windows Server, hvor installasjonsprogrammet kommer med både en egen webtjener, rammeverk og tolk. For eksempel Apache Tomcat, Apache Struts eller Oracle Java.

Jeg vil påstå at selv om det kan være en kjedelig oppgave, så vil det å utarbeide en god oversikt være til stor hjelp.

Tiltak som gir deg langt bedre sikkerhet

De ordinære tiltakene som mange allerede bruker i dag, bør også være på plass for webapplikasjonene:

• Kryptert transitt: TLS og HTTPS for overføring av data mellom enhet og tjeneste.
• Nettverkssegmentering, i minste fall makro og helst på mikronivå: per tjeneste og tjener innad i din egen infrastruktur.
• GEO-filtre: Har du ikke brukere fra Iran eller Nord-Korea, kan du med fordel blokkere ut kjente IP-adresser fra disse landene.
• Logg av bruk og trending for å oppdage unormaliteter.

Selv om det aldri finnes noe som kan gi 100 prosent sikkerhet, så finnes det noen tiltak man kan gjøre som målrettet går på å sikre webapplikasjoner, og som kan begrense angrepsflaten, hjelpe til i overgangen mellom nyere og eldre eller utdaterte autentiseringsmekanismer, og ikke minst begrense forsøk på misbruk av og angrep på webapplikasjoner.

Felles for samtlige tiltak er at man kan dekryptere TLS-sesjonene for å få innsyn i de faktiske data som strømmer inn mot tjenesten man ønsker å sikre. HTTPS-inspeksjon er et annet ord for dette, og det kan enten gjøres i en moderne brannmur (NGFW) eller gjennom en Application Delivery Controller (ADC).

Her er mine tre anbefalte tiltak:

1: Preautentisering

Se på preautentisering som å bygge et høyt gjerde med vollgrav rundt en webapplikasjon.

I all hovedsak fungerer det på den måten at en bruker må autentisere seg og få autorisasjon via et annet system, før brukeren får lov til å slippe inn til inngangsdøren til webapplikasjonen. Dette vil også kunne gi god effekt ved typiske zero-day-sårbarheter.

Med bruk av en moderne Application Delivery Controller (ADC) kan man sy sammen løsninger som stopper og rapporterer brute-force angrep, avkrever multifaktor autentisering (MFA) og som kan oversette ulike autentiseringsprotokoller.

Det siste er typisk brukt når man ønsker å innføre MFA for en enkeltstående webapplikasjon, eller når man ønsker å benytte en felles identitetstilbyder (IDP) til å fremdeles kunne aksessere webapplikasjoner som bruker eldre og mindre sikre autentiseringsprotokoller. 

2: Intrusion Prevention System (IPS)

Se på IPS som en signaturbasert beskyttelse mot kjente sårbarheter (blacklist).

Et IPS fungerer slik at det inspiserer nettverkstrafikk opp mot et sett med signaturer for kjente sårbarheter i operativsystem, rammeverk, kodespråk, applikasjoner osv. Signaturene til et IPS er gjerne generelle, og de har ingen forhold til kontekst i bruk av webapplikasjoner. For eksempel kan ikke et IPS se på om det benyttes en vanlig nettleser, om nettleseren brukes sammen med en monitor (PC/mobil) eller om brukeren startet med å gå til «inngangsdøren» til web-applikasjonen for deretter å følge normal vei inn.

Et IPS implementeres gjerne på et sentralt punkt hvor all nettverkstrafikk kan inspiseres.

3: Webapplikasjons-brannmur (WAF)

Se på WAF som et filter, hvor kun «normal» bruk slipper gjennom til webapplikasjonen (whitelist).

En moderne WAF opererer på Lag 7 i OSI-modellen, og kan derfor både spore brukere og forstå kontekst i bruk av en webapplikasjon. Videre kan den læres opp til å gjenkjenne inngangsdøren, normalt bruksmønster og for eksempel å kategorisere parametere: Søke- og kommentarfelt, skjemaer og andre parametere hvor brukeren kan legge inn data.

Typisk bruk for en WAF kan være å kategorisere inputfelter til å kun godta alfanumeriske verdier som ikke overstiger et gitt antall tegn, filtrere ut feilmeldinger fra webapplikasjonen som kan gi potensielle angripere informasjon, eller å tillate tilgang kun via ordinære nettlesere på enheter som har en fysisk skjerm tilkoblet. En WAF kan også maskere og kryptere ulike parametere som bør holdes skjult og sikret, for eksempel personnummer, passord og kredittkortopplysninger.

Innfører du disse tiltakene, vil du være bedre sikret mot angrep.

Henrik Schewe, systemarkitekt, Sicra