Den här sidan innehåller information om säkerhetsproblemet Cross Site Scripting, hur det påverkar Apache själv och hur man korrekt skyddar mot det när man använder Apache-relaterade teknologier

För en översikt över problemet, se CERT Advisory CA-2000-02 som har släppts om problemet. Du bör också läsa deras relaterade tekniska tips för webbutvecklare Förstå skadligt innehåll. CERT-rådgivningen innehåller också länkar till ett antal dokument som Microsoft har lagt ut om frågan som också är värda att granska om det här problemet påverkar dig. Informationen i dessa dokument kommer inte att upprepas här; Denna information förutsätter att du har läst dessa dokument och är bekant med problemet

Vi vill betona att detta inte är en attack mot någon specifik bugg i en specifik mjukvara. Det är inte ett Apache-problem. Det är inte ett Microsoft-problem. Det är inte ett Netscape-problem. I själva verket är det inte ens ett problem som tydligt kan definieras som ett serverproblem eller ett klientproblem. Det är en fråga som verkligen är plattformsoberoende och är resultatet av oförutsedda och oväntade interaktioner mellan olika komponenter i en uppsättning sammankopplade komplexa system

Det finns specifika buggar i ett brett utbud av webbserverprodukter, inklusive Apache, som tillåter eller bidrar till utnyttjandet av detta säkerhetsproblem. Dessa buggar borde inte finnas där och måste åtgärdas. Men det är viktigt att inse att detta bara är en liten del av den totala frågan. Det allvarligaste problemet ligger i all webbplatsspecifik kod som genererar dynamiskt innehåll. Vi ger dig denna information för att utbilda dig om de problem som har upptäckts i Apache som är relaterade till detta säkerhetsproblem, men, ännu viktigare, hjälpa dig att utbilda dig om hur detta kan påverka din egen lokala kod som utvecklats med Apache-relaterade teknologier och hur du kan fixa det

Det finns ingen "golden bullet"-patch som server- eller klientleverantörer kan släppa som på ett magiskt sätt löser problemet på alla webbservrar eller klienter som använder den produkten


Vi vill också påpeka att det är viktigt att förstå att detta inte är det gamla, välkända problemet, att om en webbplats tillåter användare A att skicka innehåll som visas av användare B, måste det vara korrekt kodat. Denna sårbarhet är när innehållet både skickas in och ses strikt av användare A. På grund av svårigheten att koda utdata korrekt i alla situationer oroar sig många webbplatser inte för att koda data som endast visas för användaren som skickade data i sin begäran på grund av det felaktiga antagandet att detta inte utgör ett säkerhetshot

Påverkar detta min webbplats?

Detta är ett allvarligt säkerhetsproblem, med potentiella konsekvenser som bara börjar förstås. Det är dock viktigt att inse att detta problem inte exponerar något sätt att bryta sig in i själva servern. Vad det tillåter är för illvilliga angripare att potentiellt ta kontroll över interaktionen mellan en användare och en webbplats. Om din webbplats innehåller helt statiskt innehåll med all information tillgänglig, kan en angripare tjäna mycket lite på att ta över denna interaktion. Det är troligt att det allvarligaste som en angripare potentiellt kan göra i den här situationen är att ändra hur en sida ser ut för en viss användare

De webbplatser där detta utgör den största potentiella faran är webbplatser där användare har någon typ av konto eller inloggning och där de kan utföra åtgärder med verkliga konsekvenser eller komma åt data som inte borde vara tillgängliga. Detta säkerhetsproblem utgör ett allvarligt hot mot sådana webbplatser; det är inte nödvändigt att bryta sig in på servern för att ta kontroll över en webbplats om du istället kan få åtkomst till användarens sida

Ok, var är den Apache-relaterade informationen?
âÃÂâ Apache 1.3.12, som ger ett visst skydd mot vissa fall av detta problem

âÃÂâ Äldre Apache-patch mot 1.3.11 som åtgärdade de kända problemen i den versionen av Apache

âÃÂâ Sidan med kodningsexempel, som beskriver hur du korrekt kodar din utdata för att skydda mot detta problem med vanliga Apache-relaterade teknologier, såsom Apache-moduler, Perl och PHP

Vi förväntar oss inte att detta är det sista ordet om metoder för att utnyttja detta problem. Det är troligt att det kommer att göras fler ändringar av Apache i framtiden för att hjälpa användare att hantera det här problemet, även om inga fler buggar hittas i själva Apache. Även om vi tillhandahåller det mesta av nödvändig information för webbplatser för att skydda sig mot den här typen av attacker, finns det fortfarande många öppna problem kopplade till det här problemet

Vi inser att detta är en komplex fråga och förväntar oss att uppdatera dessa sidor för att beskriva problemen och korrigeringar på djupet när tiden tillåter

Varför namnet "Cross Site Scripting"?

Det här problemet handlar inte bara om skript, och det finns inte nödvändigtvis något tvärtom om det. Så varför namnet? Det myntades tidigare när problemet var mindre förstått, och det fastnade. Tro mig, vi har haft viktigare saker att göra än att tänka på ett bättre namn.


Du kan skicka eventuella kommentarer eller förslag om denna uppsättning sidor till [email protected]. Observera att jag inte kan svara på frågor eller förfrågningar om hjälp, så om det är det du ska skicka, vänligen spara ansträngningen.