Chapter 10 ASP.NET Security

advertisement
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).
– 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 a few types of authentication:
– Forms (Page-wide)
– Windows (Machine-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.

Setting authentication mode in the root
Web.config
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.
The Internal Working of
IIS and ASP.NET
Security
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 application 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.
The relationship between IIS and ASP.NET.
IIS 6.0




IIS 6.0 has a driver named http.sys to listen
all HTTP requests.
When an ASP.NET related request comes
in, http.sys will stat w3wp.exe as an IIS 6.0
worker process.
W3wp now loads aspnet_isapi.dll as CLR
host.
The rest is the same as before.
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 (hidden now).

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" ... />
The ASPNET Account

You can also run the ASP.NET worker process
(aspnet_wp.exe or w3wp.exe) under a user account:
https://msdn.microsoft.com/en-us/library/bakfs900.aspx
Programming Forms Authentication
Forms Authentication
►
Forms authentication allows applications to setup web
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 (Forms1).
C:\inetpub\wwwroot\xiaotest\Forms1
You need to have admin privilege.
– On winserv1, use an existing web application directory
already created for you.
– Copy everything from
T:\Xiao\Windows Programming\Examples\C10\Forms1
to the above directory.
http://winserv1.cs.uakron.edu/xiaotest/Forms1/PublicPag
e.aspx can be viewed by everyone.
(http://winserv1.cs.uakron.edu/Examples/C10/Forms1/Pu
blicPage.aspx)
Deploy Forms1 on Winserv1
– http://winserv1.cs.uakron.edu/xiaotest/Forms1/Secret/Pro
tectedPage.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-bydirectory 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
Forms3
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
Password: yourPassword for MySQL
Default Schema: your DB name
File->Open Script:
T:\Xiao\Windows Programming\Examples\C10\MySQLTable-Creation\Weblogin.sql
• Execute!
Real-World Forms Authentication
Weblogin.sql
CREATE TABLE users
(
username
varchar(32)
password
varchar(32)
role
varchar(32)
);
NOT NULL,
NOT NULL,
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');
…
Deploy Forms2 on Winserv1
– Create a web application directory.
C:\inetpub\wwwroot\xiaotest\Forms2
You need to have admin privilege.
– On winserv1, use an existing web application directory
already created for you.
– Copy everything from
T:\Xiao\Windows Programming\Examples\C10\Forms2
to the above directory.
Deploy Forms2 on Winserv1
►
To access
– http://winserv1.cs.uakron.edu/xiaotest/Forms2/PublicPag
e.aspx, can be viewed by anyone.
– http://winserv1.cs.uakron.edu/xiaotest/Forms2/Secret/Pro
tectedPage.aspx and is available only to authenticated
users (dev/dev).
Deploy Forms2 on Winserv1
– “Authenticated users” means anyone who has
successfully logged in through LoginPage.aspx.
– Valid users are stored in the database.
– 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. No expiration.
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 as a user.
IE->Tools->Internet Options->General->Delete Cookies.
Netscape->Tools->Cookie Manager->Manage stored cookies->Remove all.
FireFox->Tools->Clear Recent History: check Cookies.
Google Chrome->Costumize->More Tools->Clear Browser Data->Cookies
Forms Authentication
Role-Based Security
http://winserv1.cs.uakron.edu/xiaotest/Forms3/PublicPage.aspx
http://winserv1.cs.uakron.edu/xiaotest/Forms3/Secret/ProtectedPage.aspx
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/Examples/C10/Forms3/PublicPage.aspx
http://winserv1.cs.uakron.edu/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
Property
Description
AuthenticationType
Reveals which form of
authentication was used
IsAuthenticated
Reveals whether the user is
authenticated
Name
Reveals an authenticated user’s
name
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 SetCookie 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:
Attribute
Description
Default
name
Name assigned to authentication cookies
.ASPXAUTH
loginUrl
URL of the login page
login.aspx
protection
Level of protection (validation and
encryption) applied to authentication
cookies
All
timeout
Lifetime of session authentication tickets in
minutes
30
path
Scope of authentication cookies
/
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/xiaotest/Forms3/PublicPage.aspx
http://winserv1.cs.uakron.edu/xiaotest/Forms3/Secret/ProtectedPage.aspx
http://winserv1.cs.uakron.edu/xiaotest/Forms3/Secret/Calc.html
http://winserv1.cs.uakron.edu/xiaotest/Forms3/Secret/Calc.aspx
Windows
Authentication
Windows Authentication



It maps incoming requests to accounts on the
Web server or in the Web server’s domain.
Serve content to a well-defined populace
(intranet.)
Requires no programming. Authentication is done
by the system.
Windows Authentication



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 . . .WWWAuthenticate: 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 (not part of your
ASP generated HTML) 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 the HTTP requests with Authorization
header 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/innotes/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.
Digest Authentication Cont.





When the client first requests a resource guarded by
digest authentication, the server returns a 401 error and
includes a “nonce”—a string of 1s and 0s—in a HTTPAuthenticate header.
The browser responds by prompting for a user name and
password. It then transmits the user name back to the
server, along with a hash or “digest” computed from the
combined user name, password, and nonce.
The server authenticates the request by performing its
own hash on the user name, password, and nonce. The
password the server uses doesn’t come from the client; it
comes from the server itself.
If the hashes match, the user is authenticated.
It’s also compatible with proxy servers.
Digest Authentication Cont.


Pros of Digest Authentication:
– Easy to understand.
– Works with firewalls.
– Far more secure over ordinary HTTP than basic
authentication.
Cons of Digest Authentication:
– Uses pop-up dialog boxes for user names and
passwords.
– Doesn’t support delegation (the ability to make a call
from one machine to another and have the call execute
as the caller on the remote machine) on Windows
2000 servers.
– Digest authentication is not widely used.
Integrated Windows Authentication

Uses Windows login credentials to authenticate users.

Identifies the user (on the server) by using that person’s
login identity on the client.

The browser asks for a user name and password only if
the user does not have a valid account on the server.

The client and server negotiate a trust in a series of
exchanges that involve user names, domain names,
nonces, and hashes.

All done automatically by the OS on the server and the
browser on the client.
Integrated Windows Authentication

Pros of Windows Authentication:
– Doesn’t force users who have already logged in to
Windows to provide a user name and password again.
– Secure, even over unencrypted channels, because
plain-text passwords are never transmitted.
– Good for in-house use and behind firewalls.

Cons of Windows Authentication:
– Can’t work through firewalls.
– Proprietary to Windows and Internet Explorer.
– Not for general Internet use.
Windows Authentication / ACL Authorization in Action
CorpNet



Examples\C10\Basic
About “CorpNet”
– It models a simple intranet-type application (e.g. an internal
application for a company).
– It uses Windows (basic) authentication and ACL authorization
to restrict access to its pages.
Code:
– General.aspx provides general information.
– Salaries.aspx lists the salary.
– Bonuses.aspx lists the bonuses.
Anyone in the company can view General.aspx, only selected
individuals can view Salaries.aspx and Bonuses.aspx.
Windows Authentication / ACL Authorization in Action

Deployment on your home computer:
– Create your own directory:
C:\inetpub\wwwroot\yourLoginID
– Copy
Examples\C10\Basic
To
C:\inetpub\wwwroot\yourLoginID
– Make the directory a web application.
– Access the aspx pages (as an anonymous user):
http://localhost/yourLogin/Basic/general.aspx
http://localhost/yourLoginI/Basic/salaries.aspx
(access accepted but no salary entry).
http://localhost/yourLoginID/Basic/bonuses.aspx
Windows Authentication and
Anonymous Access (No Authorization Control)
Use Web.config in the root directory to set the authentication mode.
<configuration>
<system.web>
<authentication mode="Windows"/>
</system.web>
</configuration>
•
Access CorpNet as an anonymous user on winserv1
http://winserv1.cs.uakron.edu/xiaotest/basic/general.aspx
http://winserv1.cs.uakron.edu/xiaotest/basic/salaries.aspx
http://winserv1.cs.uakron.edu/xiaotest/basic/bonuses.aspx
•
Access CorpNet as an anonymous on your own computer
http://localhost/xiaotest/basic/general.aspx
http://localhost/xiaotest/basic/salaries.aspx
http://localhost/xiaotest/basic/bonuses.aspx
Basic Authentication, No Authorization Control
(on your own computer)
Use Control Panel -> Administrative Tools -> IIS manager
to configure the application to require authentication and to
disallow anonymous access.
•
In IIS Manager, find and click on Basic application.
(WINSERV1\Sites\Default Web Site\xiaotest\Basic)
•
In the IIS pane, double-click on Authentication
•
Disable “Anonymous Authentication”
•
Enable “Basic Authentication”
•
http://winserv1.cs.uakron.edu/xiaotest/basic/salaries.aspx
•
Login prompt provided by the browser.
•
User Name: CS\xiao, Password: ???
No salary information is available for xiaotest
•
Modify salaries.aspx to enter a salary for xiaotest
ACL Authorization
•
•
Change the permissions on Salaries.aspx and Bonuses.xml to
deny CS\xiaotest read privilege.
Right-click on the file -> properties ->Security->Edit->Add
location: CS
object name: xiaotest
ok
Deny: Read
ok; ok
(advanced for inheritance)
If you don’t see the security tab in the properties window:
right-click on “Start”, open, tools, folder options, view, advanced
settings, files and folders, uncheck “Use simple file sharing”.
Tests:
http://winserv1.cs.uakron.edu/xiaotest/basic/general.aspx (ok)
http://winserv1.cs.uakron.edu/xiaotest/basic/salaries.aspx (denied)
http://winserv1.cs.uakron.edu/xiaotest/basic/bonuses.aspx (ok)
Security Inside
• Note: ACL Control is set per user and per file
manually.
– User: xiaotest access denied for Basic/Bonuses.xml
• Why you can still read Bonuses.xml through
Bonuses.aspx?
– IIS checks the login and passes access token to
ASP.NET if the login is correct.
– ASP.NET makes ACL checks using the caller’s
identity against the ASPX files to be accessed and
passes access token to the application (ASPX files).
– Web applications run inside ASP.NET which is run
by user “ASPNET”, and can programmatically access
anything that ASPNET is allowed to access.

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 in ASP.NET security.
– After IIS 6.0, W3WP.exe connects to
aspnet_isapi.dll.
Impersonation
– Impersonation makes web applications run as the caller. Any
programmatically access will subject ACL check using the caller’s
identity.
<configuration>
<system.web>
<authentication mode="Windows" />
<identity impersonate="true" />
</system.web>
</configuration>
– Start a new browser
– http://winserv1.cs.uakron.edu/xiaotest/basic/bonuses.aspx
– “500 - Internal error occurred.”
– The following does work on winserv1
• IIS Manager, double-click on the Basic application.
• In the IIS pane, double-click on Authentication
• Enable “ASP.NET Impersonation”

CorpNet demonstrates several important principles for
using Windows authentication:
– Windows authentication is enabled in ASP.NET by including an
<authentication mode=“Windows” /> statement in Web.config. It
has the scope of the Web.config at application level (not page
level).
– ASP.NET applications that use Windows authentication can
prevent users from viewing files by using ACLs to deny access to
selected security principals.
– ASP.NET applications that use Windows authentication must
enable impersonation if they want resources protected by ACLs to
be protected from programmatic accesses by code executed
within a request.
– ASP.NET applications that use Windows authentication can
personalize content for individual users by reading user names
from Page.User.Identity.Name.
– ACL authorization requires system administrators of the web
server to manually set the security control for each application
(even each page/file).
Windows Authentication and URL Authorizations
►
Change web.config to use URL authorization so the programmer
can set the security control (per directory not per file).
<configuration>
<system.web>
<authorization>
<deny users="CS\YourUnixID" />
<allow users="*" />
</authorization>
</system.web>
</configuration>
►
►
►
►
“CS\YourUnixID" is not allowed to access any APSX pages in Basic.
Note only one “\” after “CS”.
Based on string names not Windows security IDs (SIDs).
The deny statement needs to be before the allow statement in the
above case.
URL authorizations usually not used with Windows authentication.
Windows Authentication and Role-Based Security
►
►
►
►
►
Role-based security restricts access based on “roles” (groups) that the users belong to.
For ACL authorizations, control the access by giving permission to the selected
groups.
For URL authorizations, use Web.config to restrict groups.
e.g. add the “WP” group and a “test2” user in the group.
Start->Settings->Control Panel->User Accounts->Advanced->Advanced->Groups
Action->New Group
Start->Settings->Control Panel->User Accounts->Advanced->Advanced->Users
test2->properties->Member Of->Add
Action->New Users
Web.config
<authorization>
<allow roles=“ServerName\WP" />
<deny users="*" />
</authorization>
Deny test but allow test2.
Allow should be first here. (“*” should be at the end).
Summary
Security
Authentication
Forms
Windows
Basic, Digest, Integrated, SSL Client Certificates
Passport
Authorization: ACL, URL
IIS/ASP.NET Server-Side Security Processing
Application Security Scenarios
Encryption and Validation
Database Based Authentication
Role Based Authorization
Anonymous Login
Impersonation
Realm
Good References
Microsoft Security Tutorials
http://www.asp.net/web-forms/tutorials/security
ASP.NET authentication and authorization
by Shivprasad Koirala
http://www.codeproject.com/Articles/98950/ASP-NET-authentication-andauthorization#Authentication%20and%20Authorization
Download