Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 2004 Deloitte & Touche LLP and affiliated entities..NET Security Mechanisms Tim Cassidy MSc. CISSP.

Similar presentations


Presentation on theme: "© 2004 Deloitte & Touche LLP and affiliated entities..NET Security Mechanisms Tim Cassidy MSc. CISSP."— Presentation transcript:

1 © 2004 Deloitte & Touche LLP and affiliated entities..NET Security Mechanisms Tim Cassidy MSc. CISSP

2 © 2004 Deloitte & Touche LLP and affiliated entities.Agenda 1.Importance of Secure Applications 2.Security Policy 3.Code Access Security (CAS) and Role Based Security 4.Stack Walk or Walking the Stack 5.Permissions 6.Security Actions and Permissions 1.Security Action Demands 2.Security Action Overrides or Stack Walk Modifiers (Deny, PermitOnly and Assert) 3.Security Action Requests (minimum, optional and refusing) 7.Isolated Storage 8.Guarantee of Assembly Integrity 9.Impersonating a Windows User 10.ASP.NET - How to Securely Store Credentials for Fixed Account 11.Cryptography 12..Net Security Tool – FXCop 13.Security Services Group 14.Questions and Share Experiences – good, bad and/or ugly

3 © 2004 Deloitte & Touche LLP and affiliated entities. Importance of Secure Applications  Piracy costs more than 4,300 jobs and $850 million in damage  Attacks will cost the world economy a whopping $1.6 trillion (US) this year  Sobig virus accounted for $30 billion worth of economic damages worldwide  Personal Experience “SQL Injection is irrelevant – all our servers have been hardened against the red book” “SQL Injection is irrelevant – all our servers have been hardened against the red book”

4 © 2004 Deloitte & Touche LLP and affiliated entities. Security Policy  Security Policy + Assembly Evidence = Grant Set  Assembly Evidence – unique identification of Assembly Identity Permission Identity Permission  Grant Set – permissions granted to Assembly  Security Policy can be administered at the following levels: Enterprise Policy Level Enterprise Policy Level Machine Policy Level Machine Policy Level User Policy Level User Policy Level Application Domain Policy Level Application Domain Policy Level  The first three can be configured using: Command-line caspol.exe application (Code Access Security Policy tool) or Command-line caspol.exe application (Code Access Security Policy tool) or the GUI application mscorcfg.msc (.NET Framework Configuration tool) the GUI application mscorcfg.msc (.NET Framework Configuration tool)  See “PsychImage” application

5 © 2004 Deloitte & Touche LLP and affiliated entities. Code Access Security (CAS) and Role Based Security  Code Access Security AKA Evidence-Based Security AKA Evidence-Based Security Access based on identity of code Access based on identity of code  Role Based Security Access based on identity of user Access based on identity of user Comprised mainly of Principals and Identity Comprised mainly of Principals and Identity  Code can have permissions independent of the person executing the code  Code cannot exceed the permissions of the person executing it.Net CAS is just another layer on top of OS security.Net CAS is just another layer on top of OS security  See.Net Code Access Security I and.Net Code Access Security II.Net Code Access Security I.Net Code Access Security II.Net Code Access Security I.Net Code Access Security II

6 © 2004 Deloitte & Touche LLP and affiliated entities. Stack Walk or Walking the Stack

7 © 2004 Deloitte & Touche LLP and affiliated entities.Permissions  The.Net framework supports three different types of permissions: Identity Permission (Assembly Evidence) Identity Permission (Assembly Evidence) PublisherIdentityPermission, SiteIdentityPermission, StrongNameIdentityPermissionPublisherIdentityPermission, SiteIdentityPermission, StrongNameIdentityPermission Code Access Permission Code Access Permission FileIOPermission, WebPermission, UIPermissionFileIOPermission, WebPermission, UIPermission Role Based Security Permission Role Based Security Permission The PrincipalPermission class represents the identity and role that a particular principal class must have to runThe PrincipalPermission class represents the identity and role that a particular principal class must have to run

8 © 2004 Deloitte & Touche LLP and affiliated entities. Security Actions and Permissions Security Actions represent the actions that can be taken on permissions and include:  Demands: Demand Demand LinkDemand (only declarative) LinkDemand (only declarative) InheritanceDemand (only declarative) InheritanceDemand (only declarative)  Modifiers/Overrides: Assert Assert Deny Deny PermitOnly PermitOnly  Requests RequestMinimum (only declarative) RequestMinimum (only declarative) RequestOptional (only declarative) RequestOptional (only declarative) RequestRefuse (only declarative) RequestRefuse (only declarative) For another categorization of Security Actions – see Categorization of Security Actions By Function/Use Categorization of Security Actions By Function/Use Categorization of Security Actions By Function/Use

9 © 2004 Deloitte & Touche LLP and affiliated entities. Security Action Demands  Demand Simply creates a demand for a particular permission Simply creates a demand for a particular permission For an example of how to enforce permissions based on the name and role of a user see Example of Role Based Permissions For an example of how to enforce permissions based on the name and role of a user see Example of Role Based PermissionsExample of Role Based PermissionsExample of Role Based Permissions For more information – see Declarative and Imperative Security StatementsFor more information – see Declarative and Imperative Security StatementsDeclarative and Imperative Security StatementsDeclarative and Imperative Security Statements See “ExcelFrontEnd” applicationSee “ExcelFrontEnd” application  LinkDemand Only checks the immediate caller (direct caller) of your code. Only checks the immediate caller (direct caller) of your code. Stack walk isn’t performed Stack walk isn’t performed Linking occurs when your code is bound to a type reference, including function pointer references and method calls. Linking occurs when your code is bound to a type reference, including function pointer references and method calls. A link demand can only be applied declaratively. A link demand can only be applied declaratively. See Example of LinkDemand See Example of LinkDemandExample of LinkDemandExample of LinkDemand  InheritanceDemand Inheritance demands can be applied to classes or methods. Inheritance demands can be applied to classes or methods. If it is applied to a class, then all the classes that derive from this class must have the specified permission. If it is applied to a class, then all the classes that derive from this class must have the specified permission. If it is applied to a method, then all the classes that derive from this class must have the specified permission to override that method. If it is applied to a method, then all the classes that derive from this class must have the specified permission to override that method. See Example of InheritanceDemand See Example of InheritanceDemandExample of InheritanceDemandExample of InheritanceDemand

10 © 2004 Deloitte & Touche LLP and affiliated entities. Security Action Overrides or Stack Walk Modifiers I  Deny A call to the Deny method fails any stack walk that reaches it with a matching permission A call to the Deny method fails any stack walk that reaches it with a matching permission Deny method can be used to constrain the capabilities of non-trusted code Deny method can be used to constrain the capabilities of non-trusted code See Example of Security Action Override: Deny See Example of Security Action Override: DenyExample of Security Action Override: DenyExample of Security Action Override: Deny See “TestAssertDenyApplication” application See “TestAssertDenyApplication” application  PermitOnly A call to the PermitOnly method fails any unmatching stack walk A call to the PermitOnly method fails any unmatching stack walk Can be used to constrain the actions of some non- trusted code that you may call Can be used to constrain the actions of some non- trusted code that you may call See Example of PermitOnly See Example of PermitOnlyExample of PermitOnlyExample of PermitOnly

11 © 2004 Deloitte & Touche LLP and affiliated entities. Security Action Overrides or Stack Walk Modifiers II  Assert Sandbox Privileged Code - a call to the Assert method causes the stack walk for a matching permission to stop at the site of the Assert call Sandbox Privileged Code - a call to the Assert method causes the stack walk for a matching permission to stop at the site of the Assert call Assert is used in the following scenario: Assert is used in the following scenario: Your code has permissions to do somethingYour code has permissions to do something The calling assembly does notThe calling assembly does not You want to prevent the stack walk into their assembly where the demand will failYou want to prevent the stack walk into their assembly where the demand will fail This allows code in the trusted assembly to do things that the program as a whole may not be able to doThis allows code in the trusted assembly to do things that the program as a whole may not be able to do Unfortunately this can be misused to allow malicious applications enhanced access Unfortunately this can be misused to allow malicious applications enhanced access Untrusted callers can also be granted access to fully trusted assemblies through AllowPartiallyTrustedCallersAttribute Untrusted callers can also be granted access to fully trusted assemblies through AllowPartiallyTrustedCallersAttribute AllowPartiallyTrustedCallersAttribute

12 © 2004 Deloitte & Touche LLP and affiliated entities. Security Action Requests: Requesting Minimum Permissions  Based on the premise that it is better for an application not to run than to start and crash because of insufficient permissions, CAS allows assemblies to include minimum permission requests  Example of Request Minimum Declarative Statement Example of Request Minimum Declarative Statement Example of Request Minimum Declarative Statement

13 © 2004 Deloitte & Touche LLP and affiliated entities. Security Action Requests: Requesting Optional Permissions  Over and above core functionality, some applications offer additional but nonessential features  CAS allows assemblies to specify in their metadata a set of permissions that is useful for the assembly to have  Example of Request Optional Declarative Statement Example of Request Optional Declarative Statement Example of Request Optional Declarative Statement

14 © 2004 Deloitte & Touche LLP and affiliated entities. Security Action Requests: Refusing Permissions  CAS allows an assembly to specify a set of permissions in its metadata that the runtime must never grant it.  Even if policy resolution normally results in the granting of a permission, the runtime will remove it when it loads the assembly.  This allows the developer to ensure that nobody can use the code to perform any action controlled by the refused permissions.  Example of Request Refuse Declarative Statement Example of Request Refuse Declarative Statement Example of Request Refuse Declarative Statement

15 © 2004 Deloitte & Touche LLP and affiliated entities. Isolated Storage  Safe storage area on the hard disk where managed code can store noncritical data  Code cannot access other code’s data and to limit the space used by each application  Assemblies from low-trust zones can use this special storage space to persist their settings and other information to the local hard disk  See Technical Details of Isolated Storage Technical Details of Isolated StorageTechnical Details of Isolated Storage  Assemblies can never get the exact absolute or relative path of the file stored on the disk making it very safe  The store is not only unique to the user, but also unique to the application  Data is persistent and will remain between sessions  Primary purpose of isolated storage is to store small amounts of noncritical data  This area is not secure; therefore if sensitive information is written to this area it should be encrypted first

16 © 2004 Deloitte & Touche LLP and affiliated entities. Guarantee of Assembly Integrity  Host Evidence contains many different classes of evidence that identify an assembly  One of the classes of evidence is referred to as the StrongName class  The StrongName class can guarantee the integrity of an assembly (i.e. that it hasn’t been tampered)  The StrongName class can also be used to provide an assembly with a unique versioned identity  See Technical Details of Guaranteeing the Integrity of Assemb... Technical Details of Guaranteeing the Integrity of Assemb...Technical Details of Guaranteeing the Integrity of Assemb...  See “PortScanner” application

17 © 2004 Deloitte & Touche LLP and affiliated entities. Impersonating a Windows User  Impersonation allows a user to change the identity of owner of a thread or even a HTTP context  Not restricted to impersonating the identity of the user accessing the system.  In some instances, an application may take a set of users (possibly all users) that access an application and make them all impersonate a single account.  Different circumstances for impersonation: When to Use Windows Authentication and Impersonation When to Use Windows Authentication and Impersonation When to Use Windows Authentication and Impersonation When to Use Windows Authentication and Impersonation When to Use Windows Authentication and Not Impersonation When to Use Windows Authentication and Not Impersonation When to Use Windows Authentication and Not Impersonation When to Use Windows Authentication and Not Impersonation When to Use Impersonation for Fixed Identity When to Use Impersonation for Fixed Identity When to Use Impersonation for Fixed Identity When to Use Impersonation for Fixed Identity  See Web Application Best Practice Web Application Best PracticeWeb Application Best Practice  See Obtain Identity Information Obtain Identity InformationObtain Identity Information  See “TestImpersonate” application

18 © 2004 Deloitte & Touche LLP and affiliated entities. ASP.NET - How to Securely Store Credentials for Fixed Account  Create a windows user account (with appropriate file permissions)  Run Microsoft’s aspnet_setreg.exe to create the encrypted credentials in your registry  Copy the textual output from the aspnet_setreg.exe application into your web.config  Give read permissions to those two keys in your registry to the chosen account

19 © 2004 Deloitte & Touche LLP and affiliated entities. Cryptography – Hashing Algorithms NameInput Block SizeMessage Length(bits) Hash Code Size (bits) MD SHA SHA SHA SHA

20 © 2004 Deloitte & Touche LLP and affiliated entities. Cryptography – Symmetric Algorithms NameBlock SizeKey length (bits) DES6456 RC26440, 48, 56, 64, 72, 80, 88, 96, 104,, 112, 120, 128 Triple-DES64Two or three 56-bit keys, expressed as 64- bit numbers Rijndael (AES)128, 192, 256

21 © 2004 Deloitte & Touche LLP and affiliated entities. Cryptography – Asymmetric Algorithms  The.NET class library only supports the use of RSA asymmetric cryptography  See MSDN description of RSACryptoServiceProvider Class for further information MSDN description of RSACryptoServiceProvider ClassMSDN description of RSACryptoServiceProvider Class  The maximum key size is 2048 byte (16384 bit)

22 © 2004 Deloitte & Touche LLP and affiliated entities. DPAPI (Data Protection API) .NET System.Security.Cryptography classes are extensive in their support for cryptography  What about key management? Enter DPAPI.  DPAPI works by generating a key from the current user's credentials.  Useful for encrypting configuration data any confidential application data such as connection strings, passwords and private keys  The interface is very simplistic since it is composed of only two methods: CryptProtectData – used to encrypt data CryptProtectData – used to encrypt data CryptUnprotectData – used to decrypt data CryptUnprotectData – used to decrypt data  Potential issue is switching identities using impersonation

23 © 2004 Deloitte & Touche LLP and affiliated entities..Net Security Tool: FxCop (1.23)  Completes analysis on.NET assemblies based on rules (specified within various.dll’s). See FXCop 1.23 Rules See FXCop 1.23 RulesFXCop 1.23 RulesFXCop 1.23 Rules  Rules can be disabled if their application is not useful within the context of the analysis  Simple interface: Create a new project Create a new project Add assemblies (.dll’s or.exe’s) Add assemblies (.dll’s or.exe’s) Click analyze Click analyze Generate an XML based report Generate an XML based report

24 © 2004 Deloitte & Touche LLP and affiliated entities. Largest Security Services team in Canada Security Infrastructure Vulnerability Assessment Identity Management ERP Controls ISO17799 consulting BS certification Infrastructure Planning VPN Firewall Anti-virus Wireless Logging, Monitoring and Reporting Security Assessments Product reselling BCP planning and implementation Feasibility Studies Review of current implementations New implementations Work with leading vendors CA Application Integrity and Security ERP Security reviews ERP implementations Vendors PeopleSoft SAP Oracle JDEdwards Attack and Penetration testing Network and Application vulnerability assessments Forensic reviews Canadian Security Services Group Security Services Group Doug MacPherson –

25 © 2004 Deloitte & Touche LLP and affiliated entities. Questions? and Share.Net Security Experiences Contact:

26 © 2004 Deloitte & Touche LLP and affiliated entities..Net Code Access Security I

27 © 2004 Deloitte & Touche LLP and affiliated entities..Net Code Access Security II

28 © 2004 Deloitte & Touche LLP and affiliated entities. Categorization of Security Actions By Function/Use UseSecurity Actions Inquire about code permissionsDemand, LinkDemand Provide information for the Security Policy administrator Request Minimum, RequestOptional Restrict the permissions your code hasRequestRefuse, RequestOptional, Deny, InheritanceDemand, PermitOnly Halt the check of permissionsAssert

29 © 2004 Deloitte & Touche LLP and affiliated entities. Example of Role Based Permissions  To implement the PrincipalPermission class imperatively, create a new instance of the class and initialize it with the name and role that you want users to have to access your code. For example, the following Visual Basic code initializes a new instance of this object with an identity of "Joan" and a role of "Teller". Dim id As String = "Joan" Dim role As String = "Teller" Dim principalPerm As New PrincipalPermission(id, role) principalPerm.Demand()  You can create a similar permission declaratively using the PrincipalPermissionAttribute class. The following Visual Basic code declaratively initializes the identity to "Joan" and the role to "Teller".  When the security check is performed, both the specified identity and role must match for the check to succeed. However, when you create the PrincipalPermission object, you can pass a null identity string to indicate that the identity of the principal can be anything. Similarly, passing a null role string indicates that the principal can be a member of any role (or no roles at all). For declarative security, the same result can be achieved by omitting either property. For example, the following Visual Basic code uses the PrincipalPermissionAttribute to declaratively indicate that a principal can have any name, but must have the role of teller.

30 © 2004 Deloitte & Touche LLP and affiliated entities. Declarative and Imperative Security Statements  Declarative Style All security actions can be expressed All security actions can be expressed All security constraints can be expressed at compile time All security constraints can be expressed at compile time Only allows annotation at the full method, class or assembly scope Only allows annotation at the full method, class or assembly scope Tools are able to extract the metadata information from an assembly and determining the required permissions* Tools are able to extract the metadata information from an assembly and determining the required permissions*  Imperative Style More flexible More flexible Easier to create control flow errors Easier to create control flow errors

31 © 2004 Deloitte & Touche LLP and affiliated entities. Example of LinkDemand [FileIOPermission(SecurityAction.LinkDemand,Read="C:\\")] private void MyMethod() { // Do Something // Do Something}

32 © 2004 Deloitte & Touche LLP and affiliated entities. Example of InheritanceDemand [SecurityPermission(SecurityAction.InheritanceDemand)] private class MyClass() { // what ever // what ever}

33 © 2004 Deloitte & Touche LLP and affiliated entities. Example of Security Action Override: Deny [FileIOPermission(SecurityAction.Deny,Read="C:\\")]

34 © 2004 Deloitte & Touche LLP and affiliated entities. Example of PermitOnly UIPermission perm; perm=new UIPermission(UIPermissionWindow.AllWindows); perm.PermitOnly();

35 © 2004 Deloitte & Touche LLP and affiliated entities.AllowPartiallyTrustedCallersAttribute  TAKE A NAP NOW - if you do not expect your code to be executed from a partially trusted context or to be called by partially trusted code  By default, all code that executes from the local intranet or Internet zones is partially trusted (this can be modified through your security policy)  When a method has the AllowPartiallyTrustedCallersAttribute set, it is callable by partially trusted code If it in turn calls methods without the attribute, a partially trusted caller is, in effect, being allowed to execute code that requires full trust If it in turn calls methods without the attribute, a partially trusted caller is, in effect, being allowed to execute code that requires full trust  Depending on what full trust code is called and what parameter values are passed through from the partially trusted caller, malicious code might be able to exploit this security weakness  See Part 1 - Example of Use of AllowPartiallyTrustedCallersAt... Part 1 - Example of Use of AllowPartiallyTrustedCallersAt...Part 1 - Example of Use of AllowPartiallyTrustedCallersAt...

36 © 2004 Deloitte & Touche LLP and affiliated entities. Role Based Permission Demand Example  The following will not give the user permission if the user does not have either the identity name “John Smith” who belongs to the role “Manager” OR (due to the union) the identity name “Louise” who belongs to the role “Supervisor”: Dim id1 As String = "John Smith" Dim role1 As String = "Manager" Dim PrincipalPerm1 As New PrincipalPermission(id1, role1) Dim id2 As String = "Louise" Dim role2 As String = "Supervisor" Dim PrincipalPerm2 As New PrincipalPermission(id2, role2) PrincipalPerm1.Union(PrincipalPerm2).Demand()

37 © 2004 Deloitte & Touche LLP and affiliated entities. Example of Request Minimum Declarative Statement [assembly:UIPermissionAttribute(SecurityAction.RequestMinimum)] In this case, if the application is not granted UI access, the application will fail to start. [assembly:FileIOPermissionAttribute (SecurityAction.RequestMinimum, Write="C:\\sessionData.tmp")] (SecurityAction.RequestMinimum, Write="C:\\sessionData.tmp")] The above statement results in the assembly not starting unless the assembly has the minimum permissions of access to “c:\\sessionData.tmp”

38 © 2004 Deloitte & Touche LLP and affiliated entities. Example of Request Optional Declarative Statement [assembly:PermissionSet (SecurityAction.RequestOptional, Unrestricted=false)] (SecurityAction.RequestOptional, Unrestricted=false)]  The above optional request - this attribute makes an optional request for no permission set. This means that no permission set will be granted to the code by the code access security policy. All permissions that should be granted must be requested using additional assembly- level attributes.

39 © 2004 Deloitte & Touche LLP and affiliated entities. Example of Request Refuse Declarative Statement [assembly : FileIOPermissionAttribute (SecurityAction.RequestRefuse,Read="C:\\")] In this case, the entire assembly will be blocked from accessing the C drive.

40 © 2004 Deloitte & Touche LLP and affiliated entities. Technical Details of Isolated Storage  To access files and directories stored in the Isolated Storage, classes under the System.IO.IsolatedStorage namespace.  You can use the StoreAdm tool to view and remove the files and directories stored in Isolated Storage. Generally the Isolated Storage files are stored under the C:\Documents and Settings\ \Local Settings\Application Data\Microsoft\Isolated Storage\ directory on Windows 2000.

41 © 2004 Deloitte & Touche LLP and affiliated entities. Technical Details of Guaranteeing the Integrity of Assemblies  Assemblies can be signed using the sn.exe tool  The following command creates a new, random key pair and stores it in keyPair.snk: sn -k keyPair.snk sn -k keyPair.snk  Then the following can be placed in the assemblyInfo.cs (in the case of C# development): [assembly: AssemblyKeyFile("keypair.snk")] [assembly: AssemblyKeyFile("keypair.snk")]  Once assembly is signed, public key must be issued to users of assembly to validate integrity  The following command extracts the public key from keyPair.snk and stores it in publicKey.snk: sn -p keyPair.snk publicKey.snk sn -p keyPair.snk publicKey.snk  A third party can use the following to verify the assembly: sn -v PortScanner.exe sn -v PortScanner.exe

42 © 2004 Deloitte & Touche LLP and affiliated entities. When to Use Windows Authentication and Impersonation  The three most common occasions when authentication should be used in conjuncture with Impersonation are when: Your application’s users have Windows accounts that can be authenticated by the server. Your application’s users have Windows accounts that can be authenticated by the server. You need to flow the original caller’s security context to the middle tier and/or data tier of your Web application to support fine-grained (per-user) authorization. You need to flow the original caller’s security context to the middle tier and/or data tier of your Web application to support fine-grained (per-user) authorization. You need to flow the original caller’s security context to the downstream tiers to support operating system level auditing. You need to flow the original caller’s security context to the downstream tiers to support operating system level auditing.

43 © 2004 Deloitte & Touche LLP and affiliated entities. When to Use Windows Authentication and Not Impersonation  There are two basic scenarios in which it is useful to use impersonation without windows authentication and these are when: Your application’s users have Windows accounts that can be authenticated to the server. Your application’s users have Windows accounts that can be authenticated to the server. You want to use fixed identity to access downstream resources (for example, databases) in order to support connection pooling. You want to use fixed identity to access downstream resources (for example, databases) in order to support connection pooling.

44 © 2004 Deloitte & Touche LLP and affiliated entities. When to Use Impersonation for Fixed Identity  This is useful if you want the application to impersonate an account that isn’t the default account for running ASP.NET applications (by default this account is ASPNET)  Once this fixed identity is impersonated, you gain the benefits mentioned in the “When to Use Windows Authentication and Not Impersonation” section and that is accessing resources to support things like connection pooling.  The Microsoft recommended method of providing this very useful functionality can be found at:  b;en-us; b;en-us; b;en-us;329290

45 © 2004 Deloitte & Touche LLP and affiliated entities. Web Application Best Practice  In the situation that you would like to: collect audit information on a per user basis in a web application collect audit information on a per user basis in a web application make use of connection pooling make use of connection pooling  The application could impersonate the windows user and then when any queries are made to the database, the impersonation of a fixed account could be used  This would not allow true auditing to be done for the database, but it would allow it within the context of the web application  The above can also be used to facilitate Single Sign-On functionality by making use of impersonation and “Integrated Windows Authentication”

46 © 2004 Deloitte & Touche LLP and affiliated entities. Obtain Identity Information  It is not necessary to impersonate to perform.NET role checks or to access information within Windows ACLs. More specifically, by using LDAP queries against a Directory (for instance Active Directory) the ASPNET user can ascertain the roles of any users in that directory. The following Visual Basic code can be used to get the details of John Smith in the Active Directory server: Public Shared Function GetUserDetails() As String Dim arrName() As String Dim UserData As String, objUser As New DirectoryEntry Dim UserData As String, objUser As New DirectoryEntry objUser.Path = "LDAP://ADserverHost/CN=userName, OU=Users, " objUser.Path = objUser.Path + "OU=Region, DC=ca, DC=domain" Dim collectionOfProperties As PropertyCollection collectionOfProperties = objUser.Properties objUser = Nothing Dim dEnum As IDictionaryEnumerator dEnum = collectionOfProperties.GetEnumerator While (dEnum.MoveNext = True) While (dEnum.MoveNext = True) Dim propValCollection As PropertyValueCollection PropValCollection = collectionOfProperties.Item(dEnum.Key) UserData = UserData + " " + dEnum.Key + ": " UserData = UserData + propValCollection.Value().ToString() End While Return UserData End Function Impersonation is not required providing that the calling process has sufficient privileges to access the network’s Directory server.

47 © 2004 Deloitte & Touche LLP and affiliated entities. Part 1 - Example of Use of AllowPartiallyTrustedCallersAttribute  In your local intranet, your organization is interested in deploying an intranet application (an application that is deployed on the internal website) that makes use of dll’s that have been installed only on particular user’s computers. The dll’s provide these intranet applications with critical functionality. This in essence could act as another layer of security. That being that only users with access to the dll’s can run the intranet application.  However, the shared libraries must also be compiled such that they can be used by partially trusted applications. However, to allow assemblies to be accessed by partially trusted assemblies, they must be part of the Global Assembly Cache (GAC). In order to add an assembly to the Global Assembly Cache, the assembly must have a strong name. This can be achieved through the use of the Microsoft (R).NET Framework Strong Name Utility (sn.exe).  The Strong Name Utility can be used to generate a public and private key and then using the following syntax:    The assembly will be signed with the private key and the public key will be attached to the assembly so that whoever receives the assemblies can add the assemblies to their Global Assembly Cache (GAC).

48 © 2004 Deloitte & Touche LLP and affiliated entities. Part 2 - Example of Use of AllowPartiallyTrustedCallersAttribute  If a user does not add the shared library to the Global Assembly Cache (GAC) then it can result in the following:  "An unhandled exception of type 'System.IO.FileNotFoundException' occurred in IEExec.exe"  An assembly can be added to the Global Assembly Cache (GAC) by invoking the mscorcfg.msc (.NET Framework Configuration tool) application and right clicking on the Assembly Cache, then clicking add and selecting the assembly that needs to be added.  However, if it has been added, but the developer did not add the AllowPartiallyTrustedCallersAttribute syntax:    then the application will either return:  An unhandled exception of type 'System.IO.FileLoadException' occurred in IEExec.exe  OR  An unhandled exception of type 'System.Security.SecurityException' occurred in IEExec.exe  This means that the executable could not load the shared library.

49 © 2004 Deloitte & Touche LLP and affiliated entities. FXCop 1.23 Rules  Standard install includes the following rules: Com – rules that detect COM Interop issues. Com – rules that detect COM Interop issues. Design – rules that detect potential design flaws. These coding errors typically do not impact the execution of your code. Design – rules that detect potential design flaws. These coding errors typically do not impact the execution of your code. Globalization – rules that detect missing or incorrect usage of information related to globalization and localization. Globalization – rules that detect missing or incorrect usage of information related to globalization and localization. Naming – rules that detect incorrect casing, key–word collisions, and other issues related to the names of types, members, parameters, namespaces, and assemblies. Naming – rules that detect incorrect casing, key–word collisions, and other issues related to the names of types, members, parameters, namespaces, and assemblies. Performance – rules that detect elements in your assemblies that will degrade performance. Performance – rules that detect elements in your assemblies that will degrade performance. Security – rules that detect programming elements that leave your assemblies vulnerable to malicious users or code. Security – rules that detect programming elements that leave your assemblies vulnerable to malicious users or code. Usage - rules that detect potential flaws in your assemblies that can impact code execution. Usage - rules that detect potential flaws in your assemblies that can impact code execution.


Download ppt "© 2004 Deloitte & Touche LLP and affiliated entities..NET Security Mechanisms Tim Cassidy MSc. CISSP."

Similar presentations


Ads by Google