Fredrik Hesse Säkerhetskonsult Nexus Technology AB Att skriva säker kod – del 1.

En presentation över ämnet: "Fredrik Hesse Säkerhetskonsult Nexus Technology AB Att skriva säker kod – del 1."— Presentationens avskrift:

1 Fredrik Hesse Säkerhetskonsult Nexus Technology AB Att skriva säker kod – del 1

2 Vad kommer vi gå igenom  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

3 Vad kommer vi gå igenom  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

4 Behovet av säker kod US port 'hit by UK hacker‘ “ ” “Several corporations said they lost $10 million in a single break-in” “Up to 1,500 websites could have been affected by a recent hack attack” ” “Piracy cost more than 4,300 jobs and $850 million in damage” ” “Sobig virus accounted for $30 billion worth of economic damages worldwide” “Attacks will cost the world economy a whopping $1.6 trillion (US$) this year”

5 Hotfulla scenarios  Anställda kopplar upp sig till företagets nätverk –Via TP, trådlöst, uppringda förbindelser eller VPN –Företagsdatorer, hem-PC  Anställda kopplar upp sig till andra nätverk –“HotSpots” på internet, partners, bredband  Partners kopplar upp sig till företagets nätverk –Lokal och/eller gemensam autentisering –Anonyma gäster  Nya scenarier och hot

6 Vad vill vi skydda oss emot?  Internet är grogrunden för: –Tjuvar –Bedragare –Vandaler –Kriminella –Hackers  Du borde inte vara förvånad över att attacker förekommer!

7 Vanliga attacker Tappad uppkoppling Organisations- attacker Skyddad data Säkerhetsintrång av misstag Automatiserade attacker Hackers Virus, trojaner, maskar “Denial of Service” (DoS) DoS

8 Vad kommer vi gå igenom  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

9  Existerar primärt i ohanterad kod (C/C++)  Data överskrider förväntad storlek  Fyra vanliga typer: –Stackbaserade buffertöverskrivningar –Heap-baserade överskrivningar –Funktionspekare i “V-table” –Felhantering  Kan utnyttjas av maskar –Robert Morris mask och CodeRed Vad är en buffertöverskrivning?

10 void UnSafeMethod(const char* uncheckedData) { int anotherLocalVariable; strcpy (localVariable, uncheckedData); } char localVariable[4]; Överst på stacken int char[4] returadress Exempel på buffertöverskrivning

11 “Heap” överskrivningar Data Pekare Data Pekare strcpy xxxxxxx xxxxxxx  Skriver över data som lagrats på “heapen” –Stackbaserad överskrivning skriver över adresser i stacken  Svårare att utnyttja –En hacker måste lära sig om en funktionspekare är lagrad nära en inmatningsbuffert

12 Skydd mot buffertöverskrivningar (1/2)  Var försiktig när du använder: –strcpy –strncpy –memcpy  Använd flaggan /GS vid kompilering i Visual C++ för att identifiera överskrivningar –/GS valet är inte en ersättning för försiktig och noggrann programmering  Används strsafe.h för säker bufferthantering

13 Skydd mot buffertöverskrivningar (2/2)  Kontrollera alla vektorindex –Använd med fördel “wrapper”-klasser –Kan innehålla inbyggt skydd  Kontrollera längden på sökvägar till filer –_MAX_PATH (men var observant)  Skriv inte egna algoritmer för att dela filer –Använd splitpath eller någon liknande  Optimalt är att använda hanterad kod –Men glöm inte bort PInvoke/COM interoperabilitet samt kod som markerats som “unsafe”

14 Vad kommer vi gå igenom  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

15 Aritmetiska fel  Aritmetiska fel –Uppstår när begränsningarna för en variabel överskrids –Underskattas och förkastas ofta –Kan leda till allvarliga fel vid exekvering  Exempel på aritmetiska fel inkluderar –“Overflow” –“Underflow”

16 int Concat(char *buf1, char *buf2, size_t len1, size_t len2){ char buf[256]; if((len1 + len2) > 256) return -1; memcpy(buf, buf1, len1); memcpy(buf + len1, buf2, len2);... }  Hur stor är en size_t?  Är en size_t teckenbestämd?  Vad händer om: len1 == 0xFFFFFFFE len2 == 0x00000102 Exempel på aritmetiska fel

17 Skydd mot aritmetiska fel  För att förhindra aritmetiska fel: –Var medveten om begränsningarna på de datatyper som du använder –Skriv defensiv kod, kontrollera efter “overflows” –Överväg att skriva säkra funktioner som kan återanvändas Till exempel: SafeAdd –Överväg att skapa en säker “template”-klass om du använder C++ Till exempel: class SafeInt

18 if (A + B > MAX) return -1; // Kontrollera fel if (A + B >= A && A + B < MAX) { // coolt! } eller // Skapa egna säkra funktioner if UAdd(A,B,&R) { // coolt, resultatet i R } eller // dleblanc (SafeInt.hpp) SafeInt A = 0x5000; SafeInt B = 0xffff; if (A + B < MAX) { } Skydd mot aritmetiska fel

19 Vad kommer vi gå igenom  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

20 Vad är “Cross-Site Scripting”?  XSS ger hackers möjligheten att exekvera skadliga skript i en klients webbläsare  Vilken webbsida som helst som renderar HTML och innehåller inmatning från användare är sårbar  Hackers kan föra in,, och taggar  Hackers kan potentiellt stjäla information om sessioner och autentiserings-cookies och då få tillgång till den lokala klientens dator

21 Två vanliga användningsområden  Attackera webbaserade plattformar för epost och diskussionsgrupper –Hackern för in HTML-taggar i meddelanden och poster i diskussionsgrupper  Använda HTML -taggar för att skicka privat information vidare –Hackern lägger till HTML -taggar i hyperlänkar som går till en legitim webbsida. Attributet “Action” på -taggen leder till hackerns webbsida och privat information kan skickas dit.

22 XSS exempel Aktörerna Bosse, vår hacker Maria, en vanlig användare

23 Response.Write(“Välkommen " & Request.QueryString("UserName")) Formulärbaserade attacker (1/2)

24 idForm.cookie.value=document.cookie; idForm.submit(); > here Formulärbaserade attacker (2/2)

25 Skydd mot XSS (1/2)  Lita inte på inmatning från användare –Validera all data som ges av användare –Var extra noggrann med data som innehåller eller  Eka inte blint tillbaka inmatning från webben –Eka bara när det behövs –Validera data innan du ekar  Lagra inte känslig information i “cookies” –Relativt enkelt för hackers att ta en “cookie”

26 Skydd mot XSS (2/2)  Använd valet HttpOnly för cookies –Hindrar åtkomst från skript på klientsidan  Använd säkerhetsattributet i –Stödjer zon inställningar i Internet Explorer  Definera en explicit teckenuppsättning för sidan  Använd funktioner i ASP.NET –Använd “validateRequest” för att testa taggar –Använd “HTMLEncode” och “URLEncode” för att filtrera det som skrivs tillbaka

27 Vad kommer vi gå igenom  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

28 Vad är “SQL Injection”?  “SQL injection” uppkommer när användare kontrollerar kriterier i SQL-program och hackers matar in värden som förändrar det asviktliga syftet med programmet  Fyra vanliga exempel på “SQL Injection”: –Utforska databaser –Kringgå auktorisering –Exekvera flera SQL-program –Anropa inbyggda lagrade procedurer

29 string Status = "No"; string sqlstring =""; try { SqlConnection sql= new SqlConnection( @"data source=localhost; user id=sa;password=password;"); sql.Open(); sqlstring="SELECT HasShipped" + " FROM detail WHERE ID='" + Id + "'"; SqlCommand cmd = new SqlCommand(sqlstring,sql); if ((int)cmd.ExecuteScalar() != 0) Status = "Yes"; } catch (SqlException se) { Status = sqlstring + " failed\n\r"; foreach (SqlError e in se.Errors) { Status += e.Message + "\n\r"; } } catch (Exception e) { Status = e.ToString(); } “SQL Injection” i C#

30 Dim Status As String = "No" Dim sqlstring As String Try Dim sql As New SqlConnection( _ "data source=localhost; user id=sa;password=password") sqlstring = "SELECT HasShipped FROM detail WHERE ID='“ + Id + "'" sql.Open() Dim cmd As New SqlCommand(sqlstring, sql) If cmd.ExecuteScalar() <> 0 Then Status = "Yes" End If Catch se As SqlException Status = sqlstring + " failed” + System.Environment.NewLine For i As Integer = 0 To se.Errors.Count - 1 Status += se.Errors(i).Message + System.Environment.NewLine Next Catch e As Exception Status = e.ToString() End Try “SQL Injection” i VB.NET

31 SELECT HasShipped FROM detail WHERE ID= '1001' SELECT HasShipped FROM detail WHERE ID= '1001' or 1=1 -- ' En bussig en skriver 1001 En mindre bussig en skriver 1001’ or 1=1 - - Hur används ”SQL Injection”? (1/3)

32 SELECT HasShipped FROM detail WHERE ID= '1001' drop table orders -- ' SELECT HasShipped FROM detail WHERE ID= '1001' exec xp_cmdshell('fdisk.exe') -- ' En riktigt elak en skriver 1001' drop table orders -- En person vid namn “ondskan” skriver 1001' exec xp_cmdshell(‘fdisk.exe’) -- Om en server är nere i 5 timmar Och vi har normalt 200 transaktioner i timmen Varje transaktion är på 300 kronor 300 000 i förlorade intäkter Hur används ”SQL Injection”? (2/3)

33 Hur används ”SQL Injection”? (3/3)  SQL Injection och DoS ALFKI’; exec master..xp_cmdshell ’ipconfig /release SELECT * FROM customers WHERE ID= 'ALFKI’; exec master..xp_cmdshell ’ipconfig /release' SELECT * FROM customers WHERE ID = ‘" & customerSearch & “ ‘ "

34 Skydd mot “SQL Injection”  Validera och sanera ALL inmatning –Anta att inmatning är ond tills motsatsen bevisats –Leta efter korrekt data och förkasta allt annat –Fundera på att använda reguljära uttryck  Exekvera med så lite rättigheter som möjligt –Exekvera aldrig som ‘sa’ –Begränsa åtkomsten till lagrade procedurer  Favorisera “SQL parameterized queries” –Bygg inte program med ihopfogning av strängar  Skicka inte tillbaka meddelanden från ODBC

35 SqlDataAdapter myCommand = new SqlDataAdapter("SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn); SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); parm.Value = Login.Text;  Bygg en parameteriserad fråga i C#  Bygg en parameteriserad fråga i VB Dim myCommand As New SqlDataAdapter("SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn) Dim parm As SqlParameter = myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11) parm.Value = Login.Text Skydd mot “SQL Injection”

36 Vad kommer vi gå igenom  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

37 “Canonicalization”  Det finns fler än ett sätt att namnge saker  Alternativa representationer finns för: –Filnamn –URL:er  Hackers kan utnyttja kod där beslut baserats på filnamn eller URL:er

38 1. MinStoraFil.txt 2. MinStoraFil.txt. 3. MinSto~1.txt 4. MinStoraFil.txt::$DATA “Canonicalization”

39 http://www.microsoft.com/technet/security Är det samma som.: http://www%2emicrosoft%2ecom%2ftechnet%2fsecurity http://www.microsoft.com%c0%aftechnet%c0%afsecurity http://www%25%32%65microsoft.com/technet/security http://172.43.122.12 = http://2888530444 “Canonicalization”  Det finns många sätt att representera tecken på Internet

40 Skydd mot “Canonicalization”  Basera aldrig beslut på namn –Det finns ett antal sätt att beskriva sökvägar och URL’er –Chansen finns att du gör fel  Använd säkerheten i filsystemet –Begränsa åtkomst till privat data  Slå av “Parent Paths” i IIS

41 Vad kommer vi gå igenom  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

42  Saker som kan bli fel –Att skapa en egen –Svaga algoritmer –Felaktigheter i krypteringsalgoritmer –Säkerheten på nyckeln –Livslängden på nyckeln –Den mänskliga faktorn Svagheter vid kryptering Nyckel KlartextKryptotext Algoritm Jag behöver tre av ovanstående för att ta ditt data!

43  Om det går, använd DPAPI för att slippa hantera nycklar  Om nyckelhantering krävs –Byt nycklar regelbundet, återanvänd inte! –Använd ACL:er för att begränsa åtkomst –Använd större nycklar för ökad säkerhet  Implementera INTE dina egna kryptografiska rutiner Kryptografiska hackningsförsök

44 Vad kommer vi gå igenom  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

45 Utmaningar med Unicode  Vanliga misstag –Behandla ett Unicode-tecken som en enstaka byte –Felberäkning av behövd storlek på bufferts –Missanvändning av MultiByteToWideChar –Validering innan konvertering Alla tecken i Unicode kan inte översättas till ASCII  Resultat –Buffertöverskrivningar –Potentiellt farliga teckensekvenser kommer igenom nätet

46  Beräkna storlek på buffert med sizeof(WCHAR)  Glöm inte GB18030 (4 bytes per tecken)  Konvertera från Unicode till ASCII och validera efteråt  Använd IsNLSDefinedString vid validering  Använd MultiByteToWideChar korrekt –Erbjud en tillräckligt stor buffert Skydd mot utmaningar i Unicode

47 Vad kommer vi gå igenom  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

48  Brist i applikationen eller operativsystem  CPU brist (“svält”)  Minnesbrist  Resursbrist  Nätverksbrist “Denial of Service” attacker

49 Skydda mot DOS-attacker  Designa dina applikationer att vara säkra från första dagen –Ha eventuella planer på plats direkt  Lita inte på användarinmatning  Hantera fel intelligent –Fånga fel –(Try-Catch-Finally)  Gör säkerhetstester  Förvänta det oförväntade

50 Sammanfattning  Behovet av säker kod  Hur skyddar vi oss mot: –Minnesutmaningar –Aritmetiska fel –“Cross-site Scripting” –“SQL Injection” –“Canonicalization” utmaningar –Svagheter vid kryptering –Utmaningar med Unicode –“Denial of Service” attacker

51 Kontrollskott  Vilken flagga används i VS.NET för att skydda mot buffertöverskrivningar? –Svar:  Vem drabbas av XSS? –Svar:  Hur många har skrivit egna krypteringsalgoritmer? –Svar:

52 Nästa presentation  Att skriva säker kod –Rekommendationer och riktlinjer

53