Beginning ASP.NET Security3

PART III: Advanced ASP.NET Scenarios

Chapter 11: Shareing Data with windows communication foundation

Creating and Consuming WCF Services

Security and Privacy with WCF

Transport Security

Message Security

Mixed Mode

Selecting the Security Mode

Choosing the Client Credentials

Adding Security to an Internet Service

Signing Messages with WCF

Logging and Auditing in WCF

Validating Parameters Using Inspectors

Using Message Inspectors

Throwing Error in WCF

A Checklist for Securing WCF

• Never expose services over protocols you are not using.—Once you have migrated your services to a secure protocol, remove the insecure protocols so that they can no longer be used.
• Choose an appropriate binding for interoperability and security.—Not all clients may understand the WS* protocols. However, you can apply security to the BasicHttpProtocol if interoperability is a concern. But the WS* protocols offer more flexibility.
• Choose a suitable authentication mechanism for your protocol.—The credential type used will depend on your setup. Intranets, for example, may use Windows authentication to automatically authenticate to service, but this is not suitable for Internet-facing services, which should use a username and password.
• Apply authorization to your service contract using PrincipalPermission.
• Utilize message inspectors if needed.—Message inspectors allow you to examine a message before it reaches your service implementation, allowing for custom rules and filtering on any message property.
• Throw custom SOAP faults from your service, not .NET exceptions.—Never set IncludeExceptionDetailsInFaults to true.

Chapter 12: Securing rich internet applications

RIA Architecture

Security in Ajax Applications

The XMLHttpRequest Object

The Ajax Same Origin Policy

The Microsoft ASP.NET Ajax Framework

Examining the UpdatePanel

Examining the ScriptManager

Security Considerations with UpdatePanel and ScriptManager

Security in Silverlight Applications

Understanding the CoreCLR Security Model

Using the HTML Bridge

Accessing the

Using ASP.NET Authentication and Authorization in Ajax and Silverlight

A Checklist for securing Ajax and Silverlight

• Both Ajax and Silverlight are constrained by cross domain policies.—Ajax can only communicate with services and resources on the same domain. Silverlight can access external resources if the external Web site allow it.
• The Ajax UpdatePanel could be considered more secure than ScriptManager.—UpdatePanel hides implementation, reduces the attack service, and is easier to implement than ScriptManager services, making it a more secure option. However, ScriptManager services are more scalable.
• The Silverlight security model has restrictions.—The Silverlight security model restricts the classes you can inherit from, as well as the methods you can implement or override.
• Silverlight Isolated storage is discoverable by users.—Do not use isolated storage to save sensitive information.
• All Silverlight cryptography functions need initial value.—You cannot strore keys, hashes, or initialization vectors (IVs) securely on the local machine. Use a Web service in conjunction with the ASP.NET membership functions to store cryptographic keys on your server.

Chapter 13: Understanding code access security

Understanding Code Access Security

Using ASP.NET Trust Levels

Demanding Minimum CAS Permissions

Asking and Checking for CAS Permissions

Testing Your Application Under a New Trust Level

Using the Global Assembly Cache to Run Code Under Full Trust

.NET 4 Changes for Trust and ASP.NET

A Checklist for Code not Under Full Trust

• Always wrap code that requires CAS permissions with a demand.—You should specify mimimum permissions for your code, or fail gracefully, or disable functionality if the decmand fails.
• Place code that always requires Full Trust in a separate assembly stored in the GAC.—GAC assemblies will always run as Full Trust.
• Remember to opt-in to allow partially trusted callers.—The .NET framework will stop code hosted in partial trust environments from calling GAC assemblies, unless opt-in and mark your assembly with the AllowPartiallyTrustedCallers attribute.
• Remember to use Demand/Assert in APTC assemblies.—This will check the calling assemblies that are allowed to perform the function. If you want to override this, then remember that anyone can call a GAC assembly, unless you add a StrongNameIdentityPermission.

Chapter 14: Securing internet information server (IIS)

Installing and Configuring IIS7

IIS Role services

Removing Global Features for an Individual Web Site

Creating and Configuring Application Pools

To configure the account an application pools runs under, you must first create the Windows user account and add to to the IIS_IUSERS group (or the IIS_SPG group for IIS6/Windows 2003). This group adds the right permissions for a Windows account to be used as an application pool identity.

Configuring Trust Levels in IIS

Locking Trust Levels

Creating Custom Trust Levels

Filtering Requests

Filtering Double-Encoded Requests

Filtering Requests with Non-ASCII Characters

Filtering Requests Based on File Extension

Filtering Requests Based on Request Size

Filtering Requests Based on HTTP Verbs

Filtering Requests Based on Request Sequences

Filtering Requests Based on a Request Header

Status Codes Returned to Denied Requests

Using Log Parser to Mine IIS Log Files

Log Parser: http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1287

Using Certificates

Requesting an SSL Certificate

Configuring a Site to Use HTTPS

Setting up a Test Certification Authority

A Checklist for Securing Internet Information Server (IIS)

• Configure application pool identities. —Configuration a separate application pool identity will isolate multiple Web sites on the same machine. Setting a specific application pool identity will (If the identity has the appropriate permissions) allow you to access networked resources.
• Configure appropriate trust levels for ASP.NET applications.—Limiting what your application can do is best practice, because your applications will run under the least privilege possible. If the standard trust levels do not meet your needs, then customize and create your own.
• Configue logging in IIS.—Log files can provide a valuable source of information when trying to track down potential attacks, or to evaluate successful ones.
• Filter requests with IIS.—Using IIS’s request filtering will stop potentially dangerous requests from reaching your application, and provides another layer of defense.
• Use the Windows Certificate Authority to generate test certificates for HTTPS sites and Web services.—Using a test CA provides support for certificate validation and revocation, allowing you to develop your code without lowering the security level on certificate –handling code. This in turn, removes the risk of insecure test code making it into a production environment.

Chapter 15: Third-party authentication

A brief history of federated identity

Using the Windows Identity Foundation to accept SAML and Information Cards

Creating a “Claims - Aware” web site

Accepting information cards

Working with a claims identity

Using OpenID with your web site

Using Windows Live ID with your web site

A strategy for integrating third-party authentication with forms ahthentication

Chapter 16: Secure development with the ASP.NET MVC framework

MVC input and output

Protecting yourself against XSS

Protecting an MVC Application against CSRF

Securing model binding

Providing validation for and error messages from your model

Authentication and Authorization with ASP.NET MVC

Authorizing actions and controllers

Protecting public controller methods

Discovering the current user

Customizing authorization with an authorization filter

Error handling with ASP.NET MVC

A checklist for secure development with the ASP.NET MVC framework

• Always encode your output when adding it to your View. —Encoding your output will protect you against XSS attacks.
• Protect your POST actions with an anti-forgery token.—An anti-forgery token will protect you form CSRF, but remember that it is two-step process: add the form to the token and apply the [ValidateAntiForgeryToken] attribute to your action.
• Secure your model binding.—Witelist the properties binding to avoid malicious updates by the inclusion of extra input fields.
• Perform authorization on actions in your Controller, not based upon URLs.—Authorization rules based on URLs may not work because you can create multiple routes to a Controller.
• Use filters to provide common exception handing and custom authorization logic.—Placing common code like this in a filter allows for it to be reused across multiple Controllers and actions.