Best Practices and Techniques for Building Secure ASP.NET Applications

1. Best Practices and Techniques for Building Secure ASP.NET Applications Patrick Hynds, CriticalSites MSDN Regional Director for Boston, MCSD, MCSE+I, MCDBA, MCT, MCP + Site Builder

2. Experience / Background • Services • Integration (Design, Best Practices) • Development (Ecommerce, Commercial) • Technology Consultant Coaching • Notables • Built 1st Windows logo certified .Net app • Regularly present at: • TechEd US and TechEd Hong Kong • .Net User’s Groups worldwide (INETA Speaker) • and many other international events • Security Editor for .Net Developer’s Journal

3. Agenda • Threat modeling • Security Starting with IIS • Beyond the Web Server • Authentication • Authorization • Configuration settings • Storing secrets • Data validation

4. Internal Threats • Disgruntled employee • Bad faith business partner • Human engineering • Virus proliferation • Credential reuse outside your org • Improper configuration of security settings • At home backups

5. External Threats • Random script kiddie • Slighted prospect • Unscrupulous Competitor • Zombie Army Enlistment • Warez Hijacking • Determined, Professional Attack • Being first to get hit by a new exploit

6. Agenda • Threat modeling • Security Starting with IIS • Beyond the Web Server • Authentication • Authorization • Configuration settings • Storing secrets • Data validation

7. Anonymous Authentication • Resource Access as anonyomous • IUSR_Machinename (i.e. IUSR_Typhon) • Process identity: • LocalSystem or • IWAM_Machinename (i.e. IWAM_Typhon) • Anonymous user is completely configurable

8. Basic Authentication • Process identity: IWAM or LocalSystem • Resource access as authenticated user • Pros • Least common denominator • All HTTP clients support basic auth • Supports one hop delegation • Cons • Clear text password (Base64 Encoded) • Over the wire • On the server • Needs to be protected via SSL

9. Digest Authentication • Pros • No clear text password over the wire • Works through proxies • Password is not known to IIS • Cons • Medium secure • Internet Explorer 5 and higher • No delegation • Requires Active Directory • Password in AD (reversible encryption)

10. Windows Integrated Authentication • Security Support Provider (SSPI)-based • NTLM or Kerberos • IIS asks the client what protocol it supports • Protocol can be enforced • NTAuthenticationProviders • Negotiate • NTLM • Kerberos

11. NTLM Authentication • Pros • Works out-of-the-box • Provides automatic logon/no logon dialog box • Cons • Enterprise only – does not work through Proxy Servers (keep-alive connection required) • No delegation • Configured to be compatible with older clients

12. Kerberos Authentication • Strong, scalable, fast, supports delegation • Limited client support • Internet Explorer 5 and Windows 2000 • Issues • DC has to be client accessible Service Principal Name • Domain Administrator needs to be involved • Delegation needs to be enabled • Unconstrained! • Setup • Best description in “designing secure Web-based applications”

13. Client Certificate Authentication • Pros • Very secure • Flexible • Integrity, confidentiality • Cons • Higher management costs for PKI • Usability • Scalability and performance

14. Authentication Grid

15. Agenda • Threat modeling • Security Starting with IIS • Beyond the Web Server • Authentication • Authorization • Configuration settings • Storing secrets • Data validation

16. Windows Authentication • Can be used in combination with Basic, NTLM, Digest, Kerberos, and so forth • User is authenticated by IIS • Easiest of all • Request flow • Client makes request • IIS authenticates request, forwards to ASP.NET • Impersonation turned on? • ASP.NET returns response to client

17. Security Flow for a Request (ASP.NET)

18. Forms Authentication • Uses cookie to authenticate • Enables SSL for logon page • Often used for personalization

19. Forms Authentication Flow

20. Forms Authentication Configuration • Enable anonymous access in IIS • Configure <authentication> section • Set mode to “Forms” • Add the <forms> section • Configure <authorization> section • Deny access to anonymous user • Create logon page • Validate the user • Provide authentication cookie • Redirect the user to the requested page

21. <forms> Section Attributes • loginUrl: unauthenticated request are redirected to this page • name: name of the authentication cookie • path: path of the authentication cookie • protection: All | None | Encryption | Validation • timeout: authentication cookie expiration (min) <authentication mode="Forms"> <forms name=".ASPXAUTH" loginUrl="login.aspx" protection="All" timeout="30" path="/" /> </authentication>

22. demo Forms Authentication

23. Authorization • Process of determining whether a user is allowed to perform a requested action • File-based authorization • Performed by FileAuthorizationModule • Performs checks against Windows ACLs • Custom – handle AuthorizeRequest event • Application level (global.asax) • HTTP module (implement IHttpModule) • URL-based authorization • Performed by UrlAuthorizationModule

24. Windows Users(Check Roles) If User.IsInRole("BUILTIN\Administrators") then Response.Write("You are an Admin") Else If User.IsInRole("BUILTIN\Users") then Response.Write("You are a User") Else Response.Write("Invalid user") End if

25. Non-Windows Users(Attach Roles) • Handle AuthenticateRequest event • Create GenericPrinciple • Attach roles to Identity • Assign new Principle to User Sub Application_AuthenticateRequest(s As Object, e As EventArgs) If Not (User Is Nothing) Then If User.Identity.AuthenticationType = "Forms" Then Dim Roles(1) As String Roles(0) = "Admin" User = new GenericPrinciple(User.Identity,Roles) End If End If End Sub

26. Non-Windows Users (Check Roles) if User.IsInRole("Admin") then Response.Write ("You are an Administrator") Else Response.Write ("You do not have any role assigned") End if

27. demo Custom Authentication with Roles

28. Configuration Settings • Review production configuration: • <customErrors> RemoteOnly or On • Make sure that verbose remote errors are not enabled • Do not reveal exception details in custom error pages • <compilation> disable debugging • Review IIS scriptmaps • Only enable ones you need • Use IIS lockdown (Windows 2000/IIS 5) • Shared servers • Use configuration lockdown • <location allowOverride=“false”/> • Isolate by process (IIS 6) and/or with <trust> level

29. Machine.Config • Some settings vary by .Net Framework version • HTTPGet • HTTPPost • HTTPSoap

30. demo Machine.Config for Security

31. Accounts • Administrator • Deception planning against hackers • Service Accounts

32. Storing Secrets • Do avoid secrets when you can • Consider using integrated authentication • Use layered protection when you need secrets • Access control settings • Data Protection API (DPAPI) • Use aspnet_setreg for ASP.NET secrets • <processModel>, <identity>, <sessionState> • http://support.microsoft.com/default.aspx?scid=kb;EN-US;329290

33. demo Random Salt in the DB

34. Data Validation • Validate all input data • Use ASP.NET validation controls • Use regular expressions for other cases (e.g., web service parameters) • Use parameterized stored procedures or queries for data access to prevent SQL Injection

35. The Future / Whidbey • Indigo • NGSCB (Next Generation Secure Computing Base) • Dynamic Compilation Switch • New Login controls

36. Summary • Security is a war! Don’t fight fair. • Defense in Layers • Not a part time job or “nice to have” feature anymore • Make Security part of every aspect of your projects • should be about 12% of effort per project

37. Resources • How ASP Security Works • An overview of ASP Security http://msdn.microsoft.com/library/dotnet/cpguide/cpconhowaspnetsecurityworks.htm • Key Concepts in Application Security • A basic review of the major components needed to secure applications http://msdn.microsoft.com/library/dotnet/cpguide/cpconkeyconceptsinsecurity.htm

38. Questions