Rask tips En guide til krypteringspolitikkfiler

Hver Flash- eller Flex-utvikler som har hatt tilgang til eksterne ressurser, har kommet over en policyfil for crossdomain.xml på et tidspunkt. Denne artikkelen tar en titt på hva disse politiske filene er, hvordan de virker og hvordan du kan lage en for deg selv.

Eksempel

La oss ta en titt på et eksempel på hva vi snakker om:

Hva er så spesielt med dette? Vel, SWF laster smileybildet fra http://mytestgae.appspot.com/images/smiley.jpg, ikke fra Activetuts + -domenet. Uten en kryssdomenepolitikkfil vil forsøk på å laste bildet føre til en SecurityError.

Hva er en kryp domenepolicyfil?

Sikkerhetsmodellen kjent som "samme opprinnelses" -politikk, implementert av de fleste moderne nettlesere, forhindrer at enkelte typer innhold blir tilgjengelig eller endret hvis filen eksisterer på et annet domene. Det er ikke en hard og rask regel; HTML-sider vil gjerne vise bilder og HTML fra sider på andre domener. Men for JavaScript forhindrer den samme opprinnelsespolitikken et dokument eller skript som er lastet fra en opprinnelse, fra å få eller sette egenskaper til et dokument fra en annen.

Flash inneholder en lignende sikkerhetspolicy som vanligvis forhindrer en Flash-applikasjon fra å få tilgang til data som er vert på et eksternt domene. Men det er mange omstendigheter der det ikke bare er nyttig, men forventet at ressursene vil få tilgang til eksternt. Et elektronisk fotoalbum ville være begrenset hvis eksterne applikasjoner ikke kunne laste ned bildene. Det ville også være dumt hvis en webtjeneste ikke tillot at eksterne applikasjoner kunne kommunisere med det.

Av denne grunn er det mulig å opprette en XML-fil, kalt crossdomain.xml, som angir hvordan data på et domene kan nås av et Flash-program som er hostet på et eksternt domene. For det meste er disse politiske filene ganske enkle, men det er noen detaljer som det er nyttig å være oppmerksom på.

Hvis du er vert for innhold som du vil få tilgang til av eksterne Flash-applikasjoner, må du opprette en crossdomain.xml-fil. La oss starte med å se på et grunnleggende eksempel.

Trinn 1: En grunnleggende crossdomain.xml-fil

Her er en veldig enkel crossdomain.xml-fil. Når denne filen er vert på roten av domenet ditt, tillater det eksterne Flash-applikasjoner tilgang til alle ressursene på domenet ditt.

Politikkfilen inneholder en enkelt stikkord. Innenfor dette kan du ha null eller mer tags. Hver tag kan brukes til å definere et domene eller en IP-adresse hvorfra et Flash-program kan få tilgang til de lokale ressursene. Attributtet domain = "*" angir at alle domener har tilgang. Dette er takket være stjernekortet, som brukes her for å matche alle domener og IP-adresser.

For de fleste situasjoner er denne "tillate alle" policyfilen tilstrekkelig. Det gir Flash-applikasjoner tilgang til alle gjengivelsesressurser, mens sikkerheten du har på plass (som passordbeskyttede sider) vil forhindre at Flash-applikasjoner får tilgang til sensitive data.

(Merk at du ikke kan sette en crossdomain.xml-fil på domenet ditt, slik at SWF-er også på domenet ditt for å få tilgang til eksterne filer på en annen domene!)

Trinn 2: Spesifiserte domener

Hvis du ikke vil tillate global tilgang til dine offentlige ressurser, domenetattributtet i tag kan brukes til å gi tilgang til bestemte domener.

Du kan angi et domene i sin helhet. Eksempelet nedenfor gir tilgang til Flash-applikasjoner som er vert i www.example.com-domenet.

Du kan bruke asterisk wildcard for å matche de domenene som slutter med det oppgitte suffikset. Her gir vi tilgang til Flash-applikasjoner på domenene example.com, www.example.com, whatever.example.com etc.

Trinn 3: Angitte IP-adresser

Du kan angi tilgang via IP-adresse, akkurat som du kan gi tilgang til Flash-applikasjoner som er vert på bestemte domener. Det samme merket og attributter blir brukt, bortsett fra i dette tilfellet bruker du en IP-adresse:

Trinn 4: Arbeide med HTTPS

Som standard kan et Flash-program som er hostet på en HTTPS-server, bare få tilgang til ressurser på eksterne HTTPS-servere. Men gitt overhead at HTTPS kan legge til en server, vil du kanskje ikke bruke den. I dette tilfellet setter du inn sikre tilskrive falsk vil tillate en Flash-applikasjon på en HTTPS-server for å få tilgang til data fra en HTTP-server.

Trinn 5: Remote Flash-programmer

Så hva hvis du ikke vil at eksterne Flash-programmer skal få tilgang til dataene dine? Du kan enten opprette en crossdomain.xml-fil som ikke inneholder noen tags:

Eller du kan ikke ha en crossdomain.xml-fil i det hele tatt.

Trinn 6: Granulær kontroll av underkataloger

En kryssdomenepolitikkfil styrer tilgangen til katalogen den ligger i, og alle underkataloger under den. Slik legger du til en "tillat alle" policyfilen på domenestoten din, gir tilgang til hele domenet ditt. Men det kan være situasjoner der du bare vil tillate tilgang til en bestemt underkatalog.

Med de nyeste versjonene av Flash Player krever dette to XML-filer. Først må du plassere en crossdomain.xml-fil i roten til domenet ditt, som gjør at Flash kan behandle flere kryssdomenepolitiske filer i underkatalogene. Dette gjøres med stikkord. I eksemplet nedenfor setter vi inn tillatt tvers av domener-politikk tilskrive alle, noe som betyr at kryp domenepolitikkfiler som kan eksistere i underkatalogene, blir behandlet. Denne oppførselen er en endring i Flash Player 9 Update 3 og opp. Tidligere var policyfiler i underkataloger behandlet som standard uten å måtte sette tillatt tvers av domener-politikk Egenskap.

Legg merke til at vi ikke har lagt til noen koder, som betyr at det ikke finnes flere crossdomain.xml-filer i underkatalogene, vil eksterne Flash-applikasjoner ikke ha tilgang til ressursene på denne serveren.

Du kan finne ut mer om metapolitikkalternativene i denne artikkelen.

Deretter plasserer du en crossdomain.xml-fil i underkatalogen du vil kontrollere.

For å se et eksempel på dette i aksjon, sjekk ut denne filen. Denne policyfilen, i roten til http://mytestgae.appspot.com/ domenet, bruker tag for å delegere kontroll til eventuelle crossdomain.xml-filer som kan eksistere i underkatalogene. Da gir denne policyfilen i / bilder / underkatalogen full tilgang til katalogen og eventuelle underkatalog under den. Så et eksternt Flash-program kunne få tilgang til smiley face-bildet i bildekatalogen slik:

Tilgang til smiley face-bildet i / bilder-begrenset / katalogen er imidlertid ikke tillatt fordi det ikke er noen crossdomain.xml-fil i den begrensede mappen for å overstyre (manglende) tilgang gitt av crossdomain.xml-filen i roten av domenet. Å kjøre koden under vil føre til at et unntak kastes:

Unntaket lyder:
SecurityError: Feil # 2123: Feilsøking for sandkasse: LoaderInfo.content: file: /// D | /CrossDomain.swf kan ikke få tilgang til http://mytestgae.appspot.com/images-restricted/smiley.jpg. Ingen policyfiler gitt tilgang.
på flash.display :: LoaderInfo / få innhold ()
ved MethodInfo-635 ()

Trinn 7: Kryp domenepolitikk vs brannmur

Så fra ovenstående informasjon ser det ut som kryssdomenepolitikkfiler kan brukes til å effektivt begrense tilgangen til Flash-applikasjoner som ikke er vert på ditt eget domene. Selv om det er sant, bør du ikke stole på en kryssdomenepolitisk fil for å begrense tilgangen til sensitiv informasjon. Mens Flash kan respektere en crossdomain.xml-policyfil, vil andre plattformer som PHP ikke. Gjør et søk etter PHP Flash Proxy for å se hva jeg mener. Ved å bruke en proxy er det mulig å få tilgang til all offentlig tilgjengelig data uavhengig av eksistensen av kryp domenepolitikkfiler. Og du trenger ikke engang å betale for en PHP-server - som jeg vil demonstrere i en fremtidig artikkel, kan Google App Engine brukes som en proxy uten forutgående kostnader.

Den nederste linjen er at krypteringspolitikkfiler gir en måte å selektivt gi tilgang til lokale ressurser via eksterne Flash-programmer, men bare hvis alle spiller etter reglene. Hvis du vil sikre at private data forblir private, er det ingen erstatning for en brannmur.

Konklusjon

Å håndtere kryp domenepolitikkfiler trenger ikke å være komplisert. Når du forstår grunnleggende om hvordan de fungerer, er det ganske enkelt å gi eller begrense tilgang til dataene dine ved hjelp av eksterne Flash-applikasjoner. Bare vær oppmerksom på at de ikke er så sikre som de i utgangspunktet kan virke.

Jeg håper du likte denne Quick Tip, takk for å lese!

Kode