Trusselen utenfra. Web Security, del 1 av 2: How to do

Transkript

1 Web Security

2 Web Security, del 1 av 2: Trusselen utenfra Datasystemer som er lagd for å gi tilgang utenfra, har i utgangspunktet svakheter i forhold til sikkerheten. Dette stiller høyere krav til sikkerhetstenkingen som systemet må underlegges. Av STIG ØYVANN n Nettsider og andre internettkoblete datasystemer har i og med sin grunnleggende funksjon et problem som interne systemer i utgangspunktet slipper unna: hele verden kan koble seg til dem, og slett ikke alle har gode hensikter. Trusselbildet som internettkoblete systemer står overfor, er et helt annet og langt mer komplekst enn hva som er tilfellet for tradisjonelle lokale systemer. Dette medfører at et langt kraftigere sikkerhetsregime må settes inn på bedriftens internettkoblete systemer, i forhold til det som er normalt internt i bedriften. Det er denne problemstillingen som denne artikkelserien handler om. Vi har i samarbeid med den norske sikkerhetsbedriften Watchcom Security Group AS kikket nærmere på sikkerheten til webbaserte systemer. I denne første delen skal vi se på truslene og utfordringene, mens i andre og siste del skal vi fokusere på tiltak og løsninger i denne sammenhengen. Hovedfokuset vårt i denne artikkelen ligger på sikkerhet i forbindelse med applikasjonene på serverdelen av webbasert tjenesteproduksjon. Webbaserte systemer Med begrepet «webbaserte systemer» forstår vi et hvert applikasjonssystem som er basert på protokoller, metoder, klienter og andre komponenter som har sin opprinnelse fra weben på internett. I denne sammenhengen forutsetter vi også at systemet er koblet til internett, og tilbys som en tjeneste der. I dag er det mulig å implementere nær sagt hvilken som helst programvare og funksjonalitet ved hjelp av teknologiene og utviklingsverktøyene 2 N & K 2010

3 som har kommet i kjølvannet av internettrevolusjonen. Dette blir også gjort, og det finnes mange eksempler på svært sofistikert programvare som blir levert til brukeren via nettleseren. Dagens webbaserte applikasjonssystemer har svært lite til felles med de opprinnelige websidene, som besto av statisk tekst og linker til andre liknende sider. Dette er grunnen til at mange snakker om «Web 2.0» for å skille mellom gårsdagens statiske sider, og dagens komplette applikasjonssystemer som er i stand til å utføre omtrent enhver oppgave som en lokal applikasjon kan. Arkitekturen med programvare som dels eksekverer på serveren(e), og dels overføres til nettleseren for eksekvering der, har mange fordeler. Dette er den viktigste årsaken til utbredelsen som webbaserte systemer har i dag. Disse teknikkene er også svært enkelt tilgjengelige, nå finnes det utviklingsverktøy der all underliggende funksjonalitet er innebygd, og utvikling av webbaserte systemer har mye til felles med enhver annen programvareutvikling. Dette gjør at de aller fleste profesjonelle nettsider som bedrifter bruker er basert på svært kompleks basisteknologi. Selv en relativt primitiv webside som har som primæroppgave å presentere bedriften for Standard oppsett for webapplikasjoner og brannmurer, og trafikken som slippes gjennom. omverdenen, inneholder som regel aktive elementer som gjør at nettsiden strengt tatt må betraktes som en applikasjon. Den inneholder kode som skal eksekveres og data som skal behandles, enten lokalt på serveren eller lastes ned til klienten før kjøring. En slik nettside må i tillegg behandles som en egenutviklet applikasjon, selv om den er implementert med kommersielle verktøy oppå en Watchcoms Pentagon sikrer dine verdier! Watchcom er en langsiktig partner innen informasjonssikkerhet som sikrer dine verdier på en profesjonell og kompetent måte. Jobben vår er å beskytte kundene våre mot datainnbrudd som fører til tap av sensitive opplysninger, misbruk og skadeverk. Ikke bare arbeider vi med å redusere sannsynligheten for vellykkede angrep, men vi bidrar også med å redusere skadene etter eventuelle vellykkede angrep N & K

4 kommersiell webserver. I profesjonell sammenheng må dermed bedriftens nettjenester underlegges de samme kravene til sikkerhet og pålitelighet som ethvert annet programvareprodukt som bedriften kjøper. Her svikter dessverre mange bedrifter, fordi de ikke tar inn over seg hvilken sikkerhetsrisiko en dårlig implementert webbasert applikasjon representerer for bedriften. Problemet er til en viss grad kompleksiteten som blir introdusert med moderne nettjenester. En angriper har et stort antall mulige alternativer for å ramme applikasjonen, og i mange tilfeller vil jobben med å forsvare seg være overlatt til applikasjonen selv. Dette skjer til tross for at webapplikasjonen er omkranset av brannmurer, og kommunikasjonen inn til serverne ofte skjer kryptert. Utfordringen er at når selve applikasjonen er under angrep, så kommer angriperen inn samme vei som legitime brukere benytter. Dette gjør at normale sikkerhetstiltak som brannmurer og SSL-kryptering ikke er i stand til å sperre for angrepet. Noe som ytterligere forverrer situasjonen er at vanlig sikkerhetsprogramvare som antivirus og andre liknende funksjoner ikke har noen særlig overbevisende treffsikkerhet mot slike angrep. Det medfører at funksjonene på operativsystemnivå ikke klarer å avverge angrepet. Applikasjonen er overlatt til seg selv. Dette gjør at angriperen får direkte kontakt og tilgang til applikasjonen, og kan lete etter velkjente svakheter i implementasjonen av applikasjonen. Det er enkelt å smugle inn SQLkommandoer til serveren, dersom brukerens inndata ikke kontrolleres for gyldighet. webapplikasjoner. Det er fra denne siden vi har hentet listen vi skal presentere, og for å finne utdypende informasjon om punktene under, henviser vi også til den samme nettsiden. 1. Cross Site Scripting (XSS): XSS oppstår når en applikasjon tar inndata fra brukere og sender dette til en nettleser uten noen form for enkoding eller validering av innholdet. XSS vil da eksekvere i offerets nettleser og kan blant annet stjele andre brukeres sesjoner, gjøre nettsider uleselige, installere destruktiv programkode og lignende. gjøre angripere i stand til å inkludere destruktiv kode og data som kan lede til full kompromittering av hele løsninger. Alle løsninger som tar i mot filnavn og filer fra brukere er potensielt sårbare for denne typer angrep. 4. Insecure Direct Object Reference: Systemer som eksponerer referanser til interne systemobjekter som mapper, filer, databaser og data i form av en URL eller et parameter i et skjema, er sårbare. En angriper kan manipulere disse referansene og skaffe seg direkte tilgang til disse objektene. Topp 10 sårbarheter i webapplikasjoner For at det skal være enklere å forstå hva slags svakheter selve applikasjonene har å stri med, skal vi konkretisere litt. Det kan vi for eksempel gjøre ved å studere en liste over de mest utbredte svakhetene, og teknikkene som inntrengere bruker for å kompromittere webapplikasjoner. Denne listen blir vedlikeholdt av nonprofit stiftelsen «Open Web Application Security Project» - OWASP. På stiftelsens nettsted finnes det mye lesestoff og god informasjon som kan bidra til å komme i gang med å sikre bedriftens 2. Injection Flaws: Svakheter i forhold til injeksjon av programkode, spesielt SQL-injeksjon, er vanlig i webapplikasjoner. Injiseringen oppstår når inndata fra brukere blir sendt inn i systemet som en del av en kommando eller spørring uten tilstrekkelig validering. Dersom koden blir brukt direkte i undersystemer, for eksempel til en SQL-spørring, kan dette føre til at inndata blir brukt til å utføre utilsiktete kommandoer, for eksempel ved bruk av metategnene og i SQL. 3. Malicous File Execution: Kode som er sårbar for å inkludere filer, kan 5. Cross Site Request Forgery: Dette er en teknikk som tvinger en allerede pålogget og autentisert bruker sin nettleser til å til å utføre forespørsler til sårbare webapplikasjoner på vegne av en angriper. 6. Information Leakage and Improper Error Handling: Applikasjoner kan lekke informasjon om konfigurasjon og annet sensitivt innhold. En angriper kan bruke denne svakheten som informasjonslekkasjen utgjør, til å stjele sensitive data eller utføre mer alvorlige angrep. 7. Broken Authentication and Session 4 N & K 2010

5 Management: Hvis ikke påloggingsinformasjon og sesjonsidentifikasjon er tilstrekkelig beskyttet, kan en angriper utnytte dette. Da kan inntrengeren stjele passord, nøkler og annen autentisering, for deretter utgi seg for å være en rettmessig brukere av systemet. 8. Insecure Cryptographic Storage: Webapplikasjoner tar sjeldent i bruk sterk kryptering for å beskytte sensitive data, som for eksempel påloggingsinformasjon. Angripere kan dermed gå løs på svakt beskyttet informasjon av dette slaget for å foreta identitetstyveri eller skaffe seg tilgang til kredittkortdata. 9. Insecure Communication: Mange applikasjoner beskytter ikke kommunikasjonen mellom klient og applikasjon ved hjelp av kryptering. Dette medfører forhøyet risiko for avlytting eller kapring av sambandskanaler. 10. Failure to Restrict URL Access: Applikasjoner beskytter ofte sensitiv funksjonalitet kun ved å undertrykke visning av linker eller URL-er til uautoriserte brukere. Denne informasjonen kan likevel være til stede inni dataene som overføres til mottakeren. Angripere kan bruke denne svakheten til å skaffe seg tilgang eller utføre uautoriserte operasjoner ved å aksessere disse URL-ene direkte. Høyere sikkerhet må til Det er ingen tvil om at det er nødvendig med et høyere og mer helhetlig sikkerhetsregime omkring systemene som bedriftene eksponerer mot internett. Truslene mot disse systemene er mangeartete, og innbærer forskjellige nivåer av risiko for bedriften. Tradisjonelt har vi snakket om lav risiko forbundet med hærverk, mens det i stadig økende grad dreier seg om målrettete angrep som kan ha store konsekvenser for bedriftens forretning og virksomhet. I verste fall kan bedriftsintern informasjon bli stjålet, eller så kan bedriftens nettside brukes som en distributør av destruktiv programvare som har til hensikt å infisere et stort antall pc-er nettsidens gjester. En enkel webserver med informasjon om bedriften vil kunne innbære en økt sikkerhetsrisiko idet den inneholder mer programkode enn kun en passiv webside. Da må nettsiden også betraktes som et egenutviklet system, som en applikasjon. Dermed er nettsiden likestilt med en hver annen applikasjon i bedriften, og tilfredsstille de samme kravene til sikkerhet og pålitelighet som systemene man kjøper av andre. Det er dette applikasjonssikkerhet dreier seg om, og det er det vi skal se nærmere på i andre og siste del av denne artikkelserien. Hva sier en Watchcom kunde? Den største verdien ved samarbeidet med Watchcom er den månedlige oppdateringen og testingen av nye funksjoner. Slik blir Watchcoms kunnskap og spisskompetanse intern kunnskap hos oss. Vi benytter også Watchcom til opplæring, de har faktisk lært opp hele testavdelingen vår. Watchcom har bidratt til å sette søkelyset på informasjonssikkerhet i finn.no. Kjetil Frodahl Svingen, finn.no N & K

6 Å herde programmer Datasystemer som skal tilbys på internett, må være designet for det. En svært viktig del av sikkerheten til webtjenester, er de innebygde mekanismene. Av STIG ØYVANN n I første del av denne artikkelserien så vi hvordan rettete angrep mot selve applikasjonen på webserveren som bedriften bruker mot omverdenen, utnytter kjente svakheter som mange slike applikasjoner sliter med. Dette er en trussel som mange av bedriftens øvrige sikkerhetstiltak kan ha problemer med å fange opp, og det er all grunn til å bygge inn så mye sikkerhet som man formår, direkte i selve applikasjonen. Av denne grunn kan heller ikke applikasjonssikkerheten komme til som et påbygg eller en ettertanke, etter at applikasjonen er ferdig utviklet. Sikkerhetsmekanismene og tilhørende arkitektur må inngå som en integrert og gjennomtenkt del av systemet, allerede fra tidspunktet det kun finnes på tegnebrettet. Dette er også et prinsipp som er helt uavhengig av plattformen som systemet skal implementeres på. En del av forarbeidet når en webapplikasjon planlegges, bør derfor være trusselmodellering eller mer presist, en risikoanalyse. Det er først når man har en god forståelse av hva slags trusler systemet har å forholde seg til, at man kan iverksette effektive mottiltak. Når det kommer til systemdesignen, er disse tiltakene aller best når de er innebygde i selve systemarkitekturen, i stedet for eksempel som tiltak som er eksterne for applikasjonen. I tillegg til at selve applikasjonen skal være sikker, så forutsetter vi selvsagt at øvrig arkitektur også er implementert så sikkert som mulig. Brannmurer, kryptering, autentiseringssystemer og autorisasjonssystemer har sin rettmessige plass i den totale sikkerhetsløsningen. 6 N & K 2010

7 I denne artikkelen er det imidlertid selve applikasjonen vi fokuserer på, og nå skal vi se litt nærmere på noen anerkjente prinsipper for implementering av sikre systemer. Anerkjente prinsipper Det finnes en hel rekke med prinsipper for implementeringen som sikre applikasjoner bør følge. Det norske sikkerhetsselskapet Watchcom Security Group AS har for eksempel sine tilrådinger, og vi skal se litt nærmere på disse her: Sikre standardinnstillinger: Alle standardinnstillinger i applikasjonen skal være satt til et sikkert alternativ. Egenskaper ved applikasjonen som ikke er kritiske skal være slått av som standard. Dette betyr i praksis at dersom det finnes funksjonalitet eller egenskaper ved produktet som ikke er helt nødvendig, skal dette som standard ikke bli installert eller være skrudd av. Sikker feilhåndtering: Alle feilsituasjoner skal håndteres på en sikker måte. Oppstår det feil i applikasjonen skal informasjon om feilen, og annen potensielt sensitiv informasjon skjules og ikke eksponeres for brukerne. En del type feil viser for eksempel et fullt «stack trace» som kan avsløre informasjon som kan bli brukt av en angriper til å utføre et angrep. Vis vennlige feilmeldinger og logg feilen internt. Laveste tilgangsnivå: Bruk det lavest mulige rettighetsnivå som er nødvendig. Dette betyr blant annet at brukerkontoer som er tilknyttet applikasjonen skal ha det laveste rettighetsnivået som er påkrevd for å kunne utføre oppgaver. Dette kan for eksempel være brukerkontoer som er tilknyttet webapplikasjon/ webserver eller en databasebruker. Dybdeforsvar: «Defense in depth» er å bygge flere nivåer med sikkerhet over hverandre. Dersom ett lag brister, vil det være andre intakte lag som forhindrer en eventuell kompromittering av selve systemet. Sikkerheten øker dramatisk når forsvarsmekanismer er bygd over flere lag. Sikkerhet gjennom enkelthet: Sørg for at kode og design er så enkel og lite kompleks som mulig. Jo mer kompleksitet og mengde av kode, jo større risiko for at det finnes feil i koden som lar seg utnytte av en angriper. Åpent design: Arkitekturen skal ikke behøve å være hemmelig. Åpen arkitektur er det motsatte av «security through obscurity» som mange kommersielle systemer med hemmelig kode benytter seg av. Systemet skal være designet på en slik måte at det ikke vil føre til noen ulemper dersom designet kommer på avveie. Betrakt eksterne systemer som usikre: Ved direkte bruk av tredjepartsprodukter, eller om applikasjonen på en eller annen måte knytter seg mot tredjepartsløsninger, skal disse behandles som usikre. Dette er relatert til Dybdeforsvar. Deling av ansvar: Tillat ikke at en operasjon blir godkjent basert på kun én betingelse. Et eksempel på dette er tofaktorautentisering, der brukeren autentiserer seg med to av Skanning av fingeravtrykk eller øye regnes i dag som en sterk metode for å bevise identitet. tre mulige metoder: noe han vet (PIN eller passord), noe han har (smartkort eller token) eller noe han er (fingeravtrykk eller retina). Slike kombinasjoner er langt sikrere enn kun én faktor, som et enkelt passord. Mindre angrepsflate Angrepsflaten («Attack surface») til en applikasjon er sammenfatningen av kode, grensesnitt, tjenester og protokoller som er tilgjengelig for alle brukere, og spesielt hva som er tilgjengelig for uautentiserte brukere. Attack Surface Analysis (ASA) og Attack Surface Reducation (ASR) handler om å forstå hva som danner grunnlaget for angrepsoverflaten i applikasjoner og hva som effektivt kan redusere dette for å forhindre en angriper å ta fordel av potensielt sårbar kode. Selv om kodekvalitet er svært viktig, vil det være slik at nye klasser av sårbarheter vil kunne påvirke tilsynelatende feilfri kode. Applikasjonen kan være feilfri og møte dagens trusselbilde, N & K

8 men dette kan endre seg på grunn av eksterne faktorer. Attack Surface Analysis: Dette er prosessen ved å gå gjennom alle grensesnitt, protokoller og eksekverende kode. Kode som er en del av angrepsoverflaten er mer sårbar for angrep enn annen kode. ASA bør ses i sammenheng med trusselmodelleringen. Trusselmodellering vil kunne bistå med identifisering av potensielt sårbare områder. Et eksempel på angrepsmål som kan identifiseres er pålogginger og innganger til applikasjon og server (for eksempel TCP/UDP port 80 og 443). Attack Surface Reduction: Kjerneprinsippet ved ASR er at all kode har feil og mangler som kan resultere i utnyttbare svakheter. Noen svakheter kan lede til full kompromittering av applikasjon og underliggende systemer. For å forhindre dette må kode og angrepsoverflate Med «Dybdeforsvar» mener vi flere lag med beskyttelse utenpå hverandre, slik at ett enkelt brudd ikke medfører kompromittering. reduseres til et minimum. Kodekvalitet og ASR kan bidra i å utvikle applikasjoner som er sikrere. ASR omfatter: Reduksjon av mengden programkode. Å begrense omfanget av hvem som kan få tilgang til programkoden. Å begrense omfanget av hvilke identiteter som kan aksessere programkode. Reduksjon av rettigheter til programkode. Helsesjekk: informasjonssikkerhet Watchcom Rådgivning utfører blant annet profesjonelle sikkerhetstester mot virksomheter. Innsidetest avdekker sårbarheter fra intern-nettet Utsidetest avdekker utsatte tjenester og sårbarheter fra internett Applikasjonstest avdekker sårbarheter i web-applikasjoner Trådløs-test avdekker konfigurasjonsfeil Social Engineering tester den menneskelige brannmuren Watchcoms Pentagon sikrer dine verdier! Din virksomhet vil få dokumentert de sikkerhetsmessige utfordringene den står ovenfor, og vil gjennom konkrete anbefalinger kunne hindre vellykkede angrep N & K 2010

9 Eksempler på ASR er å ikke gjøre tilgjengelig funksjonalitet og egenskaper som standard med mindre dette er absolutt nødvendig, redusere inngangsporter for anonyme brukere og redusere tilgangsnivået til et minimum av det nødvendige for alle brukere. Sikkerhet er en syklus Sikkerhet er ikke et prosjekt som avsluttes når applikasjonen er ferdig. I alle profesjonelle sammenhenger påpekes det at sikkerhet må være en kontinuerlig prosess, som oftest går i sykluser. En slik sikkerhetssyklus fremstilles forskjellig av ulike aktører, men alle disse har til felles at den slutter tilbake ved begynnelsen. En helt generell sikkerhetssyklus kan se slik ut: 1. Analyse: Her gjøres en risikoanalyse, slik at trusler og prioriterte tiltak kan identifiseres. Som en del av analysen blir også verdien av data som systemet håndterer satt, slik at det er mulig å utrede konsekvenser. 2. Implementasjon: I denne fasen implementeres alle sikkerhetstiltak som det foregående punktet har identifisert. Dersom det er knappe ressurser, vil analysen avgjøre hvilke tiltak som må på plass først, prioritert etter risikoen til og konsekvensen av truslene. 3. Verifikasjon: Etter at tiltakene er satt i verk, må man forvisse seg om at de fungerer. I vår sammenheng kan det for eksempel bety testing, overvåking og rapportering. Alle praktiske erfaringer man gjør seg etter at systemet er satt i produksjon er også å betrakte som verifikasjon. 4. Revisjon: Kunnskapen som er avdekket i forrige punkt, sammen med all annen kunnskap om nye trusler og nye teknikker som har dukket opp, tas med tilbake til punkt nummer 1. Dermed begynner syklusen igjen, i en konstant tilstand av sikkerhetsforbedringer. Øk kunnskapen! Det første skrittet mot å mestre sikre webapplikasjoner, er kunnskap. Watchcom tilbyr opplæring i prinsippene for utvikling av sikre webapplikasjoner, i form av et en-dags kurs. På dette kurset gjennomgås blant annet alt vi har sett på i denne artikkelen, og det er ikke knyttet til spesielle utviklingsverktøy eller arkitekturer. Generell kunnskap om programvareutvikling under PHP, JSP, ASP.NET, Perl eller liknende teknologier forutsettes. Kurset har en avsluttende eksamen, og bestått eksamen fører til sertifiseringen Certified CyberSecurity Professional Web Security («CCSP Web Security»). Profesjonelt sikkerhetsarbeid er ikke et avsluttet prosjekt, det er en konstant prosess. I vår sammenheng er bevisst sikkerhetstenking spesielt viktig. Selv en webapplikasjon som er bevist feilfri og fullstendig sikret, vil ikke nødvendigvis vedvare slik over tid. Det kommer av at systemet er koblet til nettet, og der endrer trusselbildet og angrepsteknikkene seg hele tiden. Det kan medføre at applikasjonen har behov for oppdateringer, rett og slett for å holde tritt med utviklingen ute. Av den grunn kan det være viktig å legge spesielt vekt på valideringen av applikasjonen. Dette kan løses ved å gjøre regelmessige kontroller av sikkerheten til webapplikasjonen, selv om den ikke har fått endringer i mellomtiden. Dette er tjenester som også Watchcom tilbyr, der det til og med er mulig å få utført simulerte angrep mot systemet, både fra ut- og innsiden av bedriftens lokalnett og brannmurer. Til sammen utgjør applikasjonssikkerhet og alle andre tiltak vi har nevnt i denne artikkelserien det som er nødvendig for å operere så trygt som mulig på internett. Dette kan umiddelbart virke som en overdreven paranoia, men å gjennomføre slik sikkerhet kan godt vise seg å være det rimelige alternativet, sammenlignet med mulige konsekvenser av et vellykket angrep på bedriftens webtjenester. Av den grunn alene er det god grunn til å sette seg godt inn i det som skal til for å sørge for at bedriftens webservere opererer så sikkert som mulig! WEB SECURITY SIKKERHET I WEB-BASERTE APPLIKASJONER Et dagskurs for utviklere og arkitekter. kurs@watchcom.no N & K