ASP.
NET SECURITY
INTRODUCTION
Web applications are available to any user who can connect
to the web server.
Web applications are subject to several types of attacks.
[Link] simplifies programming secure applications by
providing a built-in infrastructure that supplies
application-level protection against unauthorized access to
Web pages.
WHY SECURITY?
Unauthorized Access to Private Data
Packet Sniffing (Eavesdropping)
Site Availability
COMMON WEB ATTACKS
Cross-Site Scripting
Hidden-field Tampering
Eavesdropping
Session Hijacking
Denial of Service (DOS)
[Link] SECURITY FLOW FOR REQUEST
AREAS OF SECURITY
Authentication
Authorization
Impersonation
Encryption
Data Validation
AUTHENTICATION
To ascertain the caller’s identity.
Usually involves entering credentials into some sort of
login page or window.
The credentials are then authenticated against the
Windows user accounts on the computer, a list of users in a
file, or a back-end database.
Three types: Forms, Windows & Passport.
AUTHORIZATION
The process of determining whether that user has
sufficient permissions to perform a given action.
Windows as well as code impose its own security checks.
IMPERSONATION
In [Link], code runs with under ASPNET account.
Impersonation allows a portion of the code to run under a
different identity, with a different set of Windows
permissions.
RESTRICTED FILE TYPES
[Link] automatically provides a basic level of security
by blocking requests for certain file types.
.asax, .ascx, .cs, .vb, .config, .csproj, .vbproj, .resx, .resources .
CERTIFICATES
Certificate ensures that the site & organization
information is registered & verified with the certificate
authority.
A certificate is required to use SSL which encrypts all
information sent between client & server.
One need to purchase a certificate from certificate
authority.
CERTIFICATE AUTHORITIES
Verisign ([Link]
GeoTrust ([Link]
GlobalSign ([Link]
E-mail a certificate request to certificate authority.
IIS has a wizard which asks for information & generates
the request file to be e-mailed.
REQUEST FILE GENERATION
Click here to start the
wizard.
SECURE SOCKETS LAYER (SSL)
SSL encrypts communication between a client and a
website.
Certificates ensure server identity to client.
IIS Directory settings can specify that individual folders
require an SSL connection.
To access the page over SSL, the client simply types the
URL with a preceding https instead of http.
In [Link] code, one can check whether connection is
secure or not, by using IsSecureConnection of Request
object.
FORMS AUTHENTICATION
Authenticates a user by asking the user to type credentials
(e.g., user name/password) into a web form.
Put login form in application directly & configure it in
[Link] file.
<[Link]>
<authentication mode=”Forms”>
<forms name=”iConnect” loginUrl=”[Link]” path=”/” />
</authentication>
…
</[Link]>
FORMS AUTHENTICATION
When a user accesses for the firstt time, [Link] redirects
the user to the login page.
If the login is successful, [Link] issues a ticket in the
form of a cookie and redirects the user to the page
originally requested.
Uses cookie to authenticate next time.
FORMS AUTHENTICATION SETTINGS
Name
The name of the HTTP cookie to use for authentication (defaults to
.ASPXAUTH).
If multiple application on the web server, use unique names.
loginUrl
Custom login page where user is redirected if no valid authentication
cookie is found.
Protection
The type of encryption and validation used for the security cookie.
Possible values None, Validation, Encryption and All.
Validation ensures the cookie isn’t changed during transit
FORMS AUTHENTICATION SETTINGS
Timeout
The number of minutes before the cookie expires. (default is
30).
[Link] will refresh the cookie when it receives a request.
Path
The path for cookies issued by the application.
Default is /.
requireSSL
Specifies whether a Secure Sockets Layer (SSL) connection is
required when transmitting authentication information.
FORMS AUTHENTICATION FLOW
AUTHORIZATION
Control web page access.
<authorization> section of [Link] has access control
rules.
<[Link]>
<authentication mode=“Forms”>
…
</authentication> * for all users
<authorization> (autheticated &
<deny users=“*” /> non-autheticated)
</authorization>
…
</[Link]>
<ALLOW> & <DENY> ELEMENT
ATTRIBUTES
Users
Specifies users by their names in a comma separated list.
“?” matches all anonymous users.
Roles
Specifies access groups that are allowed or denied access.
Comma-separated list of roles.
Verbs
Specifies the HTTP transmission method (e.g GET) that is
allowed or denied access.
AUTHORIZATION
<[Link]>
<authentication mode=”Forms”>
<forms name=”iConnect” loginUrl=”[Link]” path=”/” />
</authentication>
<authorization>
<allow users=“ram,paddy” />
<deny users=”?” />
</authorization>
</[Link]>
CONTROLLING ACCESS TO SPECIFIC DIRECTORIES
A common application design is to place files that require
authentication in a separate directory.
Add a [Link] file that specifies stricter settings in the
secured directory.
Subdirectory config file override the parent directory config
settings.
CONTROLLING ACCESS TO SPECIFIC PAGE
Use <location> tag in [Link].
It is directly nested in <configuration>
One can have multiple <location> tags.
<location path=“~/[Link]” >
<[Link]>
<authorization>
<deny users=“?” />
</authorization>
</[Link]>
</location>
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
LOGIN PAGE
[Link] provides a special FormsAuthentication class, which
provides static methods that help manage the authentication.
protected void Button1_Click(object sender, EventArgs e)
{
if ([Link] == “iconnect” && [Link] == “iconnect”) {
[Link]([Link], true);
}
else {
[Link](“Invalid credentials”);
}
}
FORMSAUTHENTICATION MEMBERS
Authenticate()
Checks a user name and password against a list of accounts
that can be entered in the [Link] file.
Does not require manual test for user & password.
RedirectFromLoginPage()
Logs the user into an [Link] application by creating the
cookie & redirecting the user to the requested secure page.
Second parameter if true, creates persistent cookie.
FORMSAUTHENTICATION MEMBERS
SignOut()
Logs the user out of the [Link] application by removing the
current cookie.
SetAuthCookie()
Logs the user into an [Link] application by creating and
attaching the forms authentication cookie. Do not redirect.
HashPasswordForStoringInConfigFile()
Encrypts a string of text using the specified algorithm (SHA1
or MD5).
<CREDENTIALS> ELEMENT IN
[Link]
Hard-coding user name & password is not a good idea.
One can store user names & password in [Link] in credentials
section. Use Autheticate method.
Limitation: File Size. Use database.
<forms name=”iConnect” loginUrl=”[Link]” path=”/”>
<credentials passwordFormat=”Clear”>
<user name=”iconnect” password=”iconnect” />
</credentials>
</forms>
Clear: stores password in clear text.
MD5 : Hashes password using MD5 hash algo.
SHA1: Hashes password using SHA1 hash algo
PREVENTING PAGE REVIEW AFTER
LOGOUT
Local caching by browsers and proxy servers may allow a user
to review information even after they have logged out.
HTTP Headers to avoid this scenario is :
Expires : the expire header is set to an absolute date & time
Pragma No-Cache : Signals proxy servers to expire
responses
Cache-Control : Values for it are
A) Public – Content stored in public shared caches
B) Private - Content stored in private shared caches
C) No-Cache – Content not cached
D) No-Store - Content may be cached for the length of the
session, but not archived.
PREVENING PAGE REVIEW
WINDOWS AUTHENTICATION
User is authenticated by IIS
Easiest of all
Can be used with in combination of Basic, Digest
authentication.
Request flow
Client makes request
IIS authenticates request, forwards security token to
[Link].
[Link] limits access to resources using security token.
WINDOWS AUTHENTICATION METHODS
Anonymous Access
Digest Authetication
Basic Authentication
WINDOWS AUTHENTICATION
Basic authentication: transmits a user name and password in
each request; IIS maps them to an account on the web server and
generates a token.
Suppose a web page is placed in the virtual directory
Suppose IIS is configured to disallow anonymous access to that
directory and to require basic authentication
When a user attempts to access it for the first time (via HTTP
request, a status code 401 is returned indicating that it requires basic
authentication
The user’s browser then prompts the user for windows user
name/password
Problem: User name/password sent in plain text between the browser
and the web server with each request; user needs a windows account
WINDOWS AUTHENTICATION
Digest authentication: User name/password are sent as an
encrypted token with each request
Supported by only IE 5.0 or later.
Windows Integrated Authetication : When using Integrated
authentication, Internet Explorer can send the required
information automatically using the currently logged-in Windows
account on the client, provided it’s on a trusted domain.
Integrated authentication is supported only on Internet Explorer 2.0
and later and won’t work across proxy servers.
WINDOWS AUTHENTICATION
CONFIGURATION
Set mode to “Windows”
Configure <authorization> section
<authentication mode=" Windows" />
<authorization>
<deny users="?" />
<allow users= "*" />
</authorization>
PASSPORT AUTHENTICATION
Single sign-in across member sites
Includes user profiles services
Integrated into [Link] authentication
Scenarios
Don’t want to maintain a database of users
Provide personalized content
Need to provide single-sign in capabilities
Visit [Link]
PASSPORT AUTHENTICATION CONFIGURATION
What you need:
Install Passport SDK
Register with Microsoft Passport
Set mode to “Passport”
Configure <passport> section
<authentication mode="Passport">
<passport redirectUrl="internal|url" />
</authentication>
IMPERSONATION
Code impersonate identity of the user. Code access to
resources beyond user privileges not allowed.
e.g. If user not allowed access to file, code cannot access the
file.
Used in Windows network.
For Impersonation to work, the authenticated user account
must correspond to a Windows account.
IMPERSONATION CONFIGURATION IN [Link]
<identity impersonate = “false” />
<identity impersonate = “true” />
<identity impersonate = “true” userName = “username”
password = “password” />
PROGRAMMATIC AUTHORIZATION
Page object has User property which provides an instance
of IPrincipal.
User has one property & one method:
Identity: property provides an instance of the
[Link] object.
IsInRole():Takes a single parameter, a string representation of
the system role. Returns true if the user is member of the role
specified.
[Link]
Name
Provides the username of the user.
IsAuthenticated()
Returns a Boolean value specifying whether the user has been
authenticated.
AuthenticationType
Provides the authentication type of the current user. e.g.
Basic, Forms, Passport etc.
WINDOWS USERS (CHECK ROLES)
if([Link]("BUILTIN\Administrators"))
[Link]("You are an Admin");
else if([Link]("BUILTIN\Users"))
[Link]("You are a User");
else
[Link]("Invalid user");
WINDOWSIDENTITY CLASS
Namespace: [Link].
WindowsIdentity much richer than Identity.
protected void Page_Load(object sender, EventArgs e)
{
WindowsIdentity AuthUser = [Link]();
[Link]([Link]() + “<br>” +
[Link]() + “<br>” +
[Link]() + “<br>” +
[Link]() + “<br>” +
[Link]() + “<br>” +
[Link]() + “<br>” +
[Link]());
}
PROGRAMMATIC IMPERSONATION
if([Link]()==typeof(WindowsPrincipal))
{
WindowsIdentity id=(WindowsIdentity)[Link];
WindowsImpersonationContext impersonateContext=[Link]();
// now perform tasks under the impersonated ID.
…
// Revert to the original ID
[Link]();
}