Hvordan kan du sikre en webapplikasjon?
En typisk fallgruve er å glemme å holde webapplikasjonene oppdatert
Lag deg en oversikt
Det er muligens en enkel øvelse å lage seg en oversikt over:
- Hvilke webapplikasjoner har man?
- 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 installeren kommer med både en egen webtjener, rammeverk og tolk. F. eks: Apache Tomcat, Apache Struts og Oracle Java
Jeg vil påstå at selv om det kan være en kjedelig oppgave, så vil det å utarbeide seg en god oversikt kunne være til stor hjelp. Man bør jevnlig sjekke og vurdere behovet for å vedlikeholde webapplikasjonene sine.
Det kan være så enkelt som å lage en matrise.
Patch alt, alltid!
Som Carl skriver her og Harald Brombach her, er mantraet å alltid holde programvaren oppdatert. Realiteten er nok dessverre at mange fremdeles avventer 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.
Det kan være man mener at akkurat denne webapplikasjonen bare brukes internt eller av et begrenset antall brukere, og den er således ikke å anse som spesielt utsatt.
Noen ganger kan man rett og slett ikke enkelt få oppdatert webapplikasjonen. Det kan være fordi produsenten ikke lenger tilbyr oppdateringer, at man har valgt å ikke fornye vedlikeholdsavtaler eller at webapplikasjonen er egenutviklet.
Mulige tiltak?
Det skal sies at de ordinære tiltakene som mange har i bruk i dag, absolutt bør videreføres så som:
- Kryptert transitt: TLS og HTTPS for overføring av data mellom enhet<->tjeneste.
- Nettverkssegmentering, i minste fall makro og helst på mikronivå: pr 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% sikkerhet, så finnes det noen tiltak man kan gjøre som målrettet går på å sikre webapplikasjoner:
- Begrense angrepsflaten,
- Hjelper til i overgang mellom nyere og eldre/utdaterte autentiseringsmekanismer,
- Kan begrense forsøk på misbruk av og angrep på webapplikasjoner.
Felles for samtlige tiltak krever 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 application delivery controller (ADC).
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.
Noen vil kanskje mene at preautentisering ikke er å anbefale, fordi man har gode autentiseringsmekanismer og oppdateringsrutiner.
Derimot vil preautentisering også kunne gi en god effekt ved typiske zero-day sårbarheter, så som CVE-2021-26855.
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 webapplikasjonen:
- Benyttes det en vanlig nettleser?
- Brukes nettleseren sammen med en monitor (PC/mobil)?
- Startet brukeren med å gå til inngangsdøren til-, og fulgte brukeren normal vei videre inn til webapplikasjonen?
Et IPS implementeres gjerne på et sentralt punkt hvor all nettverkstrafikk kan inspiseres. For å kunne opprettholde et fornuftig forhold mellom ytelse og sikring, bør derfor signatursettene som benyttes skreddersys til de ulike applikasjonene som man ønsker å sikre.
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ønsker og for eksempel å kategorisere parametre: Søke- og kommentarfelt, skjemaer og andre parametre hvor brukeren kan legge inn data.
Typisk bruk er:
- Kategorisere inputfelt til kun å godta alfanumeriske verdier som ikke overstiger xx antall tegn eller bytes
- Inputfelt for brukernavn brukes til å spore en gitt bruker og dens sesjon. Eventuelle blokkerte forepørsler loggføres så med brukerens kontekst.
- Å filtrere ut feilmeldinger fra webapplikasjonen som kan gi en potensiell angriper informasjon gir også mening.
- Å tillate kun ordinære nettlesere benyttet av enheter som har en fysisk skjerm tilkoblet, ved å injisere kodesnutter som identifiserer disse.
- Å maskere og kryptere ulike parametre som bør holdes skjult og sikret, f. eks personnummer, passord og kredittkortopplysninger.
Dette kan da gjøres mellom nettleser<->webapplikasjon, for å sikre at data ikke kan snappes opp gjennom typiske Man-In-The-Middle (MITM) være seg legitime eller ikke.
Dette skiller seg fra kryptering av data i transitt: enhet<->tjener
Ta gjerne kontakt med oss om du ønsker mer informasjon eller å diskutere din konkrete situasjon