690 likes | 1.23k Views
Chapter 10 ASP.NET Security. Yingcai Xiao. Introduction to Web Security Categories Issues Components. Building a Secure Web Site. Three Categories of Web Security : Content freely available to everyone (public).
E N D
Chapter 10ASP.NET Security Yingcai Xiao
Building a Secure Web Site • Three Categories of Web Security: • Content freely available to everyone (public). • Serve the general population but require a login (application-level security, protected). • Intranet sites for a controlled population of users — a company’s employees (private). • Security Issues: • Application-level security (users). • Deployment security (programmers). • Web Security Components: • Authentication identifies the originator of requests (who). • Authorization defines who can access which pages (what).
Authentication • ASP.NET supports three types of authentication: • Forms (Page-wide) • Windows (Machine-wide) • Passport (Internet-wide) • None • Web.config <configuration> <system.web> <authentication mode="Forms"/> </system.web> </configuration> Note: • The authentication mode is an application-wide setting that can be set only in the application root and can’t be overridden in subordinate Web.config files. • You can’t use Windows authentication in one part of an application and forms authentication in another.
Authorization • ASP.NET supports two forms of authorization: • ACL (access control list) authorization, also known as file authorization, based on file system permissions, typically used with Windows authentication. • URL authorization, relies on configuration directives in Web.config files, most often used with forms authentication.
Three Typical Security Scenarios for Web Applications • Pages can be freely browsed by any: no application-level security • Intranet application: use Windows authentication and ACL authorization. • Internet application with secure page access: use forms authentication and URL authorization.
IIS Security • IIS (Internet Information Services) Server • a Web server • runs in process Inetinfo.exe as SYSTEM • accepts connections • responds to HTTP requests • Web applications are deployed in application directories. Remote clients can’t arbitrarily grab files outside virtual directories. • IIS assigns every request an access token representing a Windows security principal. The access token enables the operating system to perform ACL checks on resources targeted. • IIS supports IP address and domain name restrictions. • IIS supports encrypted HTTP connections using the Secure Sockets Layer (SSL) family of protocols.
IIS Security • Anonymous access (access by unauthenticated users) • Request from anonymous users are tagged with IUSR_machinename’s access token. IUSR_machinename is an Internet guest account created when IIS is installed, where machinename is usually the Web server’s machine name.
ASP.NET Security • Server Side Processing: (1) Client accesses .ASPX files => (2)Inetinfo.exe (IIS) generates an access token =>Aspnet_isapi.dll sents the request and the token through named pipe or local procedure calls (LPCs) => (3) Aspnet_wp.exe (ASP.NET) makes ACL checks on the requested resource and passes access token to the targeted application => (4) Targeted application uses a HTTP pipeline => HTTP modules => HTTP handlers (mapped in Machine.config).
Two types of access tokens: • Authenticated user: authenticated security principal • Unauthenticated user: IUSR_machinename for anonymous login • Start->Settings->Control Panel->Administrative Tools->Computer Management->Local Users and Groups->Users • Start->Settings->Control Panel->Administrative Tools->Computer Management->Event Viewer->Security
The ASPNET Account • Created when ASP.NET is installed. • A member of the “Users” group. • Aspnet_wp.exe runs as ASPNET by default. • Requests executed by ASP.NET use Aspnet_wp.exe’s identity. • ASP.NET can impersonate to use the request’s access token. • To make Aspnet_wp.exe to run as SYSTEM, change processModel in Machine.config to <processModel userName="SYSTEM" ... />
Impersonation • To execute a request using the access token provided by IIS. • Add the following in Web.config <identity impersonate="true" /> • The identities assigned to the ASP.NET worker process and to the requests that it executes play crucial roles.
Forms Authentication • Forms authentication allows applications to setupweb authentications independently from the authentications of the operating systems. It works well with URL authorization, which relies on configuration directives in Web.config files. • Forms/URL security is useful to protect an e-commerce site (an external/Internet application for servicing customs of a company).
Forms Authentication: Static Structure • Security settings in an ASP.NET-based web application are configured in the Web.config files. • The Web.config file in the root directory (which must be an application directory) specifies the authentication mode, application-specific login page. • The Web.config file in a subdirectory sets the authorization specifics for the directory. • User credentials can be stored in a database (preferred) or in the root Web.config file.
Forms Authentication : Dynamic Behavior • The first time a user accesses a protected resource, ASP.NET redirects the user to the login page. • If the login is successful, ASP.NET then issues the user an authentication ticket in the form of a cookie (cookies need to be enabled by the client) and redirects the user to the page originally requested. • The ticket allows that user to revisit protected portions without having to login again. • The ticket’s lifetime can be controlled to determine how long the login is good for.
A First Look at Forms Authentication • Forms1 Web Application • T:\Xiao\Windows Programming\Examples\C10\Forms1 • At the application root • PublicPage.aspx can be viewed by anyone • Web.config • LoginPage.aspx • In the Secret subdirectory • ProtectedPage.aspx is available only to authenticated users (wp/wp). • Web.config
Deploy Forms1 on Winserv1 • Create a web application directory. C:\inetpub\wwwroot\VD\xiaotest\Forms1 You need to have admin privilege. On winserv1, use an existing web application directories already created for you, i.g., wppa5. • Copy everything from T:\Xiao\Windows Programming\Examples\C10\Forms1 to the above directory (C:\inetpub\wwwroot\VD\xiaotest\Forms1) • http://winserv1.cs.uakron.edu/VD/xiaotest/Forms1/PublicPage.aspx can be viewed by everyone. • http://winserv1.cs.uakron.edu/VD/xiaotest/Forms1/Secret/ProtectedPage.aspx is available only to authenticated users (wp/wp). • “Authenticated users” means anyone who has successfully logged in through LoginPage.aspx. • Valid users are stored in Web.config. • The cookie containing the authentication ticket is a session cookie, destroyed when the browser is closed. • You are not prompted for password again during a session.
Programming Forms Security • Authentication in the root Web.config <authentication mode="Forms"> <forms loginUrl="LoginPage.aspx"> <credentials passwordFormat="Clear"> <user name="wp" password=“wp"/> <user name="John" password="redrover" /> • Authorization (directory-wise) in Secret/Web.config <authorization> <deny users="?" /> URL authorization to deny “?” (anonymous) users.
Programming Forms Security • PublicPage.aspx void OnViewSecret (Object sender, EventArgs e) { Response.Redirect ("Secret/ProtectedPage.aspx"); } • LoginPage.aspx. void OnLogIn (Object sender, EventArgs e) { if(FormsAuthentication.Authenticate(UserName.Text, Password.Text)) FormsAuthentication.RedirectFromLoginPage (UserName.Text, false); // “true” for persistent cookie else Output.Text = "Invalid login"; } System.Web.Security.FormsAuthentication.Authentic method returns true if the user name and password are in the credentials section of Web.config.
Internal Works • ASP.NET creates an authentication cookie, attaches it to the outgoing response, and redirects the user to the page that he or she originally requested. The lifetime of a persistent cookie is independent of the browser session. • Authorization is applied on a directory-by-directory basis. Web.config files in each directory specify exactly how the files are to be protected. • ASP.NET checks to see whether a valid authentication cookie is attached to the request. If the cookie exists, ASP.NET extracts identity information. If the cookie doesn’t exist, ASP.NET redirects the request to the login page.
Real-World Forms Authentication – (Forms2) • Storing user names and passwords in a database (MySQL). • Creating the database, creating the “users” table and adding users. • Logo on to winserv1. • Start->All Programs->My SQL->My SQL Query Browser. • Server Host: db1.cs.uakron.edu • Port 3306 • Username: yourLoginID_wp • Password: yourPassword for MySQL • Default Schema: yourLoginID_wp • File->Open Script: T:\Xiao\Windows Programming\Examples\C10\MySQL-Table-Creation\Weblogin.sql • Execute!
Real-World Forms Authentication Weblogin.sql CREATE TABLE users ( username varchar(32) NOT NULL, password varchar(32) NOT NULL, role varchar(32) ); INSERT INTO users (username, password, role) VALUES (‘dev', ‘dev', 'Developer'); INSERT INTO users (username, password, role) VALUES (‘mgr', ‘mgr', 'Manager'); … AddUsers.sql • INSERT INTO users (username, password, role) VALUES ('wpd1', 'wp2009', 'Developer'); • INSERT INTO users (username, password, role) VALUES ('wpd2', 'wp2009', 'Developer'); …
Real-World Forms Authentication – (Forms2) • To deploy the application copy T:\Xiao\Windows Programming\Examples\C10\Forms2 to C:\Inetpub\wwwroot Create a “Forms2” virtual directory for it. • To access • http://localhost/Forms2/PublicPage.aspx can be viewed by anyone. • http://localhost/Forms2/Secret/ProtectedPage.aspx is available only to authenticated users (wpd1/wpd1).
Deploy Forms2 on Winserv1 • Create a web application directory. C:\inetpub\wwwroot\VD\xiaotest\Forms2 You need to have admin privilege. On winserv1, use an existing web application directories already created for you, i.g., wppa5. • Copy everything from T:\Xiao\Windows Programming\Examples\C10\Forms2 to the above directory (C:\inetpub\wwwroot\VD\xiaotest\Forms2) • http://winserv1.cs.uakron.edu/VD/xiaotest/Forms2/PublicPage.aspx can be viewed by everyone. • http://winserv1.cs.uakron.edu/VD/xiaotest/Forms2/Secret/ProtectedPage.aspx is available only to authenticated users (wp/wp). • “Authenticated users” means anyone who has successfully logged in through LoginPage.aspx. • Valid users are stored in Web.config. • The cookie containing the authentication ticket is a session cookie, destroyed when the browser is closed. • You are not prompted for password again during a session.
Real-World Forms Authentication LoginPage.aspx • Credential Matching: SQL: select count(*) from users where username = ‘dev' and pwd = ‘dev’; It returns 0 if no matching credentials found. • MySQL notes: (1) count (*) works for SQL Server but not MySQL due to the extra space after count. (2) password is a keyword in MySQL (not SQL Server), therefore can’t be used as database column names. (3) ExecuteScalar returns Int64 for “count” query. • FormsAuthentication.RedirectFromLoginPage (UserName.Text, Persistent.Checked); Persistent authentication cookie: be able to get back without logging in again, even after shutting down.
Authentication Cookie Lifetime • Session authentication cookie. Machine.config <forms ... timeout="30"> // 30 minutes Web.config <forms loginUrl="LoginPage.aspx" timeout="10080" /> // 7 days • Proramming cookies. HttpCookie cookie = Response.Cookies[FormsAuthentication.FormsCookieName]; cookie.Expires = DateTime.Now + new TimeSpan (7, 0, 0, 0); // 7 days • Removing cookies IE->Tools->Internet Options->General->Delete Cookies. Netscape->Tools->Cookie Manager->Manage stored cookies->Remove all. FireFox->Tools->Clear Private Data->Cookies->
Forms Authentication and Role-Based Security (Forms3) • Use role membership to allow only some authenticated users to view Secret/ProtectedPage.aspx. • Without roles: Deny all unauthenticated users. <deny users="?" /> Deny all users (users=“*”) except John and Alice. <allow users="John, Alice" /> <deny users="*" /> Allow all except Jeff, Bob, and Mary: <deny users="Jeff, Bob, Mary" /> <allow users="*" /> <allow> and <deny> are order-sensitive. ASP.NET will stop at <…= “*”> and ignore any statements that appear after it.
Forms Authentication and Role-Based Security (Forms3) • With roles: • “Users” table has a field named “role” that stores each user’s role (group) membership. • Grant Developer access to Secret. <allow roles="Developer" /> <deny users="*" /> • Map the roles to user accounts so that ASP.NET can determine whether the requestor is a developer or not. • Place the mapping in the AuthenticateRequest event handler (invoked at the beginning of every request). • Can be done in a custom HTTP module or in Global.asax. http://winserv1.cs.uakron.edu/VD/xiaotest/Forms3/PublicPage.aspx dev/dev/Developer can view ProtectedPage.aspx. mgr/mgr/Manager can’t.
Programming Role-based Authentication • Getting Information about Authenticated Users in Your Code • ASP.NET stores user information in the HttpContext.User property. • Access User through Page.Context.User or simply Page.User, or HttpApplication.User. • The “User” property is of the type IPrincipal (an interface defined in System.Security.Principal). • Implemented by the WindowsPrincipal class for Windows authentication and GenericPrincipal class for other forms of authentication (along with Windows authentication). • GenericPrincipal is a device for representing user identities independent of the authentication protocol being used. ASP.NET compares the role name in the GenericPrincipal to the roles granted access through Web.config. • User.Identity contains some usefull properties:
Properties in User.Identity if (User.Identity.IsAuthenticated) { string name = User.Identity.Name; … } Name is of the form domain-name\user-name for Windows authentication, user-typed login for forms authentication.
Programming Authentication - Roles Retrieve a user’s role and create a Principal for the user. <%@ Import Namespace="System.Security.Principal" %> <script language="C#" runat="server"> • void Application_AuthenticateRequest (Object sender, EventArgs e) • { • HttpApplication app = (HttpApplication) sender; • if (app.Request.IsAuthenticated && • app.User.Identity is FormsIdentity) { • FormsIdentity identity = (FormsIdentity) app.User.Identity; • // Find out what role (if any) the user belongs to • string role = GetUserRole (identity.Name); • // Create a GenericPrincipal containing the role name • // and assign it to the current request • if (role != null) • app.Context.User = new GenericPrincipal (identity, • new string[] { role }); • } • }
Programming Authentication - Roles string GetUserRole (string name) { MySqlConnection connection = new MySqlConnection ("server=db1.cs.uakron.edu;database=xiaotest;uid=xiaotest;pwd=wp2009; allow zero datetime=yes“) try { connection.Open (); StringBuilder builder = new StringBuilder (); builder.Append ("select role from users " + "where username = \'"); builder.Append (name); builder.Append ("\'"); MySqlCommand command = new MySqlCommand (builder.ToString (), connection); object role = command.ExecuteScalar (); if (role is DBNull) return null; return (string) role; } catch (MySqlException) { return null; } finally { connection.Close ();} }
More on Forms Authentication • Multiple Roles Coding: app.Context.User = new GenericPrincipal (identity, new string[] { "Developer", "Manager" }); Web.config <allow roles="Manager, Developer" /> <deny users="*" /> • Configure subdirectories in root Web.config <location path="Secret"> <system.web> <authorization> <allow roles=" Developer" /> <deny users="*" /> </authorization> </system.web> </location>
More on Forms Authentication • Signing Out <asp:Button Text="Log Out" OnClick="OnLogOut" RunAt="server" /> <script language="C#" runat="server"> void OnLogOut (Object sender, EventArgs e) { FormsAuthentication.SignOut (); } FormsAuthentication.SignOut( ): returns a Set-Cookie header, sets the cookie’s value to a null string and sets the cookie’s expiration date to a date in the past.
More on Forms Authentication Attributes of forms element in Web.config: The protection attributes specifies the desired level of protection for the authentication cookies. “All” instructs ASP.NET to both encrypt and validate authentication cookies.
Encrypt and Validate Authentication Cookies • Validation works by appending the machineKey element’s validationKey to the cookie, the resulting value is hashed, and the hash is appended to the cookie. When the cookie is returned in a request, ASP.NET verifies that it wasn’t tampered with by rehashing the cookie and comparing the new hash to the one accompanying the cookie. • Encryption works by encrypting the cookie—hash value and all—with machineKey’s decryptionKey attribute.
Encrypt and Validate Authentication Cookies • Validation consumes less CPU time than encryption and prevents tampering. It does not prevent someone from intercepting an authentication cookie and reading its contents. • To validate but not encrypt authentication cookies: <forms ... protection="Validation" /> • Encryption provides insurance against tampering and prevents the cookie’s contents being read. • To encrypt but not validate cookies: <forms ... protection="Encryption " />
Encrypt and Validate Authentication Cookies • To disable both: <forms ... protection="None" /> • Encrypted cookies can’t be read or altered, but can be stolen and used illicitly. Time-outs are the only protection. • The most reliable way to prevent someone from spoofing your site with a stolen authentication cookie is to use an encrypted communications link (HTTPS). • <forms ... loginUrl="https://www.wintellect.com/login.aspx" /> This assumes the server supports HTTPS and Login.aspx is stored in a directory configured to use HTTPS. • Caveat Emptor: ASP.NET does not protect HTML pages. Just renaming .html to .aspx to protect it. • http://winserv1.cs.uakron.edu/VD/xiaotest/Forms3/PublicPage.aspx • http://winserv1.cs.uakron.edu/VD/xiaotest/Forms3/Secret/ProtectedPage.aspx • http://winserv1.cs.uakron.edu/VD/xiaotest/Forms3/Secret/Calc.html • http://winserv1.cs.uakron.edu/VD/xiaotest/Forms3/Secret/Calc.aspx
Windows Authentication • It maps incoming requests to accounts on the Web server or in the Web server’s domain. Use it to serve content to a well-defined populace. • Don’t use it to generically expose content to all comers over the Internet. • Windows authentication on the front end is typically paired with ACL authorization (administrator controlled) on the back end. • Can be also used with URL authorization (programmer controlled).
Windows Authentication • Categories of Windows Authentication: • Basic authentication: login, piggyback on HTTP. • Digest authentication: login, piggyback on HTTP. • Integrated Windows authentication: Windows login. • SSL client certificates: limited primarily to intranet.
Basic Authentication • An HTTP standard (documented in RFC 2617, ftp://ftp.isi.edu/in-notes/rfc2617.txt.) • How it works: • For the first time access, the Web server returns a 401 status code indicating what type of authentication is required. • HTTP/1.1 401 Access Denied Server: Microsoft IIS-5.0 . . .WWW-Authenticate: Basic realm="uakron.edu" • A realm is a logical security space that encompasses all or part of a web site. • The browser pops up a dialog box asking for a user name and password.
Basic Authentication • It concatenates the user name and password to an encoded string in the Authorization header of an HTTP request. Authorization: Basic SmVmZjppbWJhdG1hbg== • The browser includes the same Authorization header in each future request to the same realm. • IIS maps the user name and password to an account on the web server, producing an access token. • The access token is used to perform ACL-based security checks.
Basic Authentication • Pros of Basic Authentication: • It works with virtually all browsers. • Easy to use. • It works well with firewalls. • Cons of Basic Authentication: • Nothing prevents requests from being intercepted and used to gain access to your server. • Some users consider pop-up dialogs intrusive. • Better to be used with HTTPS, not HTTP.
Digest Authentication • Documented in RFC 2617 (ftp://ftp.isi.edu/in-notes/rfc2617.txt). • Similar to basic authentication. • The browser solicits a user name and password by popping up a dialog box. The server uses the credentials to assign an identity to the request. • The big difference between basic and digest authentication is that digest doesn’t transmit clear-text passwords. Instead, it passes an authentication token that is cryptographically secure. As a result, you can use it over unencrypted channels without fear of compromising your Web server.