Har precis som Mads Kristensen märkt av att attacker med URL-injektioner har ökat det senaste.
På en sajt har jag fått in anrop som ser ut ungefär som här:
http://www.examplesite.com/product.aspx?categoryid=0 and user>0 http://www.examplesite.com/product.aspx?categoryid=0 ' and user>0 and ''='
URLerna är påhittade men på slutet av dem ser ni hur roboten lägger till extra strängar i parametern. Jag hade inte tänkt på att skydda mot detta och det blev error när sidan försökte konvertera parametern till en integer.
För att undervika fel kan man använda TryParse istället för Convert.ToInt32 (om man nu vart lika oförsiktig som jag från början).
int categoryId = -1; Int32.TryParse(Request.QueryString["categoryid"], out categoryId);
Läs mer på MSDN eller i kommentarerna till ett inlägg hos CodeBetter.com.
Häromdan publicerade GnuCitizen exempel på hur ett säkerhetshål i Quicktime kan utnyttjas till att att komma åt underliggande funktioner i webbläsaren Firefox. Och inte nog med det. Det visar sig även att det går att få tillgång till användarens operativsystem och program.
På bloggen visas ett "snällt" exempel på hur man kan starta miniräknaren i Windows genom att lägga in extrakod i Quicktime-koden. Man visar även hur man kan stänga av användarens dator. Vad för riktiga elakheter man kan hitta på med detta vill jag inte ens tänka på.
Så nu gäller det att se upp om man använder Windows och Quicktime. Rapporter visar på att även Opera och Internet Explorer kan vara sårbara för av denna säkerhetsbrist.
Ett sätt att skydda sig med Firefox verkar vara att installera tillägget NoScript. Det finns också tips om att använda ett alternativ till Quicktime som t ex Quicktime Lite.
Apple har vetat om detta säkerhetsproblem ett bra tag men inte gjort något åt det. Hoppas de börjar lyssna nu när man förstår vilken skada som det kan ställa till med hos webbsurfare.
Inloggningsuppgifter till 100 ambassaders emailkonton har publicerats på nätet av en (modig) svensk säkerhetskonsult vid namn Dan Egerstad. DN och Computer Sweden skriver mer och har intervjuat honom. Den kommer nog inte dröja länge innan resten av världen snappar upp denna nyhet. Computer Sweden har vart smarta och även skrivit artikeln på engelska (nog första gången jag ser detta på IDG-nätverket). Den kommer nog bli rätt friskt länkad under morgondagen.
Han meddelar att han kommit över denna information genom en säkerhets-labb han gjorde för ett tag sen. Sedan dess har han funderat på vad han skulle göra med den, och beslutade sig till sist för att publicera den publikt och meddela media.
Klokt eller ej får framtiden utvisa men man kan förstå problemet han brottats med. Att kontakta alla 100 ambassader skulle väldigt tidskrävande och det skulle nog kunnas tas emot på fel sätt av myndigheterna. Att överlämna uppgifterna till Säpo vore ett spioneribrott.
Läs själva hans meddelande på bloggen där uppgifterna publicerats, Deranged Security.
Förhoppning om säkrare e-postsystem
Förhoppningsvis kan något gott komma ur detta, det är ju uppenbart att vi behöver säkrare e-postsystem. Än så finns inga uppgifter på hur informationen har läckt och det är det nog många som vill ha svar på.
Första problemet med nuvarande email-system är att man kan skicka mail från vilken adress som helst, med lite programmeringskunskaper. Spam hade varit mycket svårare att skicka ifall detta inte var fallet.
Att det nu visar sig finnas brister, som gör att man kan komma över inloggningsuppgifter och läsa epost, borde sätta igång en utveckling mot säkrare system. Låt oss hoppas på det i alla fall.
Uppdateringar
(2007-08-31) Indiska tidningar har loggat in på e-postkonton för den indiska ambassaden i Kina med hjälp av inloggningsuppgifterna som läckt ut. Dessa har sedan publicerats på deras nätupplaga,som innehåller bland annat lista på inköp gjorda av det indiska försvaret
Urchin är ett statistikverktyg för att analyera besökartrafik. Det köptes år 2005 av Google och är det program som ligger till grund för Google Analytics.
Nu har det kommit fram Urchin v5.7.03 verkar vara sårbart mot XSS-attacker och att det i vissa fall verkar att kringgå inloggningsskyddet. Ha.ckers.org har mer info och visar exempel på hur man kan länka in JavaScript från en extern sajt, till inloggningsformuläret i Urchin.
Vi jobbar med några servrar som det körs Urchin på och har kunnat bekräfta XSS-problemen. Här är ett exempel på en länk som jag lyckades köra (adressen och portnumret är påhittade)
Det här är inte speciellt dramatiskt egentligen, men lite kul med action. Någon postade för en stund sen en XSS-länk på den engelska delen av vår hemsida.
Jag visste att kommentarsfältet inte var skyddat mot HTML och har inte brytt mig om att fixa det förrän nu.
Attackvektorer
I kommentaren som postades låg följande html-tagg och det är alltså bara en test för att se ifall det gick att köra javascript genom kommentarerna på vår blogg.
På ha.ckers.org's XSS (Cross Site Scripting) Cheat Sheet kan man läsa att denna vektor inte fungerar på IE7 eller FF2 men på IE6 och Opera. Där finns även fler referenser till andra vektorer.
Hur man skyddar man sig mot XSS (med .NET)
Det enklaste alternativet är att låta validateRequest vara på slaget som det är som standard. Nackdelarna är att det då inte går att posta taggar över huvudtaget och att ett error visas. Läs mer om för-/nackdelar ValidateRequest här. I vår blogg som handlar om webbutveckling vill vi ju kunna tillåta html-kod från våra besökare, så vi har detta skydd avstängt.
Istället ser vi till att använda Server.HtmlEncode på all text som kommer från besökaren (det var detta jag just la till).
En bra effekt är att det numera går att skriva htmlkod i kommentarerna och den visas som den ska. Vissa har ju märkt att det inte fungerat så bra tidigare och vi borde ha fixat det för länge sen.
Testning tillåtet
Om nån är intressarad får ni gärna försöka att posta XSS till detta inlägget. Jag antar att det är omöjligt men vem vet om det finns någon obskyr metod som inte HTMLEncode klarar av att filtera.
Har även lagt in en liten funktion som ska göra om url till länkar. Där kan jag tänka mig att det kan gå att få in någon XSS-variant. Så här ser funktionen ut ifall nån vill prova att "hacka" den.
Säkerhetsexperten beni lämnade mig ett meddelande om att han har hittat 7 säkerhetshål i bloggplattformen Wordpress (senaste versionen 2.2.1).
Han har nu skapat en vänlig XSS-mask som fixar dessa hål. Jag har själv ingen Wordpress-blogg att testa på men jag litar på att beni's skript gör det han påstår.
Men nu när säkerhetshålen är publicerade är det alltså stor varning för att XSS-attacker, utförda av illvillingar kan ske. Vad gör man? Antingen avvaktar man och väntar på den officiella Wordpress-fixen, eller kör beni's skript för att fixa hålen med en gång. Se till att du tar en ordentlig backup innan.
Men dessa säkerhetshål kan en elak person bland annat, radera alla dina blogg-poster (inget roligt alls!), lägga till sig själv som användare eller annat otyg.
Om det är en bra idé att köra patchen kan jag inte svara på och jag ansvarar inte för några bieffekter som den kan ha på din blogg.
Uppdatering: Nu har Wordpress fixat säkerhetshålen. Benjamin Flesch (beNi) är imponerad att det bara tog 6 dagar. Han skriver att han inte är så nöjd med att Wordpress-teamet inte tackade honom officiellt, men nu ser jag att de har lagt till ett meddeladne i utannonseringen på deras blogg.
Communitysajten Lunarstorm har blivit attackerade av en XSS-mask och runt 5000 användare fick sina presentationer raderade. Dessa ersattes istället av en länk till den konkurrerande communityn Hamsterpaj. Skriptet la även in gästboksinlägg på nio utvalda profiler.
Via kommentarerna hos IDG hittade jag även en länk till gate 303 som också skriver om attacken och visar upp själva koden som användes.
Lunarstorm utvecklas i ASP.NET som är relativt känt för att ha bra skydd mot liknande attacker. När man studerar attackkoden ser man att _EVENTTARGET och _VIEWSTATE har modifierats. Kanske har Lunarstorms utvecklare varit oförsiktiga och stängt av validateRequest-attributet, men det kan ju inte jag svara på. Skulle vara intressant att höra mer om exakt hur denna attack kunde möjliggöras, så andra kan ta lärdom.
Över 45 miljoner kreditskortsnummer har blivit stulna från klädkedjan TJX och det är förmodligen den största kreditkortsläckan någonsin, skriver Lars Olofsson.
Säkerhetstjänsten Stolen ID Search som vi har rapporterat om tidigare, borde alltså fått ett rejält uppsving i sina affärer. Deras affärsidé går ju ut på att söka upp kreditkortsuppgifter som hamnat i fel händer och hjälpa individer som drabbats.
Det är väl endå uppenbart att det nuvarande kreditkortssystemet inte fungerar särskilt bra. Säkerheten måste ökas för att e-handelkunder ska kunna handla säkert.
Säkerhetsexperter upptäckte för ett tag sen att CSS-historiken kunde användas till att ta reda på vilka webbplatser en besökare har vart på tidigare. Normalt används detta endast för att webbläsarna ska kunna markera besökta länkar i en annan färg eller stil.
Ett hot mot integritet kan man tycka och definitivt ett säkerhetsproblem. En nätfiskare kan med denna metod enkelt får reda på om besökaren nyss har loggat in på Gmail, Hotmail, Yahoo eller vilka banktjänster denna använder. Och på sådant sätt rikta sina nätfiskningsaktioner mot just de tjänster som användaren nyttjar.
Jeremiah Grossman visade upp exempelkod i postningen "i know where you've been" redan för ett halvår sedan och RSnake har ett "CSS History Hack"-demo (för Firefox) som visar hur det fungerar i praktiken.
Jag har själv bara väntat på att man skulle få se exempel på "kreativ markadsföring" eller småfunktioner som förhöjer besökarens upplevelse. Att få tillgång till sån här extra information om besökaren borde ju locka många sajtutvecklare.
Bloggen int2e.com visar nu ett exempel på ett användningsområde. De beskriver ett skript för en flexibel "Digg-knapp" som bara visas för besökare som tidigare vart på Digg.com.
Att det är en vanlig metod att temporärt "ta ner" webbplatser genom Denial Of Service (DOS) är ett välkänt faktum. Det har under åren skett många hot och icensättningar av överbelastningsattacker mot webbplatser. Ibland politiska aktioner men även utpressning mot krav på pengar.
Bland annat har spelsajter i USA pressats på stora pengar av internetbrottslingar.
Kortfattat går det till så att webbplatsen överbelastas med ett stort antal anrop och genom att rikta sig mot dokument av stor datamängd.
Så vad kan man göra för att skydda sig mot dessa attacker?
Jo dels kan man göra det genom att använda smart hårdvara som kan känna av ifall trafiken härstammar från otillåtliga källor eller följer ett felaktigt mönster.
Men man kan även bygga in skyddet direkt i sin webb-applikation som Omar AL Zabir visar ett exempel på i sin blogg. Hans metod skriven i ASP.NET C# går ut på att besökarnas IP-adresser sparas i Cache-minnet under en stund och håller reda på att inte för många anrop har kommit från samma källa, inom en tidsrymd.
Smart tänkt och ett bra komplement till hårdvaruskydd.