ASP.Net Security: Fundamentals

1. ASP.Net Security: Fundamentals Chapters 1-4 Freeman and Jones Book

2. Managing Trust • Establishing identity (user name, SSN, etc.) • Authentication --- verifies identity • Secrets---e.g., passwords, credit card numbers, etc. ---how and where do we store them? What is their lifetime

3. Assemblies • Assembly is a key component in .Net security • It contains one or more .Net data types compiled into MSIL---code that CLR can execute • It is the basic unit of deployment and versioning. • It is also the basic security boundary

4. Assemblies (cont.) • Assembly consists of: • Assembly metadata --- name, version, culture, strong name, list of all files, type reference information, referenced assemblies, additional information • Type metadata---information on data types contained in the MSIL code of the assembly • MSIL code • Application resources---resources that it uses such as icons etc. • Types of assemblies: • Single-file assembly---all assembly contents are stored in a single file (abc.dll) • Multi-file assembly---contents in more than one file • The assembly metadata and any resources are stored in one file • MSIL code is contained in one or more modules; each module contains one or more data types and any associated type metadata • All files must be deployed together • Each module can contain types written in a different .Net language (One module in C##, one in VB#, etc.) • Library assembly---contains .Net types consumed by other assemblies; can’t be executed) • Executable assembly---can be executed as an application---types here can’t be used by other assemblies • Windows executable assembly---executable assembly for GUI applications

5. Assemblies (cont.)

6. Assemblies (cont.) • Creating a single file assembly: • csc /out:abcsingle.dll /target:librarya.csb.csc.cs • Creating a multifile assembly • csc /out:a.netmodule /target: module a.cs • csc /out:b.netmodule /target: module b.cs • csc /out:c.netmodule /target: module c.cs • Al /out:abcmultifile.dll /target: library a.netmoduleb.netmodulec.netmodule • The abcmultifile.dll contains the assembly metadata and references to the module files. • Shared assemblies: • Assemblies can be private or shared • Each application that uses a private assembly has its own copy; if two applications on the same computer rely on the same private assembly, then there will be two copies of the assembly files installed. • Several applications can use a single instance of a shared assembly.

7. Assemblies (cont.) • .Net Framework also provides GAC or Global Assembly cache---a central repository for shared assemblies. • When an assembly is shared, they use the same disk file. Each application is provided its own copy of the data types contained in the assembly, and no data is shared between the applications.

8. Assemblies (cont.) • Strong Name • Shared assemblies must have a strong name. • Strong name consists of • Assembly name • Version • Culture • Cryptographic public key • Digital signature • Strong name is considered as a unique identifier of an assembly • Useful to ensure that an assembly’s contents are not tampered with. • It is a key feature of code access security (CAS)

9. Assemblies (cont.) • Creating a key pair (public/private key pairs) • Creating an assembly strong name • Verifying a strong name • Publisher certificates • Signcode scheme---to verify the publisher of a piece of code • It requires a software publisher's certificate (SPC) • Strong names and Signcode are complimentary technologies and both can be applied to the same assembly. • Decompiling---to produce source code from an assembly • Obfuscation---technique of altering the MSIL statements so that the application executes in the same way, but the output of a decompiler is unreadable.

10. Application Domains • Application is an isolated domain; hence, its memory or resources can’t be accessed by other applications. • .Net Framework is very different from traditional application environment. • Before loading an assembly, CLR verifies that the assembly contains only type-safe code. • It guarantees that the code does not perform illegal operations, access memory directly, or try to access type members incorrectly. • Since code is type-safe, it allows multiple assemblies to load into a single operating system process. Thus, it is much more efficient to run them, instead of single process for each application domain. • In essence: Application domains are logical containers within the CLR that provide an isolation between type-safe assemblies similar to processes in native applications. • Below, three assemblies have been loaded into application domain 1; one assembly is loaded into application domain 2; no assemblies have been yet loaded into application domain 3.

11. Application Domains (cont.) • CLR is loaded onto the system by the runtime host. Once CLR is loaded, it automatically creates a default application domain. • Types of runtime hosts: • ASP.NET runtime uses a single CLR that runs all ASP.NET web applications; each web application is loaded into a separate application domain. • Internet Explorer uses a single CLR that executes all downloaded controls. An application domain is created for each web site from which controls are downloaded; all controls from the same site run in a single application domain. • Assembly isolation with application domains • Code loaded in one application domain is isolated from code loaded into other application domains. • Unless a reference to a remote domain application is obtained, a code cannot perform an action at the remote application. • Only the creator of an application domain can obtain a reference to a domain; it is not possible for managed code to enumerate the application domains that exists in the CLR. • Application domains and runtime security • Assembly evidence and identity: When an assembly is loaded into an application, user can specify additional evidence to apply to the assembly. CLR uses evidence to determine the permissions to grant to the assembly. • Application domain evidence and identity: User can assign additional evidence when creating an application domain which determines its permissions. • Application domains and security policy--- maps evidence to permissions • Role-based security: the thread that runs an application domain acts on behalf of the application domain (principal)

12. Lifetime of a Secure Application • Designing a secure .Net application • Identifying restricted resources • Functional resources (functionality provided by an application) • External resources (e.g., database) • Subversion resources---resources that are likely to subvert the security---e.g., file that describes security policy enforced by OS • Identifying trust: • Trust can be granted to a wide range of entities, including users, code, external libraries, and different computers. • When an entity is trusted, it is being granted an ability that represents a restricted function resource. • When trust is granted to code or to a class library, then the assembly that contains the assembly is trusted. • Identifying secrets • Consider who owns the data • Consider your legal obligations • Consider the effect of disclosure • Failing gracefully---in the event of a security breach, specify actions to be taken • Developing a scure.Net application • Security testing a .Net application • Deploying a .Net application • Executing a .Net application • Monitoring a .Net application