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.
