12. december 2006 - 13:51Der er
20 kommentarer og 1 løsning
XSS beskyttelse
Jeg har nedenstående 2 dokumenter som ligger på hver deres fysiske server. Problemet er, at man ikke må gøre nedenstående pga. XSS-beskyttelse.
Er der nogen der kender til nogle workarounds? Jeg har mulighed for at ændre en del på opsætningen af serverne, men det SKAL dog ende op med at være 2 separate servere (som dog begge ender på "mitdomæne.dk")
På den ene server er der et div (eller faktisk mange divs), som skal opdateres af en funktion der ligger på samme side. Denne side er skrevet i ASP.NET og genererer noget HTML-output.
På en anden server kører en hjemmebrygget HTTP-server (srv2) som genererer nogle HTML <script>-tags der skal opdatere de div's som er i det dokument (srv1) som har genereret iframen.
Du kan lave et "proxyscript" på srv1, der via en passende forbindelse henter data fra srv2 og giver videre til klienten. Klienten snakker kun med srv1. (men om det er en optimal løsning kan jeg ikke sige)
Man kan proppe en lille Flash-dims ind på hver HTML-side - så kan man snakke ind i Flash'en via JS, fra Flash til Flash via LocalConnection og og snakke tilbage fra Flash til JS på den anden side - det er muligt og kan laves ganske usynligt og hurtigt, men det er lidt besværligt (og det kræver intet på serveren - alt er clientside).
Idéen er at slippe for AJAX og proxying gennem den anden server.
Det HTML som srv2 leverer er et HTML-dokument som i princippet aldrig afsluttes (elller... det gør det efter et bestemt timeout, men efter lang tid). Dvs. det er noget data der kommer løbende med ikke-foruddefinerede intervaller og kalder funktionen "minfunc".
Hvis jeg kører init-dokumentet (srv1) og hjemmebryggen på samme server, men på forskellige porte fungerer det fint i IE, men FF mener stadig det er XSS og nægter adgang.
XmlHttpRequest i IE har den svaghed at man ikke kan hive data ud af den før dokumentet er færdigt med at indlæse. Med mindre det er mig der gør noget forkert, selvfølgelig? :)
Flash er ikke en dårlig idé, bortset fra at ingen af os her på jobbet mestrer Flash (endnu)... Der kunne endda være tale om en ren Flash-klient, som får fat i den rigtige server.
Den konstant åbne connection er også grunden til, at løsningen ikke skal køre på de primære webservere og at det ikke er optimalt at køre proxy.
Det er selvfølgelig godt det virker for dig, men jeg har altid haft det indtryk at ændring af document.domain var en "farlig" sag, der en dag ville blive fjernet. Standarden fra W3 siger også, så vidt jeg husker og er orienteret, at den ikke kan ændres, men kun aflæses.
Grunden til at den er "farlig" er problemet om hvor langt ned man kan gå i tilordningen. Man kan nok ikke sig "com" - det ville give adgang til for meget. Men kan man gå ned til "co.uk"? Og kan man iøvrigt snyde med DNS-indstillinger, så man alligevel kan lave noget snask?
Ole: Har du styr på hvad W3 siger om document.domain (selvfølgelig har du det!) Og cwboy - jeg ville ikke regne med at denne facilitet bliver ved med at være i browsere.
Koden er testet i IE6, IE7 og FF2 og virker i alle 3. Hvorvidt faciliteten bliver ved at være der i FF3 og IE7's efterfølger (eller evt. service packs) må vi tage derfra.
Gør dig selv den tjeneste også at tjekke i en ny Opera 9 - de der nordmænd har en tendens til at læse specifikationer, og lade være med at tænke selv. ;)
Men det vigtigste er egentlig bare at gøre dig opmærksom på et potentielt problem.
Jeg angriber heller ikke, at du gør opmærksom på problemet - det er jeg såmænd glad for :)
Vi bruger en form for ekstrem programmering, hvor vi gerne vil se løsinger hurtigst muligt. Derfor vælger vi helt bevidst kode der fungerer frem for kode der "fungerer i teorien". Dog bliver baggrundskoden selvfølgelig gjort så fleksibel at det forholdsvis enkelt kan redigeres senere.
Vi har som sådan ikke noget imod standarderne - bortset fra at kun ganske få browsere overholder dem.
Selvom jeg nok vil blive angrebet for det her udsagn, så kommer det alligevel: Hvis vi bruger X antal dage på at udvikle noget kode som fungerer på 90-95% af brugerskaren, så er vi godt tilfredse. Og så foretrækker vi at bruge tid på anden udvikling frem for igen at bruge det samme antal dage på at få det til at virke hos de sidste 5-10%.
domain er helt korrekt readonly ... og det ville undre mig såre, om den er valid under XHTML.
Jeg er nu mere nervøs for, om srv2 indeholder et af de dér frygtelige pseudo-streaming chat-scripts på basis af PHP's sleep-funktion. Der er som bekendt ikke meget, der trækker tænder ud på en god server =8-O
ole> Den indeholder en hjemmeskrevet (C#) http-server som bliver skrevet til formålet.
Og netop for ikke at trække tænder ud på vores IIS'er er der ikke tale om en aspx-side der aldrig slutter.
PHP kender jeg ikke meget til, og har ikke set disse chat-scripts, så det kan jeg ikke svare på.
Metoderne her skal erstatte en Ajax polling-løsning, som desværre har vist sig at skalere meget dårligt. Derudover forbruger den nuværende løsning alt for meget cpu på både serveren og klienten.
Det kan være jeg når at lære at lave Flash i mellemtiden :) Havde overvejet en Java-applet, men Java er (af erfaring) alt for tung at danse med. Der er tale om noget kode der skal være på en hel del af vores sider, hvor folk gerne klikker rundt til højre og venstre. Java plejer ikke at tage det så pænt når den skal initeres og lukkes ned, initeres og lukkes ned....
-- i min reference (Danny Goodmans Javascript Bible 4th edition, 2001 !-) er document.domain beskrevet som Read/Write, men der gøres opmærksom på en to-punktums-regel, som jeg altid har forstået som at mindst to punktummer skal beholdes, altså tld + en domæne-del mere:
(\w*?\.)+domain.tld
kan sættes til:
document.domain = "domain.tld"
-- i bogen står der dog, at kun xxx.domain.tld kan sættes sådan, men mon ikke det er en unøjagtighed ?-)
Der er nok sket en del omkring sikkerhed i JS siden 2001 ;) Jeg kender som sagt slet ikke det rigtige svar, men 2-punktums-reglen er i hvert fald problematisk ved de "generiske subdomæner", som fx. firma1.co.uk og firma2.co.uk - der er mange flere af slagsen ude omkring i verden.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
