ASP.Net Security:
Fundamentals
Chapters 1-4
Freeman and Jones Book
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
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
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
Assemblies (cont.)
Assemblies (cont.)
•
•
•
Creating a single file assembly:
– csc /out:abcsingle.dll /target:library a.cs b.cs c.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.netmodule b.netmodule c.netmodule
– The abcmultifile.dll contains the assembly metadata and references to the
module files. (Ref: https://msdn.microsoft.com/en-us/library/226t7yxe(v=vs.110).aspx)
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.
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.
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)
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.
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.
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)
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 of a .Net application
Deploying a .Net application
Executing a .Net application
Monitoring a .Net application