Säkerhet och .NET

Johan LindforsDeveloper Evangelist

Microsoft AB

Säkerhet och .NET

Vad kommer vi gå igenom?

Funktioner i .NET Framework för säkerhet

Kod och bevisbaserad säkerhet Rollbaserad säkerhet Kryptering Säkra ASP.NET webbapplikationer Säkra ASP.NET webbservices Tips för att skriva säker kod med .NET

Framework

Agenda



Framework

Hanterad exekvering i .NET

..NET Framework basklasser

Trådhantering “COM Marshaler”

Kontroll av datatyper Felhanterare

MSILkompilatorer Kodhanterare Minneshanterare - GC

Säkerhetsmotor “Debugger”

Klassladdare

Ett typsäkert system

“Runtime” övervakar din kod Säkerheten i .NET Framework erbjuder

– Skydd mot buffertöverskrivningar– Ett kodbaserat säkerhetsregelverk

Typsäkra begränsningar i kod– Enbart åtkomst till auktoriserade

minnesplatser– Enbart åtkomst till objekt genom exponerat

gränssnitt “AppDomain” erbjuder

– Ökad prestanda och kodbaserad säkerhet

Verifiering av datatyper gör det svårt att av misstag skriva över skyddat minne

.NET Framework har stöd för…– Den “enklare” klassen “String”– Den kontrollerade “StringBuilder”-klassen

Försiktighet krävs fortfarande– Kod som markerats som “unsafe”– COM och Win32 interoperabilitet

Buffertöverskrivningar

Aritmetiska fel

byte b=0;while (true){ Console.WriteLine (b);

checked{

b++;}

}

Aritmetisk felkontroll genomförs med:– Nyckelordet “checked”– Inställningar för projektet

Guoping Ma

You asked for an example. Here, I've changed this to a sentence case. I've also reworded it so it reads better.

C:\> sn.exe –k MinPrivataOchPublikaNyckel.snk

Ett “strong name” är ett unikt ID som innehåller en publik nyckel

En assembly signeras digitalt med en nyckelfil

Signaturen från ett “strong name” verifieras när applikationen laddas

Fördelar med “Strong name”– Förhindrar påverkan utifrån– Konfirmerar identiteten på den som

publicerat applikationen– Möjliggör helt skilda komponenter sida-vid-

sida

Assemblies och ”Strong Name”

Isolerad lagring

IsolatedStorageFile isoStore = IsolatedStorageFile.GetUserStoreForAssembly();

Erbjuder ett virtuell filssystem inom ett filsystem

Hanterar– Kvoteringar– Separering av filsystem baserat på

identitet på applikationen eller användare Därför kan applikationer och användare

separeras

Agenda



Framework

Bevisbaserad säkerhet

Bevis kontrolleras när en assembly laddas Bevis kan innehålla:

– Information om “strong name”– URL, site och AppDir– Zon– Publicerare (“Authenticode”)– Hash

Bevis kan byggas ut Bevis används av säkerhetssystemet för

att bestämma rättigheterna för en assembly

Regelverk för säkerhet

Koncept Beskrivning

“Policy” - regelverk

Konfigureras av administratörer Kontrolleras vid exekvering Förenklar administration Innehåller rättigheter Innehåller kodgrupper

“Code Groups” - kodgrupper

Grupperar komponenter Bevisbaserat Kopplas samman mot en

uppsättning rättigheter

“Permission Set” - rättigheter

En uppsättning rättigheter

Säkerhetskontroller

Anropsstack

Säkerhetssystemet

MinAssemblyMinAssembly

EnAssemblyEnAssembly

.NET Framework Assembly


Anropar ReadFile

Anropar ReadFile

Tilldela: Execute

1. En assembly begär åtkomsten till en metod i din assembly

2. Din assembly skickar begäran vidare till en assembly i .NET Framework

3. Säkerhetssystemet gör en “demand” genom hela anropsstacken

4. Säkerhetssystemet ger åtkomst eller “kastar ett fel”

Tilldela: ReadFileTilldela: ReadFile

Tilldela: ReadFile

“Permission Demand”

Ge åtkomst?Ge åtkomst?“Security exception” Ingen åtkomst

“Security exception” Ingen åtkomst

FileIOPermission filePerm = new FileIOPermission( FileIOPermissionAccess.Read, "C:\\temp.txt");try{ filePerm.Demand(); // Kod för att jobba mot filen här}Catch (SecurityException e){ // detta exekverar om åtkomsten vägras}

Imperativa kontroller

Mer granulärt än deklarativt

[FileIOPermission(SecurityAction.Demand, Read="C:\\temp.txt")]public string ReadTempFile(){ // Kod för att läsa filen här}

Deklarativa kontroller

Använd attribut för att genomföra säkerhetskontroller

Fel genererar “SecurityException” Deklarativ säkerhet lagras som

metadata, vilket ger:– Enklare genomgångar av kod– Konfiguration vid exekvering (CASPOL)

Assert

En “Assert” förhindrar “stack walk” Användbart när:

– Kod behöver åtkomst till en skyddad resurs, men åtkomsten är helt gömd från användarna

– Kod behöver anropa ohanterad kod för att utföra en väldefinerad funktion, använd en kombination av “Demand” och “Assert”

Använd bara när det är absolut nödvändigt!– Se till att din kod inte kan användas av

otillåtna applikationer och användare

Assert påverkar “StackWalk”

Anropsstack

Säkerhetssystemet

MinAssemblyMinAssembly

EnAssemblyEnAssembly



Anropar ReadFile

Anropar ReadFile

Tilldela: ReadFileTilldela: ReadFile

Assert: ReadFile

“Permission Demand”

Ge åtkomst?Ge åtkomst?

Var försiktig dock!– Kräver rättigheten -

Assert– Kräver rättigheten som

görs Assert på

Utvecklaren lägger till önskade rättigheter till en assembly med hjälp av attribut

3 typer av begäran:

Ger en mekanism som:– Får en assembly att själv tala om

rättighetskrav

– Förenklar utrullning av assemblies

– Förhindrar att en assembly laddas om inte dess krav är uppfyllda

“Permission Requests”

Minimum “Optional” “Refused”

// Jag kommer bara att köra om jag får anropa ohanterad kod[assembly:SecurityPermission( SecurityAction.RequestMinimum, UnmanagedCode=true)]

// Jag måste ha rättigheter som i “FullTrust PermissionSet” [assembly:PermissionSet( SecurityAction.RequestMinimum, Name="FullTrust")]

// Bara kod som signerats med 12789ADE...kan anropa mig[StrongNameIdentityPermission(SecurityAction.LinkDemand PublicKey = "12789ADE…", Version = "1.0.0.0")]public class MyClass{ // MyClass can only be called by the assembly // with the strong name specified in the attribute}

”Permission Requests”

<location allowOverride="true"> <system.web> <securityPolicy> <trustLevel name="Full" policyFile="internal"/> <trustLevel name="High" policyFile="web_hightrust.config"/> <trustLevel name="Medium" policyFile="web_mediumtrust.config"/> <trustLevel name="Low" policyFile="web_lowtrust.config"/> <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/> </securityPolicy>  <trust level=“Full" originUrl=""/> </system.web></location>

Machine.config

Applikationer med ”Partial Trust”

Webbapplikationer har “full trust” innan .NET Framework 1.1

.NET Framework 1.1 ger ASP.NET nivåer– Begränsa åtkomsten till resurser för

ASP.NET

Webbapp med“Partial

Trust”

Wrapper Assembly

(“Strong Name” och i GAC)

Säker resurs

“Sandboxad” kod

<trust level_”Medium”originUri_--/>

Demand och Assert

Åtkomst till resurs

Priviligerad kod i “sandlådor”

Inkapsla priviligerad kod i en wrapper Gör “assert” på relevanta rättigheter Installera wrappern i GAC Använd

“AllowPartiallyTrustedCallersAttribute”

Agenda



Framework

Autentisering och auktorisering

Autentisering– Vem är du?– Är jag säker på att du är den du säger?

Auktorisering– Har du tillstånd att…?

Rollbaserad säkerhet i .NET Framework berör mest auktorisering

Identiteter och “principals”

Generisk Windows Skräddarsydd

En identitet innehåller information om en användare, till exempel inloggningsnamn

En “principal” innehåller rollinformation om en användare eller dator

WindowsIdentity myIdent = WindowsIdentity.GetCurrent();WindowsPrincipal myPrin = new WindowsPrincipal(myIdent);

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);

WindowsPrincipal myPrin = System.Threading.Thread.CurrentPrincipal;

Identiteter och Windows

Använd objekten WindowsIdentity och WindowsPrincipal för:– En enstaka validering

– Repeterad validering

GenericIdentity myIdent = new GenericIdentity("User1");string[] roles = {"Manager", "Teller"};GenericPrincipal myPrin = new GenericPrincipal(myIdent, roles);

System.Threading.Thread.CurrentPrincipal = myPrin;

Generiska identiteter

Skapa “GenericIdentity” och “GenericPrincipal”

Lägg “GenericPrincipal” till den aktuella tråden

“GenericPrincipal” kommer att användas vid framtida säkerhetskontroller på tråden

Rollbaserade kontroller (1/2)

if (String.Compare(myPrin.Identity.Name, "DOMÄN\\Johan", true)==0){ // Få åtkomst till koden}

if (myPrin.IsInRole("BUILTIN\\Administrators")){ // Få åtkomst till koden}

Du kan använda egenskapen “Name” på “ID” objektet för att kontrollera inloggningsnamn

Använd metoden “IsInRole” på “Principal” för att kontrollera medlemskap i roller

Rollbaserade kontroller (2/2)

PrincipalPermission prinPerm = new PrincipalPermission("Teller", “Manager”, true);

try{ prinPerm.Demand(); // Matchar ovanstående aktiv “principal”}

[PrincipalPermission(SecurityAction.Demand, Role="Teller", Authenticated=true)]

Använd rättigheter för att kontrollera rollbaserade säkerhetskontroller– Imperativt

– Deklarativt

Agenda



Framework

Krypteringsgenomgång

.NET Framework har klasser som implementerar dessa operationer

Krypotgrafisk term Beskrivning

Symmetriskkryptering

Kryptera och dekryptera data med en hemlig gemensam nyckel

Asymmetrisk kryptering

Kryptera och dekryptera data med ett privat/publikt nyckelpar

Hashning Mappa en lång sträng av data till en

kort sträng med fixerad längd

Digital signatur Hasha data och kryptera resultatet

med en privat nyckel

Använd symmetrisk kryptering

Välj algoritm– TripleDESCryptoServiceProvider– RijndaelManaged

Generera en hemlig nyckel Använd samma nyckel för kryptering

och dekryptering– “FileStream”– “MemoryStream”– “NetworkStream”

Asymmetrisk kryptering

Välj krypteringsalgoritm– RSACryptoServiceProvider– DSACryptoServiceProvider

Generera ett nyckelpar Kryptera eller dekryptera

Signering av data

Att signera data förhindrar påverkan och säkerställer identiteten på den som signerat

För att signera data– “Hasha” informationen

– Kryptera resultatet med privat nyckel

För att verifiera den digitala signaturen:– Dekryptera signaturen med den publika

nyckeln

– Hasha informationen och jämför resultat

Agenda



Framework

Autentisering med ASP.NET

Metod Fördelar Nackdelar

Windowsbaserad

Använder den existerande infrastrukturen i WindowsKontrollerar åtkomsten till känslig information

Inte lämpat för de flesta Internet-applikationerna

Formulärbaserad

Bra för Internet-applikationerStödjer alla klienttyper

Baseras på “cookies”

Microsoft Passport

En login för många applikationer på InternetInget behov av att hantera en databas med information om användareGer utvecklare möjligheten att skräddarsy utseendet på registreringssidan

Baseras på “cookies”Eventuella avgifter

Klienten begär sida

Autentisering i ASP.NET

Auktoriserad

Inte autentiserad Autentiserad

Inloggningssida(Användaren matar in uppgifter)

Autentiserad

“Cookie”

Auktoriserad

Inte autentiserad

Ingen åtkomst

Begärd sida

Formulärbaserad autentisering

<system.web><authentication mode="Forms">

<forms loginUrl="login.aspx"/></authentication>

<authorization> <deny users="?"/></authorization>

</system.web>

Konfigurera

Konfigurera IIS för anonym autentisering

Slå på autentisering i web.config Sätt auktorisering Bygg en inloggningssida

<authentication mode="Forms"><forms loginUrl="login.aspx"

protection="All" requireSSL="true"timeout="10"name="AppNameCookie" path="/FormsAuth"

slidingExpiration="true"</forms>

</authentication>

Ytterligare förstärkningar

Säkra “cookies”

Nycklar specifika per applikation– <machineKey

validationKey="AutoGenerate,IsolateApps">– Används för att generera unika nycklar för varje

applikation

Validering av inmatning

Fel!

KlientServer

Användarenmatar in data

Valid inmatning?

Webbapplikationenprocesserar…

Ja

Nej

Valid inmatning?

Ja

Nej

Validering på klienten– Beror på version av webbläsare– Ger återkoppling omedelbart– Minskar antalet “postbacks”

Validering på servern– Repeterar all validering från

klienten– Kan validera mot lagrad

information

Valideringskontroller

Validering på klienten (“EnableClientScript”)

Validering på servern– “ControlToValidate” – “ErrorMessage”

Agenda



Framework

Säkra webbservices

Tre huvudsakliga modeller för att konfigurera säkerheten för XML Web Services:– På plattformsnivå (IPSEC, SSL) – På applikationsnivå (ACL, IP begränsningar)– På meddelandenivån (WSE)

Standarder för att stödja integritet och konfidentialitet på meddelandenivån:– XML Signatures– XML Encryption

Säkerhet på plattformsnivån

Klient

Transport

Service

TransportSäker transport

XML XML

Plattform och transport erbjuder

säkerhetAutentisering av

anroparen

Integritet på meddelande

Skyddat innehåll

Säkerhet på transportnivå erbjuds av plattformen.

T.ex. Windows använder Kerberos

Säkerhet på meddelandenivånXML meddelandet

innehåller säkerhetsinformatio

nUppgifter för säkerhet

Digitala signaturer

Meddelanden kan krypteras

Klient

Transport

Service

TransportVilken transport som helst

XML

XML XML

XMLSäkerheten äroberoende av

transportprotokoll

“XML Signature”

En standardiserad XML syntax för att representera en digital signatur

Verifierar om ett meddelande ändrats under överföring

Signerar specifika delar av XML dokumentet eller meddelandet

Implementerat i .NET Framework– System.Security.Cryptography.Xml

“XML Encryption”

En standardiserad XML syntax för att definera information för kryptering

Kryptera utvalda delar av ett XML dokument eller meddelande

Stödjer både symmetriska och asymmetriska algoritmer

Inte inbyggt i senaste versionen av .NET Framework, men du kan skapa själv med:– System.Security.Cryptography– System.XML– System.IO.MemoryStream

Microsofts implementation av WS-Security:– Autentisering med SOAP huvuden– Kryptering av meddelanden– Signering av meddelanden

Implementerat i Microsoft.Web.Services.dll

Har också stöd för vidarehänvisning och tillägg

WSE

Agenda



Framework

Tips för säker kod (1 av 4 )

Validera all användarinmatning– Håll uppsikt på data med mer än ett

grundformat– Glöm inte “SQL injection”

Hantera känsligt data ansvarsfullt– Ta hänsyn till “reflection”– Använd attributet “NonSerializable” – Kryptera alla lagrade lösenord– Använd Dotfuscator


Kodbaserad säkerhet– Använd “permission requests” på assemblies

för att minska din exponering– Undersök noggrant explicita rättigheter– Använd “Assert” när det är absolut

nödvändigt– Anropa alltid “RevertAssert”

PInvoke och COM interoperabilitet– Använd “safe-native-unsafe” namngivning– Begär rättigheten att få exekvera ohanterad

kod– Använd “sandboxing” mot ohanterade API-

anrop


Använd funktioner i språken– private, protected, internal– readonly– sealed– LinkDemand, InheritenceDemand

Signera alla komponenter digitalt Använd FxCop

Tips för säker kod (4 av 4)

Konfiguration på din produktionsserver– <customErrors mode=”[RemoteOnly]/[On]”/>– <compilation debug=”false”/>– <trace enabled="false"/>– Glöm inte heller eventuella <%@ trace %>

i .aspx Delade servers

– <location allowOverride=”false”/> Isolera applikationer

– Med processer i Internet Information Server 6.0– Med nivåer i <trust>

Hantera och logga fel som uppstår

Sammanfattning



Framework

Kontrollskott

Vilket nyckelord kan användas för aritmetisk felhantering?– Svar:

Vad står WSE för?– Svar:

Hur många bevis finns implementerade i .NET Framework vid installation?– Svar:

Nästa steg

Workshops och labbar– Nexus Technology AB

Kurser– Cornerstone– Jönsson & Lepp

Skaffa information– MSDN Subscription

http://www.microsoft.se/msdn/security

Documents

Säkerhet och .NET