Avancerade Webbteknologier 2. AD11g Göteborg 2012 Säkerhet

Transkript

1 Avancerade Webbteknologier 2 AD11g Göteborg 2012 Säkerhet

2 Korta punkter Projekt: Något som behöver redas ut? Product: Public Guid CategoryID {g; s;} Public virtual Category Category {g; s;} Category: Public virtual ICollection<Post> Posts {g; s;} Category + CategoryID i product Virtual: Lazy loading (måste anv. t.ex: FindAll().Include(p => p.category) ) using System.Data.Entities.

3 Idag Säkerhet Allmänna tips Lösenordshantering Specifika vulnerabilities: SQL Injection XSS (Cross-Site Scripting) XSRF/CSRF (Cross-Site Request Forgery) Buffer Overflow

4 Allmänt Uppdatera applikationer/ramverk ASAP Många intrång är baserade på kända säkerhetshål hos applikationer och ramverk. Var också medveten om att det ibland är lagg mellan känt hål och säkerhetspatch. Var misstänksam mot all input (inte bara user input) om möjligt tillåt bara strängar på ett visst format (datumsträng, etc). Html.Encode / Html.Decode / Sanitize / Etc.

5 Allmänt Security by Obscurity fungerar aldrig av X rutinerade adversaries så kommer någon garanterat lista ut vad du gjort, eller mer troligt: någon har redan sett något liknande och hittar din hemlighet direkt. Liknelse: Du har ett lösenord uppskrivet på en lapp i din lägenhet du har gömt lappen på det listigaste stället du kunnat komma på. Om 1 person gör inbrott i din lägenhet för att hitta lösenordet så är du kanske säker. Om personer gör inbrott i din lägenhet i samma syfte så är det sannolikt kört.

6 Läck inte information Variant 1: Databaslösenord, etc. i ett publikt repo (github) eller skickat som plain text i ett mail, eller liknande. Variant 2: Användare kommer åt andra användares privata information genom att ändra ett id i en URL eller liknande. Kolla behörighet på allt som kräver behörighet (Gör inte misstaget att endast kontrollera behörighet på vid en ingångssida men ej på resurser bakom ingångssidan). Variant 1 är ett mycket svåråtkomligt problem ofta handlar det om saker som man inte tänkt på som informationsläckage eller informationshantering hos personer som inte är insatta i problematiken.

7 Lösenord Skriv aldrig egna krypterings/hashningalgoritmer Man kan inte slarva med lösenordshantering bara för att siten ifråga är icke-kritisk Många kostsamma dataintrång har börjat med lösenordsläckage från Hobby sidor och spritt sig därifrån (folk återanvänder användarnamn/lösenord). Överväg att göra något i stil med 15 minuters lock out då användaren matat in 3 felaktiga lösenord ( => En autom. attack mot er sida kan testa 12 lösenord/h) Minimum för lösenordshantering: Salted Hash Steg upp: Långsam hash alg. (ex. bcrypt) Steg upp: + Pepper (Kan öka säkerheten ifall endast databas, ej källkod, är läckt). => SlowHash(Password + Salt + Pepper) Verkligheten: 25k knäckta passwords (SHA1 + salt) ~40 min.

8 Self Signed Certificate: kommer ge varningar i de flesta browsers Kort om https http Secure (http via SSL/TSL) Krypterad dataöverföring mellan klient och server eller mellan två servrar. Om ni skall skicka känslig information över http så bör ni skicka det med https. Om ni vill vara någorlunda säkra på att ni kommunicerar med en specifik entitet så bör ni använda https. Om https: kör hela siten i https, annars har ni potentiellt luckor som gör https meningslöst. Använder sig av certifikat + public key encryption MVC 3: [RequireHttps] (kräver att servern är konfigurerad för det och har verifierade certifikat).

9 Buffer Overflow Inte så mycket av ett webb-problem, men något som alla programmerare bör känna till. Tidigare källa till de flesta exploits. I korthet: Du skriver data efter slutet på en array resulterar i korrupt data eller i värsta fall att din adversary kan exekvera valfritt program. The usual suspects: C, C++, Objective C Ta reda på om buffer overflow är möjligt i språk du programmerar i. Normalt sett ej möjligt i C# (Dock: unsafe/unchecked mode gör buffer overflow möjligt i C#).

10 SQL Injection Definitivt ett Webb-problem Var tidigare den mest utnyttjade sårbarheten på nätet. I korthet: Otillräcklig hantering av input gör att en adversary kommer åt privat info, all info i en databas, kan förstöra data eller i värsta fall exekvera kod. Juli 2012: Användarinfo för 450k Yahoo!- användare dumpas efter en SQL Injection.

11 Script kan injiceras på en sida via kommentarsfält, bilder, banners, querystrings, chat, Web service requests alla typer av input du kan tänka dig. XSS Nuvarande king of the hill när det kommer till utnyttjade sårbarheter på nätet. I korthet: En adversary injicerar någon form av script på sidan som resulterar i att användarinfo för samtliga användare som besöker sidan kan samlas in, account hi-jacking, installationer av trojaner.

12 Kräver normalt att det finns en aktiv session för användaren mot sidan som attackeras och att adversary kan fastställa exakt vilka värden som skall vara med i http Post. CSRF/XSRF En potentiellt väldigt farlig sårbarhet. I korthet en användare luras att gå in på en 3:e parts sida. På sidan exekveras script som gör en post mot vår sida och ändrar data för användaren. Kan få allt från irriterande till enormt kostsamma konsekvenser.

13 Kort om DoS/DDoS Finns flera olika varianter I korthet så går det ut på att skicka så mycket requests till en server att den inte klarar eller hinner svara på normal trafik. DDoS = Distributed DoS, DoS med flera källor I normala fall så innebär det inte att data går förlorad utan endast att resursen inte kan nås under tiden DoSattacken pågår, men beroende på serverkonfiguration och typ av attack så kan det i vissa fall medföra att servern kraschar, vilket i sin tur kan innebära korrupt eller förlorad data. Detta är ingenting vi skyddar oss mot på site-nivå och i praktiken så finns det inga skydd mot välorkestrerade DDoS som samtidigt garanterar att vi kan serva 100% av den normala trafiken.

14 The bad news Jag har gått igenom väldigt primitiva versioner av dessa sårbarheter i verkligheten förfinas attackerna i en rasande takt. Normalt sett så sker inte en attack manuellt som i mina demon. Adversaries använder verktyg som är extremt mycket snabbare och effektivare. Det finns 1000-tals klassificerade sårbarheter av olika slag + ett mörkertal med oklassificerade sårbarheter. I förlängningen möjliggör en sårbarhet ofta andra sårbarheter (T.ex: om du är sårbar för XSS kan du aldrig skydda dig mot XSRF XSS gör att en adversary kan kringå skydd mot XSRF).

15 Till nästa gång Projekt Mån: Repetition.